kafka数据同步（高水位&Leader Epoch）

相关名词

• LEO:每个分区中最后一条消息的下一个位置（offset），分区的每个副本都有自己的LEO

• HW(high watermarker:高水位线):核心思想为所有HW之前的数据都是已经备份的，当所有节点都备份成功，Leader会更新HW。

• ISR(in-sync-replicas):正在同步的副本集合，一个时间范围，例如10s内，改时间范围通过replica.lag.time.max.ms控制

  • 副本没有发送fetch(同步数据)的请求
  • 发送了请求但是在该时间范围内没有赶上Leader的数据（即副本一直拉取数据，但是一直同步不到到最新的LEO）

  将会把该副本踢出ISR。

数据同步-高水位

1.高水位

如上图，(LEO错误标记为EOF)leader的LEO为13，follower1同步到LEO=11,follower2同步到LEO=8,因为只有所有的副本都备份成功Leader才会更新HW,所以HW为7。从事务的角度理解为7之前的数据commited状态，7之后的数据为uncommited状态。

2.高水位存在的问题

kafka的0.11版本前采用高水位的模式进行数据同步，但是这种同步方式存在数据丢失以及数据不一致的的问题

在了解这两个问题前我们需要明白以下几个流程

1. 副本的LEO、HW的更新流程与时机？https://blog.csdn.net/m0_46449152/article/details/115057392
2. Leader的LEO、HW的更新流程与时机？https://www.cnblogs.com/huxi2b/p/7453543.html

• 数据丢失
  
  数据丢失流程：前提条件BrokerB（Leader）的HW=0,BrokerA的HW=0

1. BrokerB写入消息m2

2. BrokerA从BrokerB fetch数据得到m2并写入本地

3. BrokerA更新自己的LEO,因为还有其他副本未更新到m2，BrokerB返回给BrokerA的HW为0，BrokerA与自身的HW比较取小将自身HW更新为0

4. 此时所有副本都同步完m2，更新BrokerB的HW为1

5. 在BrokerA还未发起下一次Fetch时，BrokerA发生重启，由于自身的WH为0，所以将m2截断并删除，并且尝试从BrokerB上更新数据

6. BrokerA尝试更新数据时，BrokerB发生宕机，BrokerA变为Leader。此时m2消息丢失。

• 数据不一致
  

1. BrokerA为follower并且处于宕机状态，BrokerB为Leader，在写入m2后，其他副本正常同步完成，B的HW=1,这是B也宕机了
2. 此时A和B同时重启，但是A启动的比较快如果A变成了Leader并写入了m3，同时其他follower同步完数据，这是A的HW也=1
3. 在A的HW变为1后，B正常启动发现自己的HW也等于1，便不会截断消息。
4. 这时在offset等于1的位置上，A为m3，B为m2便产生了消息不一致

数据同步-leader epoch

待研究清楚后补充