概述
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复制数据的过程是:
- 当leader追加记录时,会为记录分派offset,offset是单调递增的,而且是从当前的logEndOffset开始递增,因此,整个log记录的offset都是单调递增的
- follower从leader复制记录时,不会重新为记录分派offset,而是使用leader已经分派好的,因此follower记录其offset才能跟leader同步
- follower从leader复制记录时,会告诉leader从哪个offset开始复制,如果请求的offset在leader上找不到(offsetOutOfRange),则leader会返回一个错误通知,让follower重新向leader请求可用的offset(earliestOffset, latestOffset)
- 当follower出现offsetOutOfRange错误时,除了重新请求可用的offset外,还需要对自身的log进行truncate,以便和leader同步
- 记录会先写入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大,则进行日志截断。