Kafka的日志同步

首先介绍下LEO和HW

LEO： 即LogEndOffset，表示该副本下次日志记录的偏移量

HW：即HighWatermark，高水位线，是所有ISR副本集合中的LEO最小值

上图中，如果此时三个副本都在ISR集合中，那么此时他们的LEO，分别为9,7,6 ，而HW则为6，只有在HW之前的消息才是消费者可见的

Kafka消息的整个追加过程可以概括如下

1. 生产者客户端发送消息至Leader副本

2. 消息被追加到leader副本的本地日志，并且会更新日志的偏移量即LEO

3. follower副本向leader副本请求同步数据

4. leader副本所在的服务器读取本地日志，并更新对应拉取的follower副本的信息

5. leader副本所在的服务器将拉取结果返回给follower副本

6. fllower副本收到leader副本返回的拉取结果，将消息追加到本地日志中，并更新日志的偏移量信息

这个过程中，我们分析下LEO和HW的变化

现在，生产者一直往leader（带阴影的方框）写入消息，某一时刻，leader的LEO增加至5，并且所有副本的HW都还为0

之后fllower副本（不带阴影的方框）向leader拉取消息，在拉取的请求中会带有自身的LEO信息，这个LEO信息对应的是FetchRequest请求中的fetch_offset。

leader副本返回给follower副本相应的消息，并且还带有自身的HW信息，如图8-5，这个HW信息对应的是FetchResponse中的high_watermark

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

接下来，follower副本再次请求拉取leader副本中的消息

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

两个follower收到新的消息后更新LEO并更新自己的HW为3，去leader HW和自身LEO的最小值。

在一个分区中，leader副本所在的节点会记录所有副本的LEO，而follower副本所在的节点只会记录自身的LEO，而不会记录其他副本的LEO。对HW而言，各个副本所在的节点都只记录自身的HW。

ISR ： 分区中的所有副本统称为AR，而ISR是指与leader副本保持同步状态的副本集合，当然leader副本本身也是这个集合中的一员。如果副本将leader副本LEO之前的日志全部同步时，则认为该副本已经追上了leader副本，此时更新该副本的lastCaughtUpTimeMs标识，kafka的副本管理器会启动一个副本过期的定时检测任务，如果当前时间与副本的lastCaughtUpTimeMs标识差值是否大于参数replica.lag.time.max.ms，如果大于则会判断为失效副本，被踢出ISR集合，还有个就是如果副本滞后的消息大小超过replica.lag.max.messages时，也会判断为失效副本