[转帖]Kafka可靠性之HW与Leader Epoch

《深入理解Kafka：核心设计与实现原理》是基于2.0.0版本的书

在这本书中，终于看懂了笔者之前提过的几个问题

准备知识

1、leader里存着4个数据：leader_LEO、leader_HW、remote_LEO集合、remote_HW集合

2、follower里只保存自身的：follower_LEO、follower_HW

HW和LEO更新过程

假设：

1个leader 和 2个follower

此时：leader_LEO = 5、leader_HW = 0、所有 follower 的 follower_LEO = 0、follower_HW = 0

同步开始

1、follower向leader发送fetch请求，来拉取消息，这个fetch请求会带上各自的follower_LEO

（先省略leader处理fetch请求的过程）

2、leader接收fetch请求后，处理并返回，这个fetch请求的响应会带上 leader_HW

3、follower拿到了fetch请求的response，同步消息数据，更新自己的 follower_LEO

（假设此时 这2个 follower_HW 分别为3和4）

4、接下来计算一下 follower_HW 并更新

公式：follower_HW = min(leader_HW，follower_LEO) 

所以 两个follower此时的 follower_HW 都是 min(0，0) = 0

5、follower再次发送fetch请求，并带上各自的 follower_LEO

6、leader处理fetch请求过程如下

把这2个 follower_LEO 加上自己的 leader_LEO，取最小值作为新的 leader_HW

公式：leader_HW = min(leader_LEO，RemoteIsrLEO)

（RemoteIsrLEO：ISR中的所有follower的follower_LEO）

leader_HW = min(l5，3，4) = 3

7、leader_HW = 3 被 fetch请求的response带上，返回

8、2个follower收到response后，依然是，同步消息数据，更新 follower_LEO，更新 follower_HW

（假设此时 这2个 follower_HW 分别更新至 6和8）

follower_HW1 =  min(3，6) = 3

follower_HW2 =  min(3，8) = 3

（leader在上面几张图分别等于5、10、15、20的意思是，在上述过程中，leader一直接收着producer的消息数据）、

为什么follower_HW = min(leader_HW，follower_LEO) ？

因为这个follower没说是哪里的follower。

当然对于ISR中的follower根本不必多此一举，其实直接 follower_HW = leader_HW 就可以

但是对于OSR中正在拼命追赶leader的follower，它的follower_LEO可能小于leader_HW

所以公式为什么是公式，原因就在这。

如图为笔者的理解。

至于很多博客，说什么谁大谁小，谁一定小于谁，谁一定小于等于谁。

不加限定条件你说NM呢？HW和LEO多了去了，谁知道你说的是哪个和哪个比？

HW更新的问题

大家仔细观察上图

这幅图展示的是follower接收到了fetch请求的response，更新了各自的follower_LEO和follower_HW

问题在哪？

leader 中有数据 offset 0-9

follower1 中有数据 offset 0-2

follower2 中有数据 offset 0-3

现在是不是offset 0-2这3个消息是ISR中所有replica中都有了，这是不是完全同步了。

既然是，为什么HW不更新成3？offset 0-2这3条数据此时，按理说就应该可以被consumer消费了。

但是并没有，HW更新为3是下一次fetch请求响应都结束后，leader_HW和follower_HW才更新成3的。

remote_LEO、leader_HW、follower_HW的更新发生于follower_LEO更新后的第二轮fetch请求。

说人话就是：

消息数据已经完全同步了，但是HW的更新比消息晚了一次请求。

也可以理解为HW的更新是异步的。

因为按照我们的认知，既然消息已经在ISR完全同步成功后，应该立马可以消费，或者说，消息和HW应该同步更新。

也正因为不是这样的，所以才会出现数据丢失和数据一致性的问题。

HW的截断

假设此时的状态是 HW= 5，即：offset = 0～4的消息对于consumer可见

此时leader宕机，follower1选举为leader，leader重启成为follower。

原则就是：一切以leader为准，新follower此时会根据之前 HW 位置进行日志截断，并重新发起fetch请求追赶。

（这个值会存入本地的复制点文件 replication-offset-checkpoint ）

那么新follower最多能追到offset=6，这是不是说明offset=7的消息就丢了。

不是的，这种情况就是正常的情况，因为offset=7这个消息并未“完全同步”，这个消息根本没有写入成功，何谈丢消息。

如图，如果offset=5的消息丢了，那才是真正的丢消息。

HW机制之丢失消息

在 0.11.0.0 版本之前， Kafka使用的是基于HW的同步机制，

但这样有可能出现数据丢失或leader副本和follower副本数据不一致的问题。

官方已经自己给出例子说明了

https://cwiki.apache.org/confluence/display/KAFKA/KIP-101+-+Alter+Replication+Protocol+to+use+Leader+Epoch+rather+than+High+Watermark+for+Truncation

简言之，既然消息数据和HW是异步更新的，

