Kafka ISR 从 3 缩到 1 的 47 秒静默窗口：rack-aware 故障下 min.insync.replicas 为什么救不了你

作者江若衡

KafkaISRmin.insync.replicasrack-aware消息可靠性

一、现象：交换机一断，ISR 就缩了，但没有任何人报错

去年 12 月，我们做 IDC 搬迁演练，把 6 台 Kafka 3.5 broker（KRaft 模式，3 个 rack × 2 台）的 rack-B 交换机直接拔线，模拟整机架断电。预期是"ISR 从 3 缩到 1，producer 侧不报错，47 秒后交换机恢复，broker 重同步"。

结果：47 秒窗口内，order-event topic（RF=3，min.insync.replicas=1，acks=all，日均 3200 万条，峰值 1.8 万 msg/s）的 ISR 从 3 缩到 1，但 producer 的 NotEnoughReplicas 错误数为 0，Prometheus 上 kafka_log_LoaderLag 和 kafka_server_ReplicaManager_IsrShrinkCount 的跳变被淹没在 200+ 条告警流里，没有一条被值班同学看到。更关键的是：rack-B 的 broker 恢复后，落后了 12,847 条消息，其中 3 条是 order-event 的事务提交标记（__transaction_state 的 abort marker），导致下游 consumer 在恢复后的 2 分钟内读到了已被 abort 的 2 笔订单的中间状态——不是数据丢失，是数据回退，对账系统报了 2 笔"幽灵订单"。

影响面不大（2 笔），但暴露了一个结构性问题：ISR 收缩在默认配置下是完全静默的。

二、原理：min.insync.replicas 到底在保护谁

很多团队把 min.insync.replicas 理解为"至少写 N 个副本"，这是错的。它的真实语义是：

ISR 里至少有 min.insync.replicas 个 broker 时，才接受写请求；否则返回 NotEnoughReplicasException。

这意味着：

min.insync.replicas=1（默认）时，ISR 缩到 1 仍然接受写。acks=all 此时等价于 acks=1，因为 "all" = ISR size = 1。你的数据只写到了 leader 一个副本上。
ISR 收缩本身不产生任何 producer 侧错误。只有 ISR 缩到低于 min.insync.replicas 时才会报错。默认值 1 意味着"只要 leader 活着就能写"，这跟不开复制没有本质区别。
unclean.leader.election（默认 true）是 ISR 空时的 fallback。当 ISR 缩到 0（所有 follower 都挂了），Kafka 会从非 ISR 的 follower 里选一个当 leader。这个新 leader 的 log 可能比旧 leader 短——consumer 看到的 offset 会回退。这就是我们那 2 笔"幽灵订单"的直接原因。

用一张时序图说清 47 秒里发生了什么：

t=0s    rack-B 交换机断电，broker-4、broker-5 失联
t=3s    broker-1（leader, rack-A）检测到 broker-4 心跳超时（default 9s 内的前 3 次 miss）
t=3s    broker-1 将 broker-4 从 ISR 移除 → ISR: [1,2,3] → [1,2]
        broker-3 将 broker-5 从 ISR 移除 → ISR: [3,4,1] → [3,1]
        ★ 无任何 producer 报错，min.insync.replicas=1 仍满足
t=5s    另一批 partition 的 ISR 也缩到 1
t=47s   交换机恢复，broker-4/5 重新上线
t=48s   broker-4/5 开始 truncation（截断到 HW）+ fetch 追赶
t=52s   broker-4 落后 12,847 条，仍在追赶
t=54s   一个 partition 的 ISR 曾缩到 0 → unclean leader election 触发
        → 新 leader 的 log end offset 比旧 leader 小 3 条
        → consumer 读到回退的数据

核心矛盾：ISR 收缩是 broker 内部的"软事件"，Kafka 的设计哲学是"宁可降级也不拒绝服务"。但在 rack-aware 部署下，"降级"意味着你的复制因子从 3 变成了 1，而你的告警体系里没有一条规则在看这件事。

三、具体做法：从配置到监控，四步堵住静默窗口

3.1 配置层：min.insync.replicas 不是"越大越好"

# broker.properties（6 broker, 3 rack × 2, RF=3）
# 关键：min.insync.replicas 必须 ≤ RF，且 ≤ 每个 rack 的 broker 数 + 1
min.insync.replicas=2
unclean.leader.election.enable=false   # 生产环境必须关，宁可不可用不可回退

# producer 侧必须配合，否则 ISR 缩到 1 时直接 NotEnoughReplicas
acks=all
retries=2147483647
retry.backoff.ms=100

注意：min.insync.replicas=2 在 6 broker（2/rack）的拓扑下，意味着任意一个 rack 整体宕机时，producer 会开始报 NotEnoughReplicas。这不是 bug，这是你要的 fail-fast——让业务方知道"现在只有 1 个副本了，要么接受风险要么降级业务"，而不是静默地写。

3.2 拓扑层：rack-aware 的 replica 分配

# 创建 topic 时指定 rack，确保每个 partition 的 3 个副本分散在 3 个 rack
kafka-topics.sh --create \
  --topic order-event \
  --partitions 48 \
  --replication-factor 3 \
  --config min.insync.replicas=2 \
  --config unclean.leader.election.enable=false \
  --config rack.rack=A \
  --bootstrap-server broker-1:9092

# 验证 replica 分布（每个 partition 的 3 个 broker 分属 3 个 rack）
kafka-metadata-shell.sh
> describe topic order-event
# 输出中确认 rack-A / rack-B / rack-C 各 1 个 replica

