3. Leader 与 Follower 角色：Leader 负责读写、Follower 负责备份、ISR 集合、AR 集合
在 Kafka 分区副本模型中，Leader 和 Follower 是两种核心角色，它们共同决定了消息的读写路径、数据冗余与一致性边界。理解这两个角色的职责划分，以及 ISR（In-Sync Replicas） 与 AR（Assigned Replicas） 集合的运作机制，是掌握 Kafka 读写分离架构的基础。
3.1 角色职责与读写分离模型
每个分区（Partition）在创建时会被分配多个副本（Replica），这些副本分布在不同的 Broker 上。副本之间通过 Leader-Follower 模型实现读写分离：
- Leader：负责处理所有客户端的读写请求。每个分区有且仅有一个 Leader。
- Follower：只负责从 Leader 拉取消息数据，进行被动备份。Follower 不对外提供读写服务。
核心原则： 读写分离的边界在于——Leader 是唯一的数据入口与出口，Follower 仅作为冗余副本存在。这种设计简化了一致性模型，避免了分布式读写冲突。
下图展示了 Leader 与 Follower 之间的数据流与角色边界：
3.2 ISR 集合：同步副本集合
ISR（In-Sync Replicas） 是指与 Leader 保持同步的副本集合。只有处于 ISR 中的 Follower 才有资格在 Leader 故障时被选举为新的 Leader。ISR 是 Kafka 保证数据一致性的关键机制。
| 属性 | 说明 |
|---|---|
| 定义 | 与 Leader 保持同步的副本列表，包含 Leader 自身 |
| 判定标准 | Follower 在 replica.lag.time.max.ms 内成功拉取并确认了 Leader 的最新消息 |
| 默认超时 | 30 秒（可通过 replica.lag.time.max.ms 配置） |
| 作用 | 决定 Leader 选举的候选池；控制消息的“已提交”状态 |
| 动态性 | Follower 同步滞后时被踢出 ISR；追上后重新加入 |
实践要点： ISR 的大小直接影响可用性与一致性。ISR 越大，数据冗余度越高，但 Leader 需要等待更多副本确认才能提交消息（取决于
min.insync.replicas 配置）。生产环境建议将 min.insync.replicas 设置为 2，配合副本因子 3，在性能和可靠性之间取得平衡。
3.3 AR 集合：全部分配副本集合
AR（Assigned Replicas） 是指分区创建时分配的所有副本的集合，包括 Leader 和所有 Follower，无论它们当前是否处于同步状态。AR 是静态的，而 ISR 是动态的。
- AR = ISR + OSR（Out-of-Sync Replicas）
- OSR：同步滞后的副本，即被踢出 ISR 的 Follower。
- AR 在分区创建时确定，除非执行副本重分配（Reassignment），否则不会改变。
关键区别： AR 是“计划分配”的副本全集，ISR 是“当前可用且同步”的副本子集。Leader 选举只能在 ISR 中进行，不能选举 OSR 中的副本。
3.4 ISR 与 AR 的关系对比
| 对比维度 | ISR（In-Sync Replicas） | AR（Assigned Replicas） |
|---|---|---|
| 集合范围 | AR 的子集 | 全部分配副本 |
| 动态性 | 动态变化（加入/踢出） | 静态（除非重分配） |
| 包含 Leader | 是 | 是 |
| 包含滞后副本 | 否 | 是（OSR） |
| 选举资格 | 有 | 仅 ISR 中的副本有资格 |
| 配置影响 | replica.lag.time.max.ms |
replication.factor |
下图展示了 AR、ISR 与 OSR 之间的包含关系：
3.5 Leader 选举与 ISR 的联动
当 Leader 发生故障时，Kafka Controller 会从当前分区的 ISR 集合中选举一个新的 Leader。选举过程遵循以下规则：
- 优先从 ISR 中选举：ISR 中的副本拥有与旧 Leader 完全一致的数据，不会丢失消息。
- ISR 为空时的处理：如果 ISR 为空（所有副本都滞后或宕机），Kafka 会从 OSR 中选举一个副本作为 Leader，但此时可能发生数据丢失。
- unclean.leader.election.enable：该配置控制是否允许在 ISR 为空时从 OSR 选举 Leader。默认
false，建议生产环境保持关闭以避免数据不一致。
风险提示： 启用
unclean.leader.election.enable=true 虽然能提高可用性，但会导致已提交消息的丢失。在金融、交易等强一致性场景中，必须设置为 false，宁可服务不可用也不丢失数据。
3.6 副本同步与滞后判定
Follower 通过向 Leader 发送 Fetch 请求来拉取消息。Leader 会跟踪每个 Follower 的同步进度，判定其是否属于 ISR：
| 指标 | 说明 | 默认值 |
|---|---|---|
replica.lag.time.max.ms |
Follower 未发送 Fetch 请求的最大时间，超过则被踢出 ISR | 30000（30 秒） |
replica.lag.max.messages |
（旧版本）Follower 落后 Leader 的最大消息数，已废弃 | 4000 |
| LEO（Log End Offset） | 每个副本的最后一条消息偏移量 | 动态 |
| HW（High Watermark） | ISR 中所有副本都确认写入的偏移量，消费者只能读取 HW 之前的消息 | 动态 |
同步判定逻辑： 只要 Follower 在
replica.lag.time.max.ms 内至少发送了一次 Fetch 请求，并且请求中携带的 LEO 与 Leader 的 LEO 差距在可接受范围内，该 Follower 就保持在 ISR 中。Kafka 2.0+ 版本已移除基于消息数量的滞后判定，仅使用时间维度。
3.7 生产配置建议
- 副本因子（replication.factor）：建议设置为 3，保证在 1 个 Broker 宕机时仍有完整副本。
- min.insync.replicas：建议设置为 2，配合副本因子 3，确保至少 2 个副本确认写入后才返回成功。
- unclean.leader.election.enable：强一致性场景设为
false；高可用优先场景可设为true，但需接受数据丢失风险。 - replica.lag.time.max.ms：根据网络延迟和负载调整，默认 30 秒通常足够，短时间网络抖动不会导致频繁踢出 ISR。