Controller 故障时集群发生什么

验证：kill一个broker，同时测三件真实不同的事

命令 · python os.kill(pid_of_broker1, signal.SIGKILL) # broker1真实同时是controller leader和分区0/1的leader p.produce("order-demo", partition=2, ...) # leader是broker2，理论上不受影响 p.produce("order-demo", partition=0, ...) # leader是刚死的broker1 admin.create_topics([...]) # 纯controller操作

验证：三件事真实几乎在同一时刻才恢复，都在11秒左右

真实实测 · 本机执行输出

真实分区2(leader=broker2，未受影响)耗时: (11.094s, 'ok')
真实分区0(leader=已死的broker1)耗时: (11.131s, 'ok')
真实创建新topic成功，耗时: 11.179s (从kill controller开始算)

最意外的是分区2那一条——它的leader从头到尾都是活着的broker2，理论上应该几乎瞬间完成，真实却也等了11秒。原因在于这个客户端是全新创建的，第一次produce之前必须先真实做一次完整的元数据刷新（参见《Kafka Metadata》），而这次刷新真实会尝试联系包括刚死的broker1在内的候选broker，在broker1真实被集群正式标记为"死亡"之前，客户端会真实反复尝试连接它、超时、退避重试——这个等待期间，连发往健康分区的消息也真实被一起拖住了。

验证：这11秒真实对应的是broker心跳超时，不是Raft选举本身

命令 · shell $ kafka-configs.sh --bootstrap-server localhost:19094 --describe --entity-type brokers --entity-name 2 --all | grep session

真实实测 · 本机执行输出

broker.session.timeout.ms=9000 sensitive=false synonyms={DEFAULT_CONFIG:broker.session.timeout.ms=9000}

真实的9秒(broker.session.timeout.ms默认值)加上客户端连接失败之后的退避重试，真实凑出了观察到的约11秒——这跟《KRaft Controller Quorum 如何选主》那篇看到的现象是同一件事的两个侧面：quorum内部选出新controller leader真实是很快的一件事(那篇的LeaderEpoch几乎立刻就变了)，但集群要真实"知道"一个broker已经死了、把它从候选人名单里剔除，靠的是心跳超时检测，这个检测窗口才是客户端真实感知到的大部分延迟来源。也就是说，Controller故障对集群的真实冲击，主要不是"选新Controller花了多久"，而是"确认旧的东西已经死了花了多久"——这也是为什么很多生产环境会把broker.session.timeout.ms调低以换取更快的故障发现，代价是网络抖动时更容易误判。

分步演示：Controller故障真实的连锁反应

每一步都是本文上面kill一个broker之后真实测量得到的原始结果。

三件看似无关的事，真实卡在了同一个9秒心跳超时上

这一步新验证的操作

参考与说明

数据来自本机3节点Kafka 4.3.1集群，被kill的broker同时兼任controller leader和数据分区leader两个角色。
和《KRaft Controller Quorum 如何选主》一起看：那篇看quorum内部选举的速度，这篇看客户端真实感知到的端到端恢复时间，两者数量级完全不同。
没有验证：把broker.session.timeout.ms调低之后真实的恢复时间变化；controller leader和数据分区leader分别落在不同broker上时，两种故障的耗时是否真的能被隔离开。

下一篇 · KAFKA 内部原理 48

Broker 加入和离开集群时发生什么