3.3 监控层：ISR 收缩必须是一级告警

# Prometheus alert rules
- alert: KafkaISRShrinkBelow2
  expr: |
    kafka_server_replicamanager_isr < 2
    and on (topic, partition)
    (kafka_server_replicamanager_isr_change > 0)
  for: 5s
  labels:
    severity: critical
  annotations:
    summary: "ISR 收缩到 {{ $value }}，topic={{ $labels.topic }} p={{ $labels.partition }}"
    # 关键：这条告警的 for 必须 ≤ 5s，因为静默窗口就是从这一刻开始的

- alert: KafkaUncleanLeaderElection
  expr: kafka_server_replicamanager_activecontrollercount == 0
  for: 0s
  labels:
    severity: critical
  annotations:
    summary: "检测到 unclean leader election 条件成立（ISR 为空）"

为什么 for: 5s 而不是 30s：我们的事故里，ISR 从 3 缩到 1 只花了 3 秒（心跳超时），但我们的告警 for: 30s 意味着"连续 30 秒 ISR < 2 才告警"。如果 ISR 在 25 秒后又恢复（比如 rack-B 的 broker 重连了但还没追上），告警就不会触发。ISR 收缩是瞬时事件，for 必须短。

3.4 故障演练层：每季度做一次 rack 级断电

# 演练脚本（在 rack-B 的交换机上执行）
# 1. 记录当前所有 partition 的 ISR
for p in $(seq 0 47); do
  kafka-replica-verification.sh --topic order-event --partition $p
done > /tmp/isr-before.txt

# 2. 拔线 / 断网（模拟 rack-B 整体宕机）
ip link set eth0 down

# 3. 等 60s，记录 ISR 变化 + producer 错误率 + consumer lag 变化
# 4. 恢复网络
ip link set eth0 up

# 5. 等 120s，验证：
#    - 所有 partition ISR 恢复为 3
#    - consumer 没有读到回退的 offset（对比 /tmp/isr-before.txt）
#    - producer 在 ISR 缩到 1 时确实报了 NotEnoughReplicas（如果 min.insync.replicas=2）
#    - 没有 unclean leader election 发生

四、踩过的坑：三个反直觉

坑 1：min.insync.replicas=2 不是"写 2 个副本"，是"ISR 里至少有 2 个才让写"。 我们最初以为设了 min.insync.replicas=2 就是"数据至少落到 2 台机器"。实际上，如果 3 个 broker 里 2 个在 ISR、1 个不在，min.insync.replicas=2 仍然满足，但你的数据只写了 2 个副本——第 3 个副本（不在 ISR 的那个）不会收到这条消息。ISR 是动态的，min.insync.replicas 是"门槛"不是"目标"。

坑 2：unclean.leader.election=false 在 ISR 空时意味着"这个 partition 不可写也不可读"。 我们演练时把 unclean.leader.election 关了，然后模拟 ISR 缩到 0（把 rack-B 的 2 台 + rack-C 的 1 台全关了）。结果那个 partition 直接不可用——producer 报 LeaderNotAvailable，consumer 也读不到。这其实是正确的行为（宁可不可用不可回退），但业务方第一次看到这个报错时以为"Kafka 挂了"，花了 20 分钟排查。关 unclean leader election 之前，必须让业务方知道"3 个副本全挂 = 这个 partition 不可用"，并且确认他们的降级方案能 cover 这个场景。

坑 3：ISR 收缩告警的 for 时长必须 ≤ 心跳超时时间。 Kafka 默认 controlled.shutdown.max.retries=3、controller.broker.connection.timeout.ms=10s、心跳间隔 zookeeper.session.timeout.ms=18000（ZK 模式）或 KRaft 的 raft.election.timeout（默认 5s）。ISR 收缩发生在心跳超时后，如果你告警的 for 比心跳超时还长，你告出来的时候 ISR 可能已经恢复了——你错过的是那个"静默窗口"本身。

五、结论与可复用清单

ISR 收缩是 Kafka 在"可用性"和"持久性"之间做的运行时权衡，默认配置偏向可用性（min.insync.replicas=1 + unclean.leader.election=true）。这在开发环境没问题，但在生产环境，"静默降级"比"显式不可用"危险得多——因为没有人知道你的复制因子已经从 3 变成了 1。

可复用清单（按优先级排序）：

| # | 动作 | 为什么 | |---|------|--------| | 1 | min.insync.replicas=2 + acks=all | ISR 缩到 1 时 producer 立即报错，fail-fast 优于静默降级 | | 2 | unclean.leader.election.enable=false | 宁可 partition 不可用，不可 consumer 读到回退数据 | | 3 | ISR 收缩告警 for: 5s，级别 critical | 静默窗口只有几秒，告警必须比窗口短 | | 4 | rack-aware 部署 + 验证 replica 分布 | 确保 rack 故障时 ISR 最多缩到 1 而不是 0 | | 5 | 每季度 rack 级断电演练 | 验证告警能触发、业务方知道降级表现、consumer 不回退 | | 6 | __transaction_state 的 RF 和 ISR 单独关注 | 事务 abort marker 丢失 = 下游读到已回滚的中间状态 |

一个开放问题留给社区：Kafka 4.0（如果 KIP-932 落地）的 KRaft 原生 controller 会不会改变 ISR 收缩的时序？如果 controller 和 broker 的故障域重叠（比如同 rack），ISR 收缩的"静默窗口"会不会更长？我倾向于认为会更长，因为 KRaft 的 controller 本身也是 rack-aware 的，但社区还没有公开的故障注入数据。有人做过这个实验吗？

赞 2 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。