HW和LEO

　　follower 副本（不带阴影的方框）向 leader 副本拉取消息，在拉取的请求中会带有自
身的 LEO 信息，这个 LEO 信息对应的是 FetchRequest 请求中的 fetch _offset 。leader 副本
返回给 follower 副本相应的消息，并且还带有自身的 HW 信息，如图 8-5 所示，这个 HW 信息
对应的是 FetchResponse 中的 high_watermark 。

　　follow往leader发带的是LEO, Leader往follow发的是自己的HW
　　

　　

　　此时两个 follower 副本各自拉取到了消息，并更新各自的 LEO 为 3 和 4。与此同时，follower
副本还会更新自己的 HW，更新 HW 的算法是比较当前 LEO 和 leader 副本中传送过来的 HW 的
最小值 ，取较小值作为自己的HW值。当前两个follower 副本的 HW 都等于 0 ( min(0,0) = 0） 。

　　接下来follower 副本再次请求拉取 leader 副本中的消息，如图 8 -6 所示。

此时 leader 副本收到来自 follower 副本的 FetchRequest 请求 ， 其中带有 LEO 的相关信息，
选取其中的最小值作为新的 HW, 即 min(l5,3,4）= 3 。然后连同消息和 HW 一起返回 FetchResponse
给 follower 副本，如 图 8-7 所示。注意 leader 副本的 HW 是一个很重要的东西，因为它直接影
响 了分区数据对消费者 的可见性 。

　　

　　

　　两个follower副本在收到新的消息之后更新 LEO 并且更新自己的 HW 为 3 ( min(LEO , 3)=3 ） 。
在一个分区中， leader 副本所在 的节点会记录所有副本的 LEO ， 而 follower 副本所在的节
点只会记录 自身的LEO，而不会记录其他副本的 LEO 。 对 HW 而言，各个副本所在的节点都只
记录它 自身 的HW。变更图 8-3 ，使其带有相应的 LEO 和 HW 信息，如图 8 -8 所示。 leader 副
本中带有其他 follower 副本的 LEO ，那么它们是什么 时候更新的 呢？ leader 副本收到 follower
副本的 FetchRequest请求之后，它首先会从自己的日志文件中读取数据，然后在返回给 follower
副本数据前先更新 follower 副本的 LEO 。