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 。