一、概述
Kafka 采用主从（Leader-Follower）复制模型来保障数据的可靠性与一致性。分区副本之间通过 ISR（In-Sync Replicas）机制协调复制进度，并以 HW（High Watermark，高水位）作为消费者可见性的判定基准。
二、核心概念
| 全称 | 含义 | 说明 |
|---|---|---|
| Assigned Replicas(AR) | 分区配置的所有副本集合（包括 Leader 和所有 Follower）。由 replication.factor 决定。 | |
| In-Sync Replicas(ISR) | 同步副本集合。指那些与 Leader 保持实时同步、延迟在允许范围内的副本。Leader 始终在 ISR 中。 | |
| Out-of-Sync Replicas(OSR) | 非同步副本集合。指因网络延迟、GC 停顿或负载过高导致同步滞后，被暂时剔除出 ISR 的副本。 | |
| High Watermark(HW) | 高水位线，ISR 集合中所有副本最后提交偏移量的最小值。 | HW = min(ISR 内所有副本的 LEO) |
| Log End Offset(LEO) | 日志末端偏移量，表示副本日志中下一条待写入消息的偏移量； | Leader 与 Follower 各自维护 |
三、ISR 保障数据一致性的核心原理
ISR 机制通过六个环节的协同，保障分区数据的一致性与可用性：ISR 维护 → 消息写入与复制 → 提交判定 → 消费可见性 → 同步保障 → 故障恢复。各环节环环相扣，共同构成 Kafka 数据可靠性的基础。
3.1 Leader 维护 ISR
Leader 负责维护 ISR。当 Follower 的复制进度追上 Leader（其 LEO 与 Leader 对齐）时，Leader 将其加入 ISR；当 Follower 长时间无法追上 Leader 的进度，或主动退出同步时，Leader 将其从 ISR 中移除，降级为OSR。
3.2 生产者发送消息
生产者将消息发送至 Leader，Leader 将消息追加（append）到本地日志，并向 ISR 中的全部 Follower 同步复制。
3.3 消息提交
当 ISR 中所有 Follower 均完成该消息的复制后，Leader 推进 HW（High Watermark，高水位/最高提交偏移量）。此时消息才被认定为"真正提交"，具备对外可见的资格。
3.4 消费者消费消息
消费者只能消费已提交的消息，即偏移量位于 HW 之前的消息；HW 之后的消息虽然已写入 Leader，但尚未确认提交，对消费者不可见。
3.5 Follower 同步数据
Follower 周期性主动从 Leader 拉取（pull）数据，保持与 Leader 的同步。当 Follower 宕机或长期未完成同步时，会被 Leader 从 ISR 中移除。
3.6 Leader 选举
当 Leader 所在 Broker 失效时，会从 ISR 中选举出新的 Leader。选举规则为：优先选择 ISR 中数据最新（LEO 最大）的 Follower 作为新 Leader。
边界说明：若开启 unclean.leader.election.enable=true，当 ISR 为空时允许选择 OSR 中的副本作为新 Leader，此时可能产生数据丢失。
四、消息ACK机制
4.1 Producer消息发送流程
Producer → ① 发送消息 → Leader 追加到本地日志（LEO+1）
↓
② Follower 拉取复制（LEO+1）
↓
③ Leader 根据 ISR 各副本 LEO 计算 HW
↓
④ 达到 ack 条件 → 向 Producer 返回 ack
4.2 ack机制
| acks 取值 | 含义 | Leader 何时返回 ack | 可靠性 |
|---|---|---|---|
acks=0 | 不等确认 | 消息写入客户端缓冲区即返回 | 最低，可能直接丢 |
acks=1 | 等 leader 确认 | 消息写入 leader 本地日志（LEO 推进）即返回 | 中等，leader 宕机可能丢 |
acks=all | 等所有 ISR 确认 | 所有 ISR 副本复制完成、HW 推进后才返回 | 最高 |
核心逻辑： acks=all 下，ack 时机 = HW 推进时机。 Leader 只有在确认"ISR 内所有副本都有了这条消息"之后，才推进 HW 并回复 ack。
