Kafka 之 HW 与 LEO

HW（High Watermark）：俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个 offset 之前的消息。分区 ISR 集合中的每个副本都会维护自身的 LEO（Log End Offset）：俗称日志末端位移，而 ISR 集合中最小的 LEO 即为分区的 HW，对消费者而言只能消费 HW 之前的消息。

LEO：该副本底层 log文件下一条要写入的消息的位移，例如 LEO=10则当前文件已经写了了10条消息，位移是[0,10)。
HW：所有分区已提交的的位移，一般HW<=LEO。

多副本下，各个副本中的 HW和 LEO的演变过程

某个分区有3个副本分别位于 broker0、broker1 和 broker2 节点中，假设 broker0 上的副本1为当前分区的 Leader 副本，那么副本2和副本3就是 Follower 副本，整个消息追加的过程可以概括如下：
【1】生产者客户端发送消息至 Leader 副本（副本1）中；
【2】消息被追加到 Leader 副本的本地日志，并且会更新日志的偏移量。
【3】Follower 副本（副本2和副本3）向 Leader 副本请求同步数据。
【4】Leader 副本所在的服务器读取本地日志，并更新对应拉取的 Follower 副本的信息。
【5】Leader 副本所在的服务器将拉取结果返回给 Follower 副本。
【6】Follower 副本收到 Leader 副本返回的拉取结果，将消息追加到本地日志中，并更新日志的偏移量信息。
某一时刻，Leader 副本的 LEO 增加至5，并且所有副本的 HW 还都为0。

之后 Follower 副本（不带阴影的方框）向 Leader 副本拉取消息，在拉取的请求中会带有自身的 LEO 信息，这个 LEO 信息对应的是 FetchRequest 请求中的 fetch_offset。Leader 副本返回给 Follower 副本相应的消息，并且还带有自身的 HW 信息，如上图（右）所示，这个 HW 信息对应的是 FetchResponse 中的 high_watermark。

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

接下来 Follower 副本再次请求拉取 Leader 副本中的消息，如下图（左）所示。

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