【Kafka】图解 Leader Epoch 解决数据丢失问题

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第13天，点击查看活动详情

Kafka 的 0.11.x 版本如何解决之前版本高水位机制的弊端?

高水位机制存在弊端有：

1. Follower 副本的高水位更新需要一轮额外的拉取请求才能实现。

2. Leader 副本高水位更新和 Follower 副本高水位更新在时间上是存在错配的。

   • 数据丢失
   • 数据不一致

Tips: Kafka 0.11.x 版本引入 leader epoch 机制解决高水位机制弊端。

Leader Epoch，大致可以认为是 Leader 版本，由两部分数据组成：[epoch, offset]  

• Epoch：一个单调增加的版本号; 每当副本领导权发生变更时，都会增加该版本号。小版本号的 Leader 被认为是过期 Leader，不能再行使 Leader 权力。
• 起始位移（Start Offset）：Leader 副本在该 Epoch 值上写入的首条消息的位移。

Leader Epoch 解决数据丢失问题

前情回顾：Leader 切换时发生数据丢失问题

环境前提：

# 副本有 2 个，1 个 leader 和 1 个 follower
replication-factor = 2
​
# 最小同步数为1，1个副本写入数据就认为写入成功
min.insync.replicas = 1

此问题发生在 Follower 第二次拉取数据时，各副本状态如下：

# 这时候 Leader 和 follower 的状态是：
Leader  ： LEO = 1, HW = 1, [Epoch = 0, Offset = 0]
Follower： LEO = 1, HW = 0

1. 此时 Follower 宕机，Follower 重启：

2. Leader 宕机再重启，Follower 成为新 Leader：

# Epoch 元数据存储在 Zk
# Follower 成为新的 Leader，对应Epoch为：
[Epoch = 1, Offset = 1]
​
# 意思为：当前版本为 1, 下次写入数据的 Offset 为 1

3. 副本A 变成 Follower，请求拉取数据时，对比 Offset = 1 都相同，则不需要进行数据截断