Kafka 副本备份机制(LEO,HW,leader epoch)
Kafka副本备份机制(LEO,HW,leader epoch)
Kafka 0.11版本之前水印副本备份机制
步骤:
-
初始leader,follower参数都为0,其中leader中的remote LEO记录的是follower的LEO
-
生产者发送消息m1到leader中,更新leader的LEO为1
-
follower fetch leader,follower写入日志,更新follwer的LEO为1
-
follower再次fetch leader,leader接受到以后,更新leader中的remote LEO为1,并更新HW(取leader中的LEO,remote LEO 最小值)为1,
follower获取fetch返回信息,leader的HW为1,更新follower自身的HW为1。
更新HW,需要额外的一轮fetch rpc请求。
水印备份机制缺陷
数据丢失
数据不一致/离散
造成上述两个问题的根本原因在于HW值被用于衡量副本备份的成功与否,但HW值的更新是异步延迟的,特别是需要额外的FETCH请求处理流程才能更新,故这中间发生的任何崩溃都可能导致HW值的过期。鉴于这些原因,Kafka 0.11引入了leader epoch来取代HW值。
leader epoch
Kafka 引入了 leader epoch 机制,在每个副本日志目录下都创建一个 leader-epoch-checkpoint 文件,用于保存 leader 的 epoch 信息,如下,leader epoch 长这样:
它的格式为 (epoch offset),epoch指的是 leader 版本,它是一个单调递增的一个正整数值,每次 leader 变更,epoch 版本都会 +1,offset 是每一代 leader 写入的第一条消息的位移值,比如:
(0, 0)
(1, 300)
以上第二个版本是从位移300开始写入消息,意味着第一个版本写入了 0-299 的消息。
leader epoch工作机制
1)当副本成为 leader 时:
这时,如果此时生产者有新消息发送过来,会首先新的 leader epoch 以及 LEO 添加到 leader-epoch-checkpoint 文件中。
2)当副本变成 follower 时:
- 发送 LeaderEpochRequest 请求给 leader 副本,该请求包括了 follower 中最新的 epoch 版本;
- leader 返回给 follower 的相应中包含了一个 LastOffset,如果 follower last epoch = leader last epoch,则 LastOffset = leader LEO,否则取大于 follower last epoch 中最小的 leader epoch 的 start offset 值,举个例子:假设 follower last epoch = 1,此时 leader 有 (1, 20) (2, 80) (3, 120),则 LastOffset = 80;
- follower 拿到 LastOffset 之后,会对比当前 LEO 值是否大于 LastOffset,如果当前 LEO 大于 LastOffset,则从 LastOffset 截断日志;
- follower 开始发送 fetch 请求给 leader 保持消息同步。