复制、扩容与故障恢复

每个分区只有一个 Leader 接收客户端读写，Follower 从 Leader 同步数据。ISR 是与 Leader 保持同步的副本集合；当 Producer 使用 acks=all 且 Topic 的 min.insync.replicas=2 时，ISR 少于 2 个会拒绝写入，这是用可用性保护已确认数据的设计。

1. 检查 Leader 与 ISR

# 查看分区 Leader、全部副本和 ISR；Replica 与 ISR 不一致需要立即关注。
/opt/kafka/bin/kafka-topics.sh --describe \
  --bootstrap-server kafka-1.example.internal:9092 --topic orders.created.v1

# 仅输出副本不足分区；生产巡检中无输出才是预期状态。
/opt/kafka/bin/kafka-topics.sh --describe --under-replicated-partitions \
  --bootstrap-server kafka-1.example.internal:9092

# 仅输出没有可用 Leader 的分区；有输出通常意味着该分区不可读写。
/opt/kafka/bin/kafka-topics.sh --describe --unavailable-partitions \
  --bootstrap-server kafka-1.example.internal:9092

不要为了快速恢复开启 unclean.leader.election.enable=true。它可能从落后副本选出 Leader，从而丢弃未同步的已确认消息；只有明确接受数据损失并经应急审批后才能考虑。

2. Broker 维护与重分配

维护 Broker 前先确认没有副本不足分区，再分批迁移副本或受控停机。副本重分配会消耗网络与磁盘 I/O，应分 Topic 执行并持续观察 ISR、生产延迟和 Consumer Lag。

{
  "version": 1,
  "partitions": [
    {
      "topic": "orders.created.v1",
      "partition": 0,
      "replicas": [1, 2, 4],
      "log_dirs": ["any", "any", "any"]
    }
  ]
}

# 根据真实 Topic 清单生成候选方案；先审核输出，不能直接执行未知分配。
/opt/kafka/bin/kafka-reassign-partitions.sh --generate \
  --bootstrap-server kafka-1.example.internal:9092 \
  --topics-to-move-json-file topics.json --broker-list "1,2,3,4"

# 将审核后的方案写入 reassignment.json 后提交任务。
/opt/kafka/bin/kafka-reassign-partitions.sh --execute \
  --bootstrap-server kafka-1.example.internal:9092 \
  --reassignment-json-file reassignment.json

# 反复验证直到完成；完成前不可下线源或目标 Broker。
/opt/kafka/bin/kafka-reassign-partitions.sh --verify \
  --bootstrap-server kafka-1.example.internal:9092 \
  --reassignment-json-file reassignment.json

3. ZooKeeper 故障边界

ZooKeeper 失去法定人数时，已建立的数据流可能短时继续，但 Controller 选举、元数据变更和分区故障转移会受阻。恢复顺序是先恢复 ZooKeeper 法定人数和数据一致性，再处理 Broker；绝不能删除 ZooKeeper 数据目录来“重建”仍有关联 Broker 的生产集群。

故障	首要动作
单 Broker 不可用	检查 Leader、ISR、磁盘和网络，恢复后等待副本追平
多副本脱离 ISR	停止高风险变更，检查复制流量、磁盘 I/O 和 Broker 延迟
ZooKeeper 单节点故障	保持其余节点运行，核对 myid 与持久卷后恢复节点
ZooKeeper 无法形成法定人数	按备份和变更记录恢复足够节点，避免多个孤立节点独立启动

4. 重分配限速与恢复验收

重分配会和线上复制、生产、消费争抢磁盘和网络。应先在低峰期按小批次执行，必要时临时配置节流；任务完成后要删除节流，避免其长期限制 Broker 复制能力。

# 临时限制副本迁移速率；数值仅为起点，必须结合磁盘、网络和 ISR 监控调整。
/opt/kafka/bin/kafka-configs.sh --alter \
  --bootstrap-server kafka-1.example.internal:9092 \
  --entity-type brokers --entity-default \
  --add-config leader.replication.throttled.rate=52428800,follower.replication.throttled.rate=52428800

# 迁移完成、ISR 恢复后删除动态节流，避免残留为长期吞吐瓶颈。
/opt/kafka/bin/kafka-configs.sh --alter \
  --bootstrap-server kafka-1.example.internal:9092 \
  --entity-type brokers --entity-default \
  --delete-config leader.replication.throttled.rate,follower.replication.throttled.rate

恢复验收包括：无 Offline Partition、无持续 Under Replicated Partition、所有关键 Topic 的 ISR 完整、生产失败率与消费者 Lag 回到基线。不要只依据 Broker 进程恢复就宣布故障结束。