面试知识库
极高 进阶

Kafka-ISR机制#

一句话答案#

ISR（In-Sync Replicas）是与 Leader 保持同步的副本集合，Kafka 通过 ISR + HW（高水位）机制保证数据一致性：消息只有被 ISR 中所有副本确认后才对消费者可见。

核心要点

ISR 是什么#

Partition 的副本集合：
  AR (All Replicas) = ISR + OSR

  ISR: 与 Leader 同步的副本（包括 Leader 自己）
  OSR: 落后太多被踢出的副本
plaintext

副本进出 ISR 的条件#

被踢出 ISR： Follower 超过 replica.lag.time.max.ms（默认 30s）没有向 Leader 发送 Fetch 请求。 重新加入 ISR： Follower 追上 Leader 的 LEO。

LEO 和 HW#

概念含义
LEO（Log End Offset）每个副本的日志末端偏移量
HW（High Watermark）ISR 中所有副本的最小 LEO
Leader:    [0][1][2][3][4]  LEO=5
Follower1: [0][1][2][3]     LEO=4
Follower2: [0][1][2]        LEO=3

HW = min(5, 4, 3) = 3
消费者只能读到 offset 0~2（HW 之前）
plaintext

ISR 与 acks 的配合#

acks等谁确认安全性
0不等最低
1Leader中等
allISR 所有副本最高

陷阱： acks=all 只等 ISR 中的副本。ISR 只有 Leader → 等于 acks=1。 解决： min.insync.replicas=2。

Leader 选举#

Leader 宕机 → 从 ISR 中选新 Leader。ISR 为空时：

  • unclean.leader.election.enable=false（默认）→ 分区不可用
  • =true → 从 OSR 中选，可能丢数据

核心配置#

replica.lag.time.max.ms=30000
min.insync.replicas=2
replication.factor=3
unclean.leader.election.enable=false
properties
面试回答（2分钟版）

ISR即In-Sync Replicas，是Kafka中与Leader保持同步的副本集合，Leader本身也在ISR中。Follower通过不断向Leader发Fetch请求拉取数据保持同步，如果超过replica.lag.time.max.ms默认30秒没有Fetch请求就会被踢出ISR进入OSR，追上后可以重新加入。ISR配合两个关键概念：LEO是每个副本的日志末端偏移量，HW高水位是ISR中所有副本LEO的最小值，消费者只能读到HW之前的消息，这保证了已提交消息的一致性。ISR和acks参数配合使用，acks=0不等确认最快但最不安全，acks=1只等Leader确认，acks=all等ISR中所有副本确认最安全。但这里有个陷阱，acks=all只等ISR中的副本，如果ISR只剩Leader一个节点就等于acks=1，所以必须配合min.insync.replicas=2保证至少有两个同步副本才允许写入。Leader宕机时从ISR中选新Leader，如果ISR为空且unclean.leader.election.enable=true则从OSR选可能丢数据。生产环境推荐三件套配置：replication.factor=3、min.insync.replicas=2、unclean.leader.election.enable=false。

追问与易错

追问方向：

  • “HW 什么时候更新？”→ Follower Fetch 时 Leader 计算新 HW 并返回
  • “min.insync.replicas=2 但只有 2 副本？”→ 任一 Follower 宕机即无法写入

易错点：

  • ❌ “acks=all 等所有副本”——只等 ISR，不等 OSR
  • ❌ “HW 等于 Leader 的 LEO”——HW 是 ISR 所有副本的最小 LEO