leader epoch

更多内容，前往 IT-BLOG

leader epoch 代表 Leader 的纪元信息（epoch），初始值为0。每当 Leader 变更一次，leader epoch 的值就会加1，相当于为 Leader 增设了一个版本号。每个副本中还会增设一个矢量 <LeaderEpoch >= StartOffset>，其中 StartOffset 表示当前 LeaderEpoch 下写入的第一条消息的偏移量。

假设有两个节点A 和 B，B是 leader节点，里面的数据如图：
​
A发生重启之后，A不是先忙着截断日志而是先发送 OffsetsForLeaderEpochRequest请求给B，B作为目前的 Leader在收到请求之后会返回当前的 LEO（LogEndOffset，注意图中 LE0和 LEO的不同），与请求对应的响应为OffsetsForLeaderEpochResponse。如果 A 中的 LeaderEpoch（假设为 LE_A）和 B 中的不相同，那么 B 此时会查找 LeaderEpoch 为 LE_A+1 对应的 StartOffset 并返回给 A
​
如上图所示，A 在收到2之后发现和目前的 LEO 相同，也就不需要截断日志了，以此来保护数据的完整性。

再如，之后 B 发生了宕机，A 成为新的 leader，那么对应的 LE=0 也变成了 LE=1，对应的消息 m2 此时就得到了保留。后续的消息都可以以 LE1 为 LeaderEpoch 陆续追加到 A 中。这个时候A就会有两个LE，第二 LE所记录的 Offset从2开始。如果B恢复了，那么就会从 A中获取到 LE+1的 Offset为 2的值返回给B。
​
再来看看 LE如何解决数据不一致的问题：当前 A 为 Leader，B 为 Follower，A 中有2条消息 m1 和 m2，而 B 中有1条消息 m1。假设 A 和 B 同时“挂掉”，然后 B 第一个恢复过来并成为新的 leader。
​
之后 B 写入消息 m3，并将 LEO 和 HW 更新至2，如下图所示。注意此时的 LeaderEpoch 已经从 LE0 增至 LE1 了。
​
紧接着 A 也恢复过来成为 Follower 并向 B 发送 OffsetsForLeaderEpochRequest 请求，此时 A 的 LeaderEpoch 为 LE0。B 根据 LE0 查询到对应的 offset 为1并返回给 A，A 就截断日志并删除了消息 m2，如下图所示。之后 A 发送 FetchRequest 至 B 请求来同步数据，最终A和B中都有两条消息 m1 和 m3，HW 和 LEO都为2，并且 LeaderEpoch 都为 LE1，如此便解决了数据不一致的问题。

​​​