那么你一定能找出某种场景：让已经实现“完全同步”但HW没来得及更新的消息丢失。

1、此时leader收到fetch请求，没有消息要同步了，返回leader_HW=2

follower接到response，再更新follower_HW = 2就OK了。

删除线部分并没有发生，而是follower宕机了，此时再次重启follower，重启之后会根据之前 HW 位置进行日志截断 。

好的，此时follower上的offset=1的消息没了。

2、follower截断日志后，应该去追赶leader，先一次fetch，从新把offset=1的消息拿过来，再一次fetch，把HW更新为2

删除线部分依然没发生，而是leader宕机了，follower成了新leader，重启旧leader成为了follower。

3、follower_HW不能比leader_HW 大，必须以leader为准，所以还会做一次日志截断，以此将follower_HW调整为 1

至此，offset=1的消息就被玩没了。

HW机制之数据不一致

场景：leader有 2 条消息，且 HW 和 LEO 都为 2, follower有 1 条消息，且 HW 和 LEO 都为 1

1、leader和follower同时宕机，follower率先复苏，成为新leader，并接收一个消息m

并将LEO和HW更新至 2 （假设所有场景中的 min.insync.replicas 参数配置为 1)

2、旧leader重启，成为follower，需要根据 HW 截断日志及发送 FetchRequest 至新leader ，

不过此时HW相等，那么就可以不做任何调整了。

至此，数据就不一致了。

leader epoch 方案

Kafka 从 0.11.0.0 开始引入了 leader epoch 的概念，

笔者总结的核心思路

1、在需要截断数据的时候使用 leader epoch 作为参考依据而不是原本的 HW

2、leader epoch 把他比喻成 时代、朝代 都可以，就是为了比较，follower和leader是不是处于一个朝代的

（方唐镜：包大人你好大的官威啊，拿前朝的剑斩本朝的官!）

3、如果处于同时代，follower的LEO对比leader的LEO，follower落后就不用截断，超过就自行了断。

4、如果处于不同时代，// TODO

存储位置和segment是一起的，文件名：leader-epoch-checkpoint

文件内容分两列

第一列：leader的版本号，每当leader出现变更就会追加一条记录，版本号+1

第二列：这个leader上任后，写入的第一条数据的offset

# 说明leader的0代目，写下了offset 0～99 = 100 条消息，之后当场去世





# 1代目，从offset = 100 开始写入，目前还没死





0 0





1 100

leader epoch 的作用

在日志截断之前，加一层判断是否有必要截断。而这个判断的依据就是leader epoch

当replica成为leader时

收到生产者发来的第一条消息时，会将新的epoch和当前LEO添加到leader-epoch-checkpoint文件中。

当replica成为follower时

(epoch太别扭了，以下都用version代替)

0、先不急着截断

1、向leader发送请求，带上follower当前本地的最新epoch，也就是文件中的那个最大版本号 follower_max_version

2、leader接收请求，需要进行一下计算，并返回一个last_offset值

如果 follower_max_version = leader_max_version，last_offset = leader_LEO

如果不相等，leader就取 follower_max_version+1 这个版本对应的start_offset 当作 last_offset

3、follower拿到response里的 last_offset 进行判断

如果 last_offset  < follower_LEO，需要进行截断

否则不需要

4、开始fetch请求

笔者的疑问

很奇怪，说到last_offset的判断时，书里也只说了相等或不相等，很多看似华丽的博客完全都是copy书上的，一点没改。

按理来说，不应该区分以下谁大谁小么？

不相等，为什么能保证一定能取到  follower_max_version+1 的数据呢？

会不会有的follower的follower_max_version比leader中的还大，这个不得而知。

【如果不相等，leader就取 follower_max_version+1 这个版本对应的start_offset 】

你怎么就知道 follower_max_version 一定比leader的小呢？

———————————————以下是笔者的假设———————————————————

假设，一个leader，目前为止还没写入过消息，所有replica的leader epoch 都是一样的，等于2。

此时，这个leader收到了producer的一条数据，记录了leader epoch，假设为3。

然后他马上宕机，此时其他的follower的 leader epoch还都是2（这就是问题所在，这个epoch到底是怎么同步的）

有一个follower选举为leader，且一直没有producer发消息，这个新leader的 leader epoch 也是2，

这是旧的leader重启成为follower，那么此时是不是follower的leader epoch比新leader的大了呢？

——————————————————————————————————————————

笔者仔细看了官方的文档，借助谷歌翻译，大概能知道为了保持leader epoch的同步，Kafka一定做了某些处理方案，

但是具体的看不懂。

而对于，两本书中都提到的“不等于”、“否则”，哎，不等于到底是大于还是小于啊？

如果在leader中一定能找到 follower_max_version+1 的 epoch，那为什么用不等于这种模棱两可的表达呢？

文章知识点与官方知识档案匹配，可进一步学习相关知识

云原生入门技能树首页概览13727 人正在系统学习中