当前位置：首页 > news >正文

kafka的ISR机制

news 2026/5/31 13:44:10

ISR 机制的全称是：

In-Sync Replicas
（同步副本集/同步副本机制）

当一个追随者副本启动时，它会开始从领导者副本拉取消息。如果它能够持续地、及时地追上领导者的最新数据（即 LEO - Log End Offset），它就会被领导者认为是“同步的”，并维持在 ISR 列表中。

如果某个追随者副本落后了，比如因为网络问题、机器负载过高、GC 停顿等导致它长时间没有从领导者拉取数据，它就会被领导者从 ISR 集合中移除。

判断一个副本是否“失步”的标准，在旧版本中是基于延迟的消息数，现在主要是基于时间参数：

replica.lag.time.max.ms（默认 30秒）：如果一个追随者副本在此时间内没有向领导者发起获取数据的请求（如 FetchRequest），或者它的数据落后领导者超过这个时间阈值，领导者就会将其从 ISR 中踢出。

被踢出 ISR 的副本并不会停止工作，它仍然会继续尝试从领导者拉取数据。当这个“落后”的副本重新追上了领导者的最新进度（即它的 LEO 与领导者的 LEO 相差在允许的范围内），领导者会将它重新加入 ISR 集合。

如果没有 ISR，为了保证数据一致性，每次写入可能都需要所有副本确认，但只要有一个副本缓慢或宕机，整个系统就会不可用或变得极慢。
有了 ISR，Kafka 只需要关注那些健康的、同步的副本。只要 ISR 中至少有一个副本存活，分区就是可用的。

当生产者配置 acks=all 时，它实际上是在等待 ISR 中的所有副本都确认收到消息后，才认为发送成功。这确保了只要 ISR 中有一个副本存活，成功写入的消息就不会丢失。

当分区的领导者副本发生故障时，Kafka 不会从所有副本中随意选择一个作为新领导者，而是优先从 ISR 集合中选举一个新的领导者。

假设一个分区有 3 个副本：Leader (L), Follower1 (F1, ISR), Follower2 (F2, ISR)。

正常状态：
- L, F1, F2 都在 ISR 中。
- 生产者发送消息，L 和 F1 很快写入，但 F2 因网络问题开始变慢。
Follower 失步：
- F2 的延迟超过了 replica.lag.time.max.ms（例如 30秒）。
- 领导者 L 将 F2 从 ISR 中移除。当前 ISR = [L, F1]。
生产者写入：
- 生产者配置了 acks=all，它只需要等待 ISR ([L, F1]) 中的所有副本确认即可，无需等待缓慢的 F2。这保证了写入性能和可用性。
Follower 恢复：
- F2 的网络恢复，并快速追上了领导者的最新数据。
- 领导者 L 检测到 F2 已同步，将其重新加入 ISR。当前 ISR = [L, F1, F2]。
领导者故障：
- 假设 Leader (L) 宕机。
- Kafka 控制器会从当前的 ISR ([F1, F2]) 中选举一个新的领导者（比如 F1）。由于 F1 和 F2 数据都是最新的，这个切换过程不会造成数据丢失。

replica.lag.time.max.ms：决定追随者副本是否“失步”的关键时间阈值。默认 30000ms (30秒)。
min.insync.replicas：非常重要的参数。它定义了生产者设置 acks=all 时，所必需的最小 ISR 数量。
- 例如，如果你设置 min.insync.replicas=2，那么当 ISR 中的副本数少于 2 个时（比如只剩下领导者自己），生产者写入会失败（抛出 NotEnoughReplicasException）。这是一个可用性和可靠性的权衡：你宁愿让服务不可用，也不接受数据可能丢失的风险。