一、写在重启之前
重启 Kafka 集群从来都不是“关机再开机”那么简单。分区 Leader 的重新选举、客户端的瞬时断开、ISR 列表的抖动、Log 文件的一致性校验，每一步都可能触发数据延迟或消息丢失。本文用近四千字，把一次“看似粗暴”的集群重启拆成可落地的 24 个检查点，帮助你把风险降到可忽略的量级。
二、为什么需要重启
1. 版本升级：Broker 二进制替换后需要滚动重启生效。 2. 配置热改失败：某些参数（例如 log.segment.bytes）不支持动态生效。 3. 资源扩容：磁盘或内存升级后，必须让进程重新感知硬件。 4. 故障自愈：长期运行后文件句柄耗尽、页缓存碎片化，重启是最快解药。 5. 安全补丁：操作系统或 JVM 更新，需要整体停机维护窗口。 在动手前，先问自己：这次重启属于哪一类？不同场景对应的“停机策略”“回滚预案”截然不同。
三、重启前 8 个检查项
1. 健康基线 用 jmx 或内置指标确认：Under Replicated Partitions 为 0、ISR 抖动 < 1 %、CPU 负载 < 60 %。 2. 客户端兼容性 Producer 的 acks=all、retries、重试退避算法是否足够健壮。Consumer 的 session.timeout.ms 与 rebalance 策略是否可容忍短暂失联。 3. 数据均衡度 若某些 Broker 磁盘使用率 > 85 %，先运行 rebalance 再重启，避免重启过程中磁盘写爆。 4. 依赖系统 ZooKeeper 或 KRaft Controller 的会话超时、JVM GC 日志、操作系统文件句柄上限。 5. 告警静默 提前 30 分钟在监控系统创建维护窗口，防止瞬时告警轰炸值班群。 6. 回滚策略 旧版本保留、配置备份、回退脚本提前写好并 chmod +x。 7. 时间窗口 选择业务低谷，并预留 2 倍估算时间做缓冲。 8. 通知机制 公告、IM、邮件三通道同时推送，告知业务方“可预期抖动”。
四、滚动重启 12 步舞曲
第 1 步：挑选第一个节点 选分区副本数最少的 Broker，降低 Leader 切换波及范围。 第 2 步：确认副本同步 确保该节点所有分区 ISR 包含其他副本。 第 3 步：优雅下线 发送 SIGTERM，等待 controlled.shutdown.enable=true 自动把 Leader 迁走。 第 4 步：观察 Leader 选举 关注 ZooKeeper /Controller 日志，确认新 Leader 已就位。 第 5 步：关闭进程 若 30 秒内未完成，再发送 SIGKILL 兜底。 第 6 步：升级或替换文件 替换二进制、更新配置、清理旧日志索引。 第 7 步：启动进程 观察启动日志，重点查看 LogLoader 完成、BrokerId 注册成功。 第 8 步：等待副本同步 该节点重新加入 ISR 后，再进行下一步。 第 9 步：验证生产消费 用 kafka-console-producer/consumer 发送 100 条消息，确认无丢数。 第 10 步：指标回归 Under Replicated Partitions、RequestQueueTimeMs 回到基线。 第 11 步：放开告警 解除静默，观察 10 分钟无异常。 第 12 步：记录变更 把重启时间、耗时、异常写入运维 Wiki，方便下次复盘。
五、分区迁移重启：当磁盘或机架故障
若节点因硬件故障必须下线，且无法在原地恢复： 1. 使用 kafka-reassign-partitions 脚本生成分区迁移计划。 2. 把该节点所有分区迁移到健康 Broker。 3. 等待迁移完成，数据目录清零。 4. 按滚动重启流程下线节点。 迁移期间 ISR 可能短暂掉数，需提前调大 Producer 的 `delivery.timeout.ms`。
六、全集群停机：最后的大招
仅在重大版本不兼容或操作系统补丁时采用： 1. 停 Producer：业务侧优雅关闭或限流。 2. 停 Consumer：等待 offset commit 完成。 3. 停 Broker：按从低到高 BrokerId 顺序，减少 Controller 抖动。 4. 停 ZooKeeper：最后关闭，保证 Controller 元数据完整。 5. 升级并反向启动。 全集群停机需至少 2 倍数据保留时长的窗口，确保消息不丢。
七、客户端侧配合
Producer • 开启幂等 `enable.idempotence=true`，避免重启期间重试导致重复。 Consumer • 设置 `max.poll.interval.ms` 大于重启耗时，防止 rebalance 风暴。 • 关闭自动提交，改为手动 commitSync，确保 offset 精确。
八、回滚与异常处理
场景：升级后消息写入失败 1. 立即把 Broker 二进制换回旧版本。 2. 用 `--version` 验证版本号。 3. 启动后检查 log-start-offset 是否一致。 4. 若数据目录损坏，从远程快照恢复，再用 kafka-replica-verification 校验一致性。
九、验证清单：重启后的 6 个黄金指标
1. 集群可用：任意 topic 能正常生产消费。 2. 数据完整：对比重启前后 topic 的 end-offset。 3. 副本健康：Under Replicated Partitions 为 0。 4. 响应延迟：Produce/Consume Request Latency P99 回归基线。 5. 资源使用：CPU、内存、磁盘 IO 无异常飙升。 6. 告警静默：关闭维护窗口后 30 分钟无告警。
十、工具箱速查
• kafka-topics --describe：查看分区副本分布。 • kafka-preferred-replica-election：触发 Leader 再平衡。 • kafka-broker-api-versions：确认版本一致性。 • kafka-reassign-partitions --verify：检查迁移进度。 • jstack / jmap：进程卡死时快速定位。
十一、小结：重启不是结束，而是新的开始
一次成功的 Kafka 集群重启，不在于按下 `systemctl restart` 的瞬间，而在于前期 8 项检查、中期 12 步舞曲、后期 6 项验证。把这份清单沉淀为团队 SOP，下次升级就能从“惊心动魄”变成“按部就班”。 记住：滚动重启是常态，全集群停机是例外；任何自动化脚本都要先经过演练、回滚、复盘，才能真正做到零业务中断。