Kafka 3.3（Kraft模式）：Controller ID每秒频繁变更问题咨询

结论：这种每秒变更Controller ID的现象绝对不正常

正常情况下，Kraft模式的Kafka集群Controller应该稳定运行，仅在以下场景才会触发重新选举：

• 当前Controller节点故障宕机
• Controller节点失去集群Quorum（多数节点无法连通）
• 主动触发Controller切换（如手动下线节点）

针对你遇到的3.3版本三节点集群问题，可从以下方向排查：

1. 节点间网络连通性问题 #

节点间网络高延迟、丢包或防火墙拦截，会导致Controller心跳超时，集群频繁触发重新选举：

• 用ping、mtr工具测试三个节点间的网络连通性，查看是否存在丢包或延迟过高情况
• 检查Kafka节点日志，搜索Controller failover triggered关键词，查看触发选举的具体原因（如timeout waiting for controller heartbeat）

2. 节点资源瓶颈 #

节点CPU、内存资源耗尽，会导致Kafka进程无法及时处理心跳请求，被集群判定为故障：

• 用top、htop查看节点CPU、内存使用率，确认是否存在资源过载情况
• 查看Kafka的GC日志，检查是否有频繁Full GC导致进程卡顿的问题（可通过jstat -gc <kafka-pid>实时监控）

3. Kraft元数据同步异常 #

Kraft模式下元数据通过Quorum集群同步，若元数据复制延迟过高或同步失败，会引发选举循环：

• 查看节点日志中QuorumController、MetadataCache相关报错信息，比如metadata replication timeout
• 执行kafka-metadata-quorum.sh describe --bootstrap-server <节点IP:端口>，查看元数据集群状态，确认是否有节点同步异常

4. 配置错误 #

检查每个节点的server.properties配置是否一致：

• 确认controller.quorum.voters配置的节点列表完全一致，格式应为id@host:port,id@host:port,id@host:port
• 检查controller.election.timeout.ms配置，默认值为3000ms，若设置过小（如1000ms以下）会导致误判故障

5. 版本Bug #

Kafka 3.3版本的Kraft模式存在部分已知选举循环Bug，比如特定场景下的Quorum状态异常：

• 查看官方Release Notes，确认是否有匹配的Bug记录
• 考虑升级到3.3.x的补丁版本（如3.3.2）或更高稳定版本（如3.4+）

验证方法 #

• 多次执行kafka-metadata-quorum.sh describe --bootstrap-server <节点IP:端口>，观察Current Controller ID是否持续变化
• 持续跟踪节点日志，重点关注INFO [ControllerManager id=<node-id>] became the new controller这类日志，统计出现频率和触发原因

内容的提问来源于stack exchange，提问作者Dojo