【Kafka】图解 Leader Epoch 解决数据不一致问题

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

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 = 2, HW = 1, [Epoch = 0, Offset = 0]
Follower： LEO = 1, HW = 1

Leader 在 offset 为 0, 1 的位置有两条数据。 Follower 在 offset 为 0 的位置有一条数据。

1. 这时候，Follower 宕机了后重启

当第二条数据还没有同步到 Follower 里，Follower 就宕机了。

2. 这时候，Leader 宕机了后重启，Follower 变为 新Leader

这时候新 Leader：[epoch = 1, offset = 1]

3. 这时候，有新数据写入 Leader

4. 副本A请求拉取数据

• 副本A请求拉取数据，发现 Leader 的 offset = 1 跟自己的 offset = 1 一致，但自己这已经有数据了
• 此时就会截断掉自己一条数据，然后跟人家同步保持数据一致