Kafka processing OffsetForLeaderEpochRequest

What’s LeaderEpochCache?

1. 每个log（一个log有1到多个segment）都有一个记录了leaderEpoch和其startOffset的文件：leader-epoch-checkpoint
2. log在初始化的时候，会从文件系统加载各种元数据信息，其中一项就是读取leader-epoch-checkpoint文件，建立leaderEpochCache，cache其实就是epoch->startOffset的map
3. leaderEpochCache在log的整个生命周期中会不停变化：
   3.1 追加新记录时，如果记录中包含的leaderEpoch大于当前cache中最后一个epoch，则添加新的leaderEpoch和该记录的offset（作为epoch的startOffset）到cache
   3.2 log被定时删除记录后，log的startOffset会增大，则cache中offset小于startOffset的项会被删除
   3.3 log被整个truncate，则cache会被清空
   3.4 log被truncate到某个位置（truncatePoint），则cache中offset大于该truncatePoint的项会被删除

What’s leaderEpoch?

1. 每个topicPartition会对应1到多个Broker（kafka server）节点，节点数由topic的replicationFactor控制，所以这些Broker也被称之为topicPartition的replica
2. KafkaController会在topicPartition的所有replica中，选举一个节点作为leader，其余节点（replicationFactor>1）则成为follower
3. 由于各种原因，replica不可能总是正常运行，所以leader也会出现挂掉的情况，因此KafkaController会在leader挂掉的时候从follower中重新选择一个replica成为新leader
4. 为了区分leader的新旧，必须产生一个唯一的标识，因此KafkaController为每个新leader绑定了一个单调递增的id，称之为epoch（主要是为了在zookeeper上同步信息时，防止旧leader恢复然后执行和新leader一样的操作，具体可以查看zk的相关文档）

Premises

1. 当leader追加记录时，会为记录分派offset，offset是单调递增的，而且是从当前的logEndOffset开始递增，因此，整个log记录的offset都是单调递增的
2. follower从leader复制记录时，不会重新为记录分派offset，而是使用leader已经分派好的，因此follower记录及其offset才能跟leader同步
3. follower从leader复制记录时，会告诉leader从哪个offset开始复制，如果请求的offset在leader上找不到（offsetOutOfRange），则leader会返回一个错误通知，让follower重新向leader请求可用的offset（earliestOffset， latestOffset）
4. 当follower出现offsetOutOfRange错误时，除了重新请求可用的offset外，还需要对自身的log进行truncate，以便和leader同步
5. 记录会先写入leader，再写入follower（不论记录的ACK是什么都一样），即leader的logEndOffset会比follower的要大（出现leader切换时例外，因为有可能选举了一个offset较小的follower成为新leader），另外，follower之间的offset也不尽相同（最终会一致，但是过程中会有差异）。如果这时出现leader切换，则新leader的log会成为标准，follower必须跟它同步。但是这个新leader的log可能还没有follower的多（即logEndOffset还要比其他follower的要小），因此，follower需要进行truncate才能与leader实现最终同步（旧leader如果恢复过来，也会成为follower）。

What’s leaderEpoch’s startOffset?

follower如何跟leader同步？通过复制过程，每次复制follower都会告诉leader一个开始复制的offset和其对应的epoch

1. 没有新记录追加时，如果新leader的logEndOffset比follower请求的offset大，则复制照样进行（相等就不用复制）
2. 没有新记录追加时，如果新leader的logEndOffset比follower请求的offset小，则告诉follower offsetOutOfRange，follower知道后就会重新计算可用的offset，并truncate自身的log
3. 当有新记录追加时，新leader会为记录分派offset（从自身的logEndOffset开始单调递增），并把第一条记录的offset作为新的leaderEpoch的startOffset。follower请求复制数据时，新leader就把follower请求的epoch和新的leaderEpoch进行对比：
   3.1 如果相等则返回新leader的logEndOffset（follower收到后会跟自己的请求offset做对比，取较小值）；
   3.2 如果不相等，则根据请求的epoch，在所有比它大的leaderEpoch（cache中有多个leaderEpoch和startOffset对）中找出最小的一个，返回其对应的startOffset（follower收到后就会检查是否需要truncate）；
   3.3 如果cache中没有找到，则通知follower重新获取可用的offset并检查是否truncate。
4. 由此可见，leaderEpoch和startOffset的存在，才能使得各个follower和leader之间的数据最终保持一致

Examples

A(leader, epoch=1): 1, 2, 3, 4, 5, 6
A cache: leaderEpoch = 1, startOffset = 1

B(follower): 1, 2, 3, 4
B cache: leaderEpoch = 1, startOffset = 1

B从A复制

---

A(follower, after offline): 1, 2, 3, 4, 5, 6
A cache: leaderEpoch = 1, startOffset = 1

B(leader, epoch=2): 1, 2, 3, 4
B cache: leaderEpoch = 1, startOffset = 1

A挂掉后，B成为新leader，A又恢复过来，此时还没有新记录追加，leaderEpochCache没有新增条目。
当A请求复制B时，就会出现offsetOutOfRange，然后A重新获取B的latestOffset为4，A truncate自己的5和6
C则继续从B复制

---

A(follower, after offline): 1, 2, 3, 4, 5, 6
A leaderEpoch = 1, startOffset = 1

B(leader, epoch=2): 1, 2, 3, 4, 5, 6, 7
B cache:
leaderEpoch = 1, startOffset = 1
leaderEpoch = 2, startOffset = 5、

A挂掉后，B成为新leader，A又恢复过来，此时追加了新数据，B的leaderEpochCache增加了新条目（leaderEpoch=2, startOffset=5）。
当A请求复制B时，请求的epoch为1，B查询到epoch=2（比1大的最小epoch），然后返回对应的startOffset=5，A收到后truncate自己>=5的记录（这里是offset=5和6），然后把请求的offset更新为5，重新复制数据，B返回数据（offset=5, 6 和7，epoch=2），A追加记录时发现数据的epoch=2，新增条目（epoch=2, startOffset=5）到自己的leaderEpochCache。

处理流程图：