上一篇【第62篇】Kafka数据不丢失实战指南——生产者、Broker、消费者三端防护
下一篇【第64篇】Kafka消费者可靠性实战——偏移量提交的那些坑
摘要
如果问Kafka最精妙的设计是什么，答案一定是副本机制。只存一份数据等于裸奔，存多份数据又要面对"哪份是最新的"这个分布式经典难题。Kafka的解法另辟蹊径——不追求强一致性，而是通过ISR+Leader Epoch组合拳，在可用性和一致性之间找到了绝妙的平衡点。
本文将深入副本机制的四个核心问题：ISR是怎么维护的（谁进谁出），Leader是怎么选举的（凭什么选它），Follower是怎么同步的（追不上了怎么办），以及HW截断这个"头号坑"是怎么用Leader Epoch填上的。
一、副本机制全景图
先展示副本机制的全貌：
【Kafka 副本架构全景】 Topic: orders, Partition: 0, Replication Factor: 3 ┌─────────────────────────────────────────────────────────┐ │ Kafka Cluster │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Broker 1 │ │ Broker 2 │ │ Broker 3 │ │ │ │ │ │ │ │ │ │ │ │ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │ │ │ │ │Leader │ │ │ │Follower│ │ │ │Follower│ │ │ │ │ │Part.0 │◄─┼───┼──│Part.0 │ │ │ │Part.0 │ │ │ │ │ │ │──┼───┼─►│ │ │ │ │ │ │ │ │ │ │HW=100 │ │ │ │LEO=95 │ │ │ │LEO=100 │ │ │ │ │ │LEO=105 │ │ │ │HW=95 │ │ │ │HW=100 │ │ │ │ │ └────────┘ │ │ └────────┘ │ │ └────────┘ │ │ │ │ ▲ │ │ │ │ │ │ │ │ │读/写 │ │ │ │ │ │ │ └───────┼──────┘ └──────────────┘ └──────────────┘ │ │ │ │ └──────────┼──────────────────────────────────────────────┘ │ Producer ┘ Consumer ──► 只能从 Leader 读 关键概念： LEO (Log End Offset): 日志末尾位置（下一条消息的 offset） HW (High Watermark): 消费者可见的最高 offset（所有ISR都同步到的位置）核心规则：
- 读写都走Leader：Producer写入Leader，Consumer从Leader读取
- Follower只做备份：从Leader拉取数据，只负责备份，不参与读写
- ISR决定选举资格：只有ISR中的副本才能被选为新Leader
二、ISR 的维护机制
2.1 Follower 同步流程
Follower的同步本质上就是不断发FetchRequest，追Leader的日志：
【Follower 同步流程】 Leader (Broker1) Follower (Broker2) ┌──────────────┐ ┌──────────────┐ │ LEO = 105 │ │ LEO = 95 │ │ │ │ │ │ 有10条新消息 │ │ 发 FetchReq │ │ │◄───────────────────│ fetchOffset=95│ │ │ │ │ │ 返回 msg96 │ │ │ │ ~ msg105 │───────────────────►│ 收到10条消息 │ │ │ FetchResponse │ │ │ │ │ LEO → 105 │ │ │ │ │ │ 发 FetchReq │ │ │ │◄──────────────────────────────────│ fetchOffset= │ │ │ │ 105 │ │ 没有新数据 │ │ │ │ 返回空响应 │ │ 等待下一步 │ └──────────────┘ └──────────────┘2.2 ISR 加入和剔除的规则
【ISR 动态维护规则】 ┌────────────────────────────────────────────────────┐ │ ISR 成员判定条件 │ │ │ │ 新加入 ISR: │ │ • Follower 的 LEO ≥ Leader 的 LEO │ │ • （新版 Kafka 还要求待在 ISR 里持续一段时间） │ │ │ │ 移出 ISR: │ │ • Follower 落后于 Leader 的时间超过 │ │ replica.lag.time.max.ms（默认 30 秒） │ │ • 注意：不是条数，是时间！ │ └────────────────────────────────────────────────────┘ T0: Follower LEO=100, Leader LEO=100, ➡ ISR ✓ T1: Leader 写入 500 条，LEO=600 T2: Follower 网络抖动，只拉到 LEO=300 T3: Follower LEO=300, Leader LEO=700 T4: 30 秒过去，Follower 还没追到 LEO=700 T5: Follower 被踢出 ISR ❌ 注意：这里的关键是"时间"，不是"条数"。 即使只差 1 条，30 秒没追上也踢。 即使差了 10000 条，只要能在 30 秒内追上就留。# ISR 相关配置参数 replica.lag.time.max.ms=30000 # Follower 落后多长时间被踢出 ISR replica.fetch.wait.max.ms=500 # Follower 拉取请求的最大等待时间 replica.fetch.min.bytes=1 # Follower 每次拉取的最小字节数 replica.fetch.max.bytes=1048576 # Follower 每次拉取的最大字节数（1MB）三、Leader 选举——谁有资格接管
3.1 选举流程
当Leader宕机时，Controller负责触发Leader重新选举：
【Leader 选举完整流程】 ┌──────────────┐ │ Controller │ (Broker 3) └──────┬───────┘ │ 检测到 Broker1 离线（ZooKeeper Watch 触发） │ ▼ ┌──────────────────────────────────┐ │ Step 1: 获取该 Topic/Partition │ │ 的 AR 列表和 ISR 列表 │ │ │ │ AR = [Broker1, Broker2, Broker3] │ │ ISR = [Broker1, Broker2] │ │ (Broker1 已挂，ISR 剩 Broker2) │ └────────────┬─────────────────────┘ │ ▼ ┌──────────────────────────────────┐ │ Step 2: 在 ISR 中选择新 Leader │ │ │ │ 策略 (PartitionLeaderSelector): │ │ • OfflinePartitionLeaderSelector│ │ → 按 AR 顺序，选第一个在线 │ │ 且属于 ISR 的副本 │ │ • 其他策略（按机架感知等） │ │ │ │ 选中 Broker2 → 成为新 Leader │ └────────────┬─────────────────────┘ │ ▼ ┌──────────────────────────────────┐ │ Step 3: 通知所有相关 Broker │ │ │ │ → 新 Leader (Broker2): │ │ "你现在是 orders-0 的Leader了" │ │ → 内部角色为 Leader │ │ → 开始接收 Producer 写入 │ │ │ │ → 其他 Follower (Broker3): │ │ "Broker2 是你新的 Leader" │ │ → 切换到新的 Leader 拉取数据 │ │ │ │ → 所有 Broker 更新元数据缓存 │ │ → Producer/Consumer 在下个 │ │ metadata refresh 周期感知 │ └──────────────────────────────────┘3.2 选举策略的选择
// Controller 源码中的选举逻辑（简化版）classPartitionLeaderSelector{// 默认策略：选 AR 列表中第一个在 ISR 中且存活的副本defselectLeader(partition:TopicPartition,isr:Set[Int],liveReplicas:Set[Int]):Int={// 1. 按 AR 顺序，第一个在线且在 ISR 里的val assignedReplicas=controllerContext.partitionReplicaAssignment(partition)assignedReplicas.find{replica=>isr.contains(replica)&&liveReplicas.contains(replica)}.getOrElse{// 2. 如果 ISR 里没人在线 → 抛异常或选不干净的Leaderif(config.uncleanLeaderElectionEnable){// 危险！选一个不在 ISR 但还活着的副本assignedReplicas.find(liveReplicas.contains).get}else{thrownewNoReplicaOnlineException()}}}}3.3 选举速度——受控状态转换
Kafka控制着Leader选举的速度，防止"全员同时竞选"：
# Controller 端参数 # Leader选举的最大速率（每秒钟的选举数） # 默认限制，防止批量宕机时所有分区同时选举 controller.election.rate.limit=100四、HW (High Watermark) 与 LEO
4.1 HW 的作用
【HW 的作用】 HW = High Watermark（高水位线） LEO = Log End Offset（日志末尾偏移量） 关键规则： • 消费者只能读到 offset < HW 的消息 • HW 由所有 ISR 副本中最小的 LEO 决定 示例： ┌──────────────────────────────────┐ │ Partition 0 │ │ │ │ Offset: 0 1 2 3 │ │ ┌───┐ ┌───┐ ┌───┐ ┌───┐│ │ Leader: │m0 │ │m1 │ │m2 │ │m3 ││ LEO=4 │ └───┘ └───┘ └───┘ └───┘│ │ │ │ Follower1: m0, m1, m2 │ LEO=3 │ Follower2: m0, m1, m2, m3 │ LEO=4 │ │ │ min(LEO) = 3 → HW = 3 │ │ 消费者最多读到 offset=2 的消息 │ │ offset=3 (m3) 尚未被所有ISR确认 │ └──────────────────────────────────┘ HW 保证了消费者读到的数据一定是"ISR 全员同步过"的4.2 HW 截断问题——著名的坑
这也是副本机制中最著名的问题：
【HW 截断问题图解】 初始状态： ┌──────────────────────────────────────┐ │ Broker1 (Leader) Broker2 (Follower) │ │ LEO=5, HW=5 LEO=5, HW=5 │ │ msg1~5 全在 ISR │ └──────────────────────────────────────┘ Step 1: Broker1 写入 msg6, msg7 ┌──────────────────────────────────────┐ │ Broker1 (Leader) Broker2 │ │ LEO=7, HW=5 LEO=5, HW=5 │ │ msg6~7 还没同步 ← HW 还没提升 │ └──────────────────────────────────────┘ Step 2: Broker2 拉取 msg6 ┌──────────────────────────────────────┐ │ Broker1 (Leader) Broker2 │ │ LEO=7, HW=5 LEO=6, HW=5 │ └──────────────────────────────────────┘ Step 3: Broker1 的 HW 推进到 6 ┌──────────────────────────────────────┐ │ Broker1 (Leader) Broker2 │ │ LEO=7, HW=6 LEO=6, HW=6 │ └──────────────────────────────────────┘ Step 4: Broker1 挂了！Broker2 被选为新 Leader ┌──────────────────────────────────────┐ │ Broker1 💀 Broker2 (新Leader)│ │ LEO=6, HW=6 │ │ msg7 丢了 消费者看到哪？ │ └──────────────────────────────────────┘ 问题：Producer 以为 msg6 成功了（因为 HW=6 了） 但 Broker1 的 msg7 没了 不过 msg6 还在 Broker2 上，没丢 真正的问题场景是： 新Leader（Broker2）只有 msg1~6，有个Follower3有 msg1~7 → Follower3 需要截断到 msg1~6（因为新Leader没有msg7） → Follower3 的 msg7 被截掉 → 但 msg7 旧 Leader 已经确认过了！4.3 Leader Epoch —— 终极解决方案
Kafka 0.11 引入了Leader Epoch机制来解决HW截断：
【Leader Epoch 工作原理】 概念： • Leader Epoch: 单调递增的"Leader 任期号" • 每次 Leader 变更，epoch +1 • 每个 Leader 将 epoch 对应的起始 offset 记录到日志中 没有 Leader Epoch 时： ┌────────────────────────────────────────────┐ │ Follower 恢复： │ │ "我的 HW=5 → 恢复到 5" │ │ 错了！新 Leader 可能只有 4！ │ │ → 截断错误，数据丢失！ │ └────────────────────────────────────────────┘ 有 Leader Epoch 时： ┌────────────────────────────────────────────┐ │ Follower 恢复： │ │ "我的 epoch=3 → 查新 Leader epoch=3 的 │ │ 起始offset → 是 5 → 截断到 5" │ │ │ │ 新 Leader 响应（LeaderEpoch=4）: │ │ "LeaderEpoch=3 的起始 offset 在我这里是 4" │ │ → Follower 截断到 4，与新 Leader 一致 ✓ │ └────────────────────────────────────────────┘【Leader Epoch 与日志截断】 旧 Leader (B1): epoch=0 epoch=1 ┌──────────────────┐ ┌───────────┐ ┌───────────┐ │ msg0 msg1 msg2 │ │ msg3 msg4 │ │ msg5 msg6 │ ← 有 msg6 │ offset: 0 1 2│ │ 3 4 │ │ 5 6 │ └──────────────────┘ └───────────┘ └───────────┘ 新 Leader (B2): epoch=0 epoch=1 ┌──────────────────┐ ┌───────────┐ ┌──────┐ │ msg0 msg1 msg2 │ │ msg3 msg4 │ │ msg5 │ ← 没有 msg6 │ offset: 0 1 2│ │ 3 4 │ │ 5 │ └──────────────────┘ └───────────┘ └──────┘ B1 恢复后： 1. 向 B2 请求 epoch=1 的 offset 范围 2. B2 回复：epoch=1 的 offset 范围是 [3, 6) → 最后一条是 msg5 3. B1 发现自己的 epoch=1 有 msg6（超出 B2 的范围） 4. B1 截断到 offset=5（和 B2 一致） 5. 变成 B2 的 Follower，继续同步五、副本性能对写入的影响
5.1 多副本写入的延迟边界
【acks=all 下的写入延迟分析】 场景：RF=3, ISR=[B1, B2, B3], acks=all Producer → B1(Leader) → B1写入(msg) → 立即同步给B2,B3 │ ├── B2 写入 ────┐ │ │ 等最慢的那个 ├── B3 写入 ────┤ 确认 │ │ └── 全部确认 ◄───┘ ↓ 返回 ACK 给 Producer 延迟 = max(B1写入, B2写入, B3写入) ≈ 最慢的Follower的写入延迟 这也是为什么 ISR 能及时剔除慢副本如此重要： 慢 Follower 会拖慢整个写入过程5.2 副本数与吞吐量的关系
| RF | ISR延迟 | 写入吞吐 | 数据安全 |
|---|---|---|---|
| 1 | 0ms（无副本开销） | 100% | 0 安全 |
| 2 | +2ms | 98% | 低 |
| 3 | +3~5ms | 95% | 高 |
| 5 | +8~10ms | 90% | 很高（多机房） |
本篇小结
Kafka的副本机制是可靠性的基石，核心要点总结：
- ISR维护：按时间（非条数）判定同步状态，落后超过
replica.lag.time.max.ms（30秒）即移除 - Leader选举：Controller从ISR里选第一个在线的副本，
unclean.leader.election.enable=true会从OSR选（危险） - HW与LEO：HW是所有ISR中最小的LEO，消费者只能读到HW之前的数据
- Leader Epoch：解决了HW截断问题，用任期号精确指导日志截断
记住：副本多 → 数据安全但写入慢，副本少 → 写得快但风险高。RF=3 + min.isr=2 依然是黄金配置。
下一篇，我们将聚焦消费者端的可靠性——那些关于偏移量提交的坑，一篇文章帮你全部填平。
上一篇【第62篇】Kafka数据不丢失实战指南——生产者、Broker、消费者三端防护
下一篇【第64篇】Kafka消费者可靠性实战——偏移量提交的那些坑
