Kafka

HW、LEO、LeaderEpoch 完整原理

·5 分钟阅读·1621 字
kafkamessage-queue

Kafka 组件/原理详解

📋 目录

一、基础定义

作用：控制消息对外可见边界、副本日志截断、保证多副本数据一致性，配合ISR实现高可用。

1.LEO（Log End Offset）

每个副本（Leader/Follower）独立维护，LEO = 当前副本日志最后一条消息Offset + 1，代表下一条待写入消息的位置。

  • Leader收到生产消息落盘 → Leader.LEO自增；
  • Follower拉取完一批日志写入本地 → Follower.LEO同步上涨。

2.HW（High Watermark，高水位）

同一个分区HW = ISR集合内所有副本LEO的最小值。

  • HW之前的数据：全ISR副本已同步完毕，消费者可以正常消费；
  • HW ~ Leader.LEO区间：数据仅存在Leader本地、Follower未同步，消费者无法读取。

3.Leader Epoch（Leader纪元，0.11版本修复日志截断BUG）

每次分区切换新Leader时生成一个自增Epoch编号，每条日志物理存储携带当前Epoch；
用来解决老版本宕机后Follower错误删有效日志、数据丢失问题。

二、正常同步流程举例

分区3副本：Leader(B1)、F1(B2)、F2(B3)，同在ISR

  1. Leader写入3条消息：Leader_LEO=3
  2. F1拉取2条：F1_LEO=2；F2拉取1条：F2_LEO=1
  3. ISR最小LEO=1 → HW=1
  • offset 0、1：全副本落盘，可消费；
  • offset 2：只在Leader，不可消费。
  1. F2继续同步到3，三者LEO都=3 → HW更新为3。

三、Follower同步与ISR收缩

Follower长时间（replica.lag.time.max.ms）追赶不上Leader，被踢出ISR变为OSR，计算HW不再参考该副本LEO。
例：F2掉线掉队退出ISR，只剩Leader、F1在ISR，HW取min(3,2)=2。

四、故障宕机 & HW数据保护机制

场景1：原Leader宕机，从ISR挑选新Leader

新上任Leader只能以本机HW作为对外服务起点，截断本机HW之后未同步的日志，对外只提供HW之前数据。

设计目的：保证新Leader对外的数据全副本落地，不会对外暴露只有单副本的数据。

老版本无LeaderEpoch漏洞

旧版无Epoch，新Leader上任后，旧Leader重启加回集群，旧Leader会以新Leader的HW强制截断自身有效日志，造成数据永久性丢失；LeaderEpoch诞生就是修复该缺陷。

五、LeaderEpoch工作机制

  1. Leader变更 → 生成新Epoch，记录【Epoch：起始Offset】存入分区元数据；
  2. Follower和Leader建立连接时，先同步Epoch列表，对比各自日志末尾Epoch；
  3. 如果Follower末尾Epoch < Leader对应Epoch：Follower直接截断到该Epoch起始Offset，再增量拉取日志；
    杜绝盲目大范围删日志。

六、acks参数和HW联动

  1. acks=all：消息必须同步到全部ISR副本、所有副本LEO上涨、HW抬升后，生产者才收到成功ACK；
  2. acks=1：Leader本地落盘即返回，不等Follower同步，HW后续异步抬升，存在Leader瞬间宕机丢未同步消息风险。

七、面试易错点梳理

  1. HW是分区全局属性，一个分区只有一个HW；LEO每个副本各自独立；
  2. HW永远不可能超过任意一个ISR副本的LEO；
  3. LeaderEpoch不存储在消息体，存在分区checkpoint文件。

关联文档

返回首页订阅更新