Kafka副本备份机制（LEO，HW，leader epoch）
Kafka 0.11版本之前水印副本备份机制
步骤：
-
初始leader,follower参数都为0，其中leader中的remote LEO记录的是follower的LEO
-
生产者发送消息m1到leader中，更新leader的LEO为1
-
follower fetch leader,follower写入日志，更新follwer的LEO为1
-
follower再次fetch leader,leader接受到以后，更新leader中的remote LEO为1，并更新HW（取leader中的LEO，remote LEO 最小值）为1，
follower获取fetch返回信息，leader的HW为1，更新follower自身的HW为1。
更新HW，需要额外的一轮fetch rpc请求。
水印备份机制缺陷
数据丢失
数据不一致/离散
造成上述两个问题的根本原因在于HW值被用于衡量副本备份的成功与否，但HW值的更新是异步延迟的，特别是需要额外的FETCH请求处理流程才能更新，故这中间发生的任何崩溃都可能导致HW值的过期。鉴于这些原因，Kafka 0.11引入了leader epoch来取代HW值。
leader epoch
Kafka 引入了 leader epoch 机制，在每个副本日志目录下都创建一个 leader-epoch-checkpoint 文件，用于保存 leader 的 epoch 信息，如下，leader epoch 长这样：
它的格式为 (epoch offset)，epoch指的是 leader 版本，它是一个单调递增的一个正整数值，每次 leader 变更，epoch 版本都会 +1，offset 是每一代 leader 写入的第一条消息的位移值，比如：
(0, 0)
(1, 300)
以上第二个版本是从位移300开始写入消息，意味着第一个版本写入了 0-299 的消息。
leader epoch工作机制
1）当副本成为 leader 时：
这时，如果此时生产者有新消息发送过来，会首先新的 leader epoch 以及 LEO 添加到 leader-epoch-checkpoint 文件中。
2）当副本变成 follower 时：
- 发送 LeaderEpochRequest 请求给 leader 副本，该请求包括了 follower 中最新的 epoch 版本；
- leader 返回给 follower 的相应中包含了一个 LastOffset，如果 follower last epoch = leader last epoch，则 LastOffset = leader LEO，否则取大于 follower last epoch 中最小的 leader epoch 的 start offset 值，举个例子：假设 follower last epoch = 1，此时 leader 有 (1, 20) (2, 80) (3, 120)，则 LastOffset = 80；
- follower 拿到 LastOffset 之后，会对比当前 LEO 值是否大于 LastOffset，如果当前 LEO 大于 LastOffset，则从 LastOffset 截断日志；
- follower 开始发送 fetch 请求给 leader 保持消息同步。
解决数据丢失
解决数据不一致/离散
参考
Kafka水位(high watermark)与leader epoch的讨论
原文地址：http://www.cnblogs.com/hongdada/p/16918984.html
