HW重要特性与保障
1. 数据一致性保障
HW 机制确保了消费者在所有副本上看到的数据是一致的。无论消费者连接到哪个副本（Leader 或 Follower），它都只能读到 HW 之前的消息。
2. 数据不丢失的保证
只有 HW 之前的消息才被认为是 "已提交（Committed）"。这意味着即使 Leader 宕机，新选举出的 Leader 也一定拥有 HW 之前的所有消息，从而保证已提交的消息不会丢失。
3. 副本同步的标尺
HW 是衡量副本同步进度的指标。如果某个 Follower 的 LEO 持续小于 HW，说明它落后了。
关键场景分析
场景一：Leader 宕机，重新选举
假设：
-
LEO_L = 10，LEO_F1 = 9，LEO_F2 = 8
-
HW = min(10, 9, 8) = 8
如果此时 Leader 宕机：
-
F1 和 F2 会进行选举。F1 的 LEO 更高，更可能成为新 Leader。
-
新 Leader（F1）会将自己的 LEO 截断（Truncate）到 HW（8）。
-
为什么？因为 F1 虽然拥有偏移量 8 的消息，但偏移量 9 的消息（在 F1 上）可能没有在旧的 ISR 中完全复制（事实上 F2 就没有它），所以它不能保证这个数据是安全的。
-
新 Leader 从偏移量 8（HW）开始接受新的写入。
-
消费者不会看到任何数据丢失，因为它们最多只能消费到偏移量 7（HW-1）。
场景二：Follower 重启或重新加入 ISR
当 Follower 重启或重新加入 ISR 时：
-
它会向 Leader 发送请求，获取自己的 LEO 与 Leader 的 HW 之间的差异。
-
它会截断自己日志中超过 HW 的部分（因为这些数据可能不一致）。
-
然后从 HW 开始重新同步 Leader 的数据。
与 LEO/HW 相关的配置和监控
重要配置
replica.lag.time.max.ms（默认 30000）
- Follower 在此时间内没有向 Leader 发送 Fetch 请求，就会被移出 ISR。
- 直接影响 HW 的推进速度。
min.insync.replicas（默认 1）
- 定义最小 ISR 副本数。当 ISR 中的副本数少于此值时，生产者将无法写入（如果
acks=all）。 - 这是数据可靠性的重要保障。
监控指标
-
under-replicated-partitions：分区副本不同步的数量。 -
replicas.leo和replicas.hw：可以通过 JMX 或 Kafka 工具查看每个副本的 LEO 和 HW。 -
replica.lag.max.messages（已废弃）：过去用于衡量 Follower 落后 Leader 的消息数。