KAFKA 服务端日志LEO和HW说明

KAFKA 服务端日志LEO和HW说明

KAFKA 服务端一个日志文件包含两个特性：日志末端位移（log-end-offset）和高水印（high-watermask），无论是LEADER还是follow副本均含有这两个特性：

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

HW：所有分区已提交的的位移，HW之外consumer无法消费，一般HW<=LEO。

一 LEO更新机制

1.1 follow的LEO更新机制

follow的LEO更新机制包括follow所在broker的follow的LEO更新机制以及Leader所在broker的follow的LEO更新机制。

follow所在broker的follow的LEO更新机制主要是为了follow的HW更新；

Leader所在broker的follow的LEO更新机制主要是为了Leader的HW更新。

（1）follow所在broker的follow的LEO更新机制

在follow向Leader发送fetch同步请求后，Leader将数据返回，此时follow向底层log写入数据然后更新LEO。

（2）Leader所在broker的follow的LEO更新机制

在follow向Leader发送fetch同步请求后，Leader收到后首先从自己底层log读取数据，然后根据Leader上的follow的LEO。再向follow发送响应。

1.2 Leader的LEO更新机制

在producer向Leader发送producer同步请求后，Leader收到数据，此时Leader向底层log写入数据然后更新LEO。

二 HW更新机制

2.1 follow的HW更新机制

更新时机：follow收到Leader的fetch响应更新follow端的LEO后，尝试更新follow的HW。

更新方式：HW=min(follow端的LEO,fetch响应中LEADER的HW)

2.2 LEADER的HW更新机制

更新时机：（1）新副本成为LEADER副本；（2）broker崩溃；（3）producer向LEADER请求写入了数据更新了LEADER的LEADER LEO；（4）follow向LEADER请求同步，更新了LEADER的follow的LEO

更新方式：HW=min(LEADER LEO, all follows' LEO in LEADR broker)

这里的所有follow包括ISR以及即将具备入ISR还没来得及入ISR的副本（副本LEO落后LEADER LEO的时长低于replica.lag.time.max.ms）

设一个主题，分区数1，副本因子2。

第一轮fetch

生产者给该topic发送了一条信息，待Leader写入log后更新Leader端的LEO=1；尝试更新Leader 的hw，hw=min(leader leo,follow leo)=0故hw=0

follow发送fetch请求，请求中附带follow端的follow leo=0,Leader读取log然后更新Leader的follow leo=0（因为fetch请求中附带follow端的follow leo=0）；尝试更新Leader hw=min(leader leo,follow leo)=0,故塞给fetch相应中的leader hw=0

follow收到fetch请求后，写log，更新leo=1，follow的hw=min(leo, leader hw)=0

第二轮fetch

follow发送fetch请求，请求中附带follow端的follow leo=1,Leader读取log然后更新Leader的follow leo=1（因为fetch请求中附带follow端的follow leo=1）；尝试更新Leader hw=min(leader leo,follow leo)=1故塞给fetch相应中的leader hw=1

follow收到fetch请求后，写log,此时无数据，故leo=1，follow的hw=min(leo, leader hw)=1