4. Replica与ISR机制：副本、选举与一致性保障

Kafka 的高可用，说白了就靠副本。没有副本，Broker 一挂，数据全丢。我在早期项目里见过有人为了省磁盘，Topic 只配了 1 个副本，结果机器硬盘坏了，整个 Topic 的数据直接归零。嗯，从那以后，我再也不敢省副本了。

4.1 Replica 副本的作用

Replica 就是分区的副本。每个分区可以有多个副本，分布在不同的 Broker 上。副本的作用很直接：

• 数据冗余：某个 Broker 挂了，副本还在，数据不丢。
• 故障转移：Leader 挂了，Follower 顶上，服务不中断。
• 读写分离：只有 Leader 处理读写，Follower 只负责同步，保证一致性。

副本数一般设 2 或 3。设 1 等于没保护，设太多又浪费磁盘。我个人习惯，生产环境至少 3 副本，关键业务甚至 4 副本。

4.2 Leader 与 Follower 选举

每个分区只有一个 Leader，其余都是 Follower。Leader 负责所有读写请求，Follower 只做一件事：从 Leader 拉数据，保持同步。

那 Leader 怎么选出来的？

1. Kafka 集群启动时，Controller 从 ISR 列表里选一个副本当 Leader。
2. 如果 Leader 挂了，Controller 会重新从 ISR 里选一个新的 Leader。
3. 选举很快，毫秒级。我遇到过 Leader 切换后，客户端几乎没感知。

你可能会问：为什么不从所有副本里选？因为 ISR 里的副本数据是最新的，选它们不会丢数据。如果 ISR 为空，那就只能选 OSR（Out-of-Sync Replica），但会有数据丢失风险。

4.3 ISR（In-Sync Replica）机制详解

ISR 是 Kafka 保证数据一致性的核心机制。它维护了一个「同步副本集合」，只有跟 Leader 保持同步的副本才能留在 ISR 里。

判断标准很简单：Follower 在 replica.lag.time.max.ms（默认 10 秒）内，必须向 Leader 发起一次同步请求。如果超时，就被踢出 ISR。

参数	默认值	说明
replica.lag.time.max.ms	10000	Follower 同步超时时间
min.insync.replicas	1	最小 ISR 副本数
unclean.leader.election.enable	false	是否允许非 ISR 副本当选 Leader

ISR 机制跟生产者的 acks 参数配合使用，效果更佳：

• acks=all：必须等 ISR 里所有副本都确认，才返回成功。
• min.insync.replicas=2：ISR 里至少要有 2 个副本，否则生产者会报错。

举个例子：Topic 有 3 个副本，min.insync.replicas=2，acks=all。如果某个 Follower 挂了，ISR 只剩 2 个副本，写入还能正常。但如果再挂一个，ISR 只剩 1 个，写入就会失败。这就是「宁可不可用，也不丢数据」的设计思路。

4.4 ISR 与 Leader 选举的关系

Leader 选举时，只从 ISR 里选。为什么？因为 ISR 里的副本数据跟 Leader 完全一致，选它们不会丢数据。

但如果 ISR 为空呢？这就看 unclean.leader.election.enable 了：

• false（默认）：不允许非 ISR 副本当选，Leader 选举失败，分区不可用。
• true：允许 OSR 当选，但会丢数据。

我个人建议，核心业务关掉 unclean.leader.election.enable。数据一致性比可用性更重要。非核心业务可以打开，避免长时间不可用。

4.5 知识体系图

下面这张图展示了 Replica、ISR 和 Leader 选举的关系：

4.6 实战建议

最后，给几个我在项目中总结的配置建议：

• 副本数：生产环境至少 3，关键业务 4。
• min.insync.replicas：设 2，配合 acks=all 使用。
• unclean.leader.election.enable：核心业务关掉，非核心可打开。
• replica.lag.time.max.ms：默认 10 秒够用，网络不稳定可适当调大。

记住，副本和 ISR 是 Kafka 高可用的基石。配置好了，集群稳如老狗；配不好，数据丢了都不知道。嗯，希望你能少踩我踩过的坑。