kafka2.2源码分析之leader epoch_kafka epoch源码详解

概述

Kafka使用HW值来决定副本备份的进度，而HW值的更新通常需要额外一轮FETCH RPC才能完成，故而这种设计是有问题的。它们可能引起的问题包括：

• 备份数据丢失
• 备份数据不一致 

Kafka 0.11版本之后引入了leader epoch来取代HW值。Leader端多开辟一段内存区域专门保存leader的epoch信息，这样即使出现上面的两个场景也能很好地规避这些问题。

EpochEntry

leader epoch实际上是一对值：（epoch，offset）。epoch表示leader的版本号，从0开始，当leader变更过1次时epoch就会+1，而offset则对应于该epoch版本的leader写入第一条消息的位移。因此假设有两对值：

(0, 0)

(1, 120)

则表示第一个leader从位移0开始写入消息；共写了120条[0, 119]；而第二个leader版本号是1，从位移120处开始写入消息。

// Mapping of epoch to the first offset of the subsequent epoch
case class EpochEntry(epoch: Int, startOffset: Long) {
  override def toString: String = {
    s"EpochEntry(epoch=$epoch, startOffset=$startOffset)"
  }
}

LeaderEpochFileCache

leader broker中会保存EpochEntry的缓存，并定期地写入到一个checkpoint文件中。

当leader写底层log时它会尝试更新LeaderEpochFileCache ——如果这个leader首次写消息，则会在缓存中增加一个条目；否则就不做更新。而每次副本重新成为leader时会查询这部分缓存，获取出对应leader版本的位移，这就不会发生数据不一致和丢失的情况。

每个log（一个log有1到多个segment）都有一个记录了leaderEpoch和其startOffset的文件：leader-epoch-checkpoint
log在初始化的时候，会从文件系统加载各种元数据信息，其中一项就是读取leader-epoch-checkpoint文件，建立leaderEpochCache，cache其实就是epoch->startOffset的map

 
/**
 * Represents a cache of (LeaderEpoch => Offset) mappings for a particular replica.
 *
 * Leader Epoch = epoch assigned to each leader by the controller.
 * offset则对应于该epoch版本的leader写入第一条消息的位移
 * Offset = offset of the first message in each epoch.
 *
 * @param topicPartition the associated topic partition
 * @param checkpoint the checkpoint file
 * @param logEndOffset function to fetch the current log end offset
 */
class LeaderEpochFileCache(topicPartition: TopicPartition,
                           logEndOffset: () => Long,
                           checkpoint: LeaderEpochCheckpoint) extends Logging {
//保存EpochEntry的缓存
//读取leader-epoch-checkpoint文件，建立leaderEpochCache
  private var epochs: ListBuffer[EpochEntry] = inWriteLock(lock) { ListBuffer(checkpoint.read(): _*) }
......................
 
}

追加新记录时，如果新的leaderEpoch小于当前cache中最后一个epoch，则添加新的leaderEpoch和该记录的offset（作为epoch的startOffset）到cache，并进行日志截断。

eg:

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(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。

/**
    * Assigns the supplied Leader Epoch to the supplied Offset
    * Once the epoch is assigned it cannot be reassigned
    */
  def assign(epoch: Int, startOffset: Long): Unit = {
    inWriteLock(lock) {
      val updateNeeded = if (epochs.isEmpty) {
        true
      } else {
        val lastEntry = epochs.last
        lastEntry.epoch != epoch || startOffset < lastEntry.startOffset
      }
 
      if (updateNeeded) {
        truncateAndAppend(EpochEntry(epoch, startOffset))
        flush()
      }
    }
  }

日志截断

/**
   * Remove any entries which violate monotonicity following the insertion of an assigned epoch.
   */
  private def truncateAndAppend(entryToAppend: EpochEntry): Unit = {
    validateAndMaybeWarn(entryToAppend)
 
    val (retainedEpochs, removedEpochs) = epochs.partition { entry =>
      entry.epoch < entryToAppend.epoch && entry.startOffset < entryToAppend.startOffset
    }
 
    epochs = retainedEpochs :+ entryToAppend
 
    if (removedEpochs.isEmpty) {
      debug(s"Appended new epoch entry $entryToAppend. Cache now contains ${epochs.size} entries.")
    } else {
      warn(s"New epoch entry $entryToAppend caused truncation of conflicting entries $removedEpochs. " +
        s"Cache now contains ${epochs.size} entries.")
    }
  }

HW会造成数据丢失，指的是即使数据成功入follower副本，还是可能会出现数据丢失。

HW造成数据丢失的条件：

1、producer端min.insync.replicas设置为1，即消息写入leader副本A即为成功。

2、消息也写入follower副本B，但未更新HW值。

3、follower副本B和leader副本A先后宕机。

以上条件造成的结果依次是：

1、消息m被认为是写入成功，不应该出现数据丢失的情况。

2、follower副本B在重启后拿到的是过期的HW，会进行日志截断，丢弃该过期HW之后的消息m；

3、leader副本A宕机，kafka选举B为leader副本，A重启回来后复制B的HW，进行日志截断，丢弃HW之后的消息m；

使用leader epoch复制数据的过程是：

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）。

使用leader epoch不会造成数据丢失的原因是：

1、follower副本B先请求leader副本A的leaderEpoch and Leader LogEndOffset，再从leader副本A复制消息；

2、如果消息写入了follower副本B，则follower副本B的LEO与leader副本的LEO是一致的，对应的offset是最新的，即使此后follow副本B宕机也不受影响。如果消息没写入follower副本B，follower副本B宕机重启后，使用上次分派好的 Leader LogEndOffset，从leader副本A复制消息；

3、如果发生leader切换，B成为leader，则leaderEpoch+1，B根据自身的LEO生成新的Leader LogEndOffset。A称为follower，如果A请求复制B，A发现LEO比leader LEO大，则进行日志截断。

参考：Kafka水位(high watermark)与leader epoch的讨论

Kafka processing OffsetForLeaderEpochRequest