Kafka通过HW（高水位）和LEO（日志末端位移）保障主从一致性：HW取ISR中所有副本最小LEO，标识消费者可读取的最大位移；Broker强制截断HW之后消息，确保只暴露已同步数据；HW随ISR副本LEO渐进更新，故障切换时自动截断未同步消息，由服务端闭环控制，Java客户端无需干预。
Java 中 Kafka 利用 HW 和 LEO 实现主从复制下的一致性保障，核心在于“只让消费者读取已同步到所有 ISR 副本的数据”。这不是靠客户端代码主动判断，而是由 Kafka 服务端严格控制可见边界——消费者拉取时，Broker 自动截断超过 HW 的消息，根本不会返回。
HW 是分区数据可见性的唯一权威
消费者（无论用 KafkaConsumer 还是 Spring Kafka）发起 fetch 请求时，Broker 返回的消息范围始终是 offset < 分区 HW。即使 Leader 副本本地已写入 offset=100 的消息，只要 HW 还停留在 92，offset=92～99 的消息就对所有消费者不可见。这个限制在服务端强制执行，Java 客户端无需、也无法绕过。
关键点：
- 分区 HW 取值为当前 ISR 中所有副本（含 Leader）的最小 LEO；
- ISR 列表由 Kafka 动态维护，Follower 落后太多（如超 replica.lag.time.max.ms）会被踢出；
- 只有仍在 ISR 中的副本，其 LEO 才参与 HW 计算，保证“已提交”意味着至少被多数副本持久化。
LEO 驱动 HW 的渐进式更新
HW 不会实时跟随每条消息更新，而是在副本间同步过程中逐步推进。Java 应用无需干预，但理解流程有助于排查延迟问题：
立即学习“Java免费学习笔记（深入）”；
- Producer 发送消息 → Leader 写入本地日志 → Leader LEO +1；
- Follower 定期向 Leader 发 FetchRequest，携带自身当前 LEO；
- Leader 收到请求后，用所有 ISR 副本（包括自己）的 LEO 算出新 HW = min(LEO₁, LEO₂, …)；
- Leader 在 FetchResponse 中把新 HW 值返回给 Follower；
- Follower 收到响应后，将自己的 HW 更新为 min(自身原 LEO, Leader 返回的 HW)，再追加消息并更新自身 LEO。
这个过程确保：HW 永远 ≤ 所有 ISR 副本的 LEO，且只增不减。
故障切换时 HW 保护数据不丢失
当 Leader 崩溃，新 Leader 从 ISR 中选出（比如原 Follower A）。此时若 A 的 LEO 小于旧 Leader，它成为新 Leader 后，分区 HW 会立即回落到 A 的 LEO（因为 HW = min ISR-LEO）。旧 Leader 上 HW 之后、但未同步到 A 的消息会被截断（truncation）。
对 Java 应用的影响：
- 消费者不会看到被截断的消息——它们从未达到 HW，本来就不曾对外可见；
- Producer 若配置 acks=all，那些未达 HW 的消息会收到 NotEnoughReplicasException 或 TimeoutException，应用需重试；
- Spring Kafka 中可通过 @KafkaListener 的 error handler 捕获这类异常，避免静默丢数据。
开发中可观察但不可修改
Java 程序员不能也不应手动设置 HW 或 LEO。但可通过以下方式观测其状态，辅助调优：
- 使用 AdminClient.listOffsets() 查询某分区的 LOG_END_OFFSET（即 Leader LEO）；
- 通过 JMX 指标 kafka.log:type=Log,name=LogEndOffset,topic=xxx,partition=0 获取实时 LEO；
- 监控 kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions 查看是否有分区 ISR 缩小，间接反映同步滞后；
- Consumer 的 position() 返回的是已提交位移，天然受 HW 约束，无需额外校验。
本质上，HW/LEO 是 Kafka 内核的水位标尺，Java 客户端只需按协议消费，一致性由 Broker 层闭环保障。
