副本与 ISR 是什么
Kafka 每个分区都有一个 Leader 副本和若干 Follower 副本，分布在不同的 Broker 上。Follower 持续从 Leader 拉取数据并追赶，那些跟得上、延迟在阈值内的副本构成 ISR（In-Sync Replicas，同步副本集合）。Leader 故障时，新的 Leader 优先从 ISR 中选出。
ISR 收缩意味着什么
某个副本落后太久（超过 replica.lag.time.max.ms）会被移出 ISR，这是保护机制：避免选举出一个数据明显缺失的副本。但如果 ISR 持续收缩或反复抖动，说明 Broker 磁盘 IO、网络或 GC 有瓶颈，需要处理根因，而不是简单重启。
角色对照
| 角色 | 含义 | 关注点 |
|---|---|---|
| Leader | 处理客户端读写请求的副本 | 为 -1 或 none 表示分区不可用 |
| Follower | 持续拉取 Leader 数据，保持同步 | 落后原因通常是磁盘或网络 |
| ISR | 与 Leader 保持同步的副本集合 | 短于副本数说明有副本掉队 |
| AR | 分区的全部副本集合（Assigned Replicas） | 数量等于创建时设定的副本因子 |
基本信息
| Leader 选举 | 默认从 ISR 中选，保证新 Leader 不会丢数据 |
|---|---|
| ISR 超时 | replica.lag.time.max.ms 决定多久未同步被移出（较新版本默认 30 秒） |
| 最小同步副本 | min.insync.replicas 与 acks=all 配合控制写入可用性 |
| 非同步选举 | unclean.leader.election.enable 默认关闭，开启会在副本不足时牺牲数据 |
| 观察视角 | describe 输出的 Isr 与 Replicas 差异 |
典型使用场景
- 巡检副本健康：统计 under-replicated 分区数量，观察是否长期不为零
- Broker 重启与扩容后：跟踪 ISR 是否逐步恢复完整
- 写入报错排查：ISR 不足导致 acks=all 无法满足时，写入会直接失败
- 容量评估：副本因子直接放大磁盘与网络占用，规划时不能只算单副本
- 机架感知配置：确保同一分区的副本分散在不同机架，避免单点故障
观察副本与 ISR
观察副本与 ISR
# 查看分区的 Leader、副本与 ISR
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders
# Partition: 0 Leader: 2 Replicas: 2,3,1 Isr: 2,1 ← 3 号副本暂未同步
# 集群级：所有存在副本掉队的分区
kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions
# 统计掉队分区数量，适合做巡检基线
kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions | grep -c 'Partition:'相关 Broker 参数
相关 Broker 参数
# 副本多久未同步会被移出 ISR（较新版本默认 30000 毫秒）
replica.lag.time.max.ms=30000
# 是否允许非同步副本当选 Leader：默认 false，开启后副本不足时会丢数据
unclean.leader.election.enable=false
# 副本拉取线程数与单次拉取大小，节点磁盘与网络越强可适当调大
num.replica.fetchers=4
replica.fetch.max.bytes=1048576副本落后期间若 Leader 宕机，只有 ISR 内的副本能参选，未同步的那部分数据可能丢失；这正是「acks=all 加副本 3」组合存在的原因——用冗余换掉这段风险窗口。
unclean.leader.election.enable 打开后，当 ISR 为空时允许落后的副本当选 Leader，集群能重新写入，但会丢失尚未同步的数据。对账务类数据应保持默认关闭，宁可暂时不可用。