Controller 是什么
Controller 是 Kafka 集群的「大脑」，负责分区 Leader 选举、主题创建与删除、副本状态维护、ISR 收缩等元数据层面的决策。它本身也是集群里的一个 broker，只是额外承担这些职责。ZooKeeper 模式下 controller 通过 ZK 选举产生、元数据存放在 ZK 中；KRaft 模式（Kafka 3.3 起生产可用）取消了 ZK，由 controller quorum 通过 Raft 协议自行复制元数据日志。集群级的疑难问题，第一个该看的就是 controller 的状态。
基本信息
| 适用版本 | ZooKeeper 模式：Kafka 2.x 及更早为主流；KRaft：3.3+ 生产可用 |
|---|---|
| 核心职责 | Leader 选举、主题与分区管理、副本状态协调 |
| ZK 模式 | 控制器经 ZK 选举产生，元数据存 ZooKeeper |
| KRaft 模式 | controller quorum 通过 Raft 维护元数据日志 |
典型使用场景
- 日常巡检：确认 controller 是否频繁切换、元数据 quorum 是否稳定
- 主题创建或删除异常时，先翻 controller 日志找根因
- 大量分区同时触发选主时，判断是元数据问题还是 broker 批量掉线
- 从 ZooKeeper 模式迁移到 KRaft 前的 quorum 规模与节点规划
- 元数据规模增长时评估 controller 节点是否需要独立部署
KRaft 元数据 quorum 检查
KRaft 元数据 quorum 检查
kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status # 看 leader 与成员
kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --replication # 看各节点日志末端位移
grep -i "controller" /opt/kafka/logs/controller.log | tail -50 # controller 侧线索
grep -iE "election|leader" /opt/kafka/logs/server.log | tail -50 # broker 侧选主记录
# ZK 模式的等价观察：直接查 ZK 中的 controller 节点
# zookeeper-shell.sh localhost:2181 get /controllerquorum 状态字段读法
| 字段 | 含义 | 异常表现 |
|---|---|---|
| LeaderId | 当前 controller leader | 频繁变化说明 quorum 不稳定 |
| CurrentVoters | 当前投票成员列表 | 成员缺失时容错能力下降 |
| LastFetchTimestamp | leader 最近一次拉取时间 | 长期不更新说明 follower 已落后 |
| MaxFollowerLag | follower 落后条数 | 持续增大预示元数据同步滞后 |
| ActiveControllerCount | broker 侧统计的活动控制器数 | 恒为 1 才正常，大于 1 存在脑裂风险 |
集群级异常（例如大量分区同时触发选主）先看 controller 日志与元数据 quorum 是否稳定，再看 broker 是否成批掉线；把顺序反过来很容易误判为磁盘或网络问题。
KRaft 集群把 controller 与 broker 混部时，controller 节点负载过高（网络抖动、磁盘延迟、CPU 抢占）会拖慢全集群的元数据操作，表现为主题创建、分区扩容、ISR 更新都变慢，而数据读写看上去正常。