Controller

定义与作用

Controller（控制器）是 Kafka 集群中负责管理分区和副本状态的特殊 Broker。每个集群同一时间只有一个 Active Controller，其他 Broker 在 Controller 故障时通过选举接替。Controller 的职责类似于分布式系统中的"协调者"——它不参与数据流的读写路径，但决定数据存储在哪些节点上、谁当 Leader。

核心原理

Controller 职责全景

Controller 选举过程（KRaft 模式）

KRaft 与传统 ZooKeeper 模式的关键区别：

• ZooKeeper 模式：Controller 选举依赖 ZK 临时节点（ephemeral znode）
• KRaft 模式：Controller 选举通过 Raft 协议在 Metadata Topic 的 Quorum 中完成

Controller 故障转移时序

Controller 切换影响：在选举期间（通常 1-3 秒），创建 Topic、分区重分配等管理操作不可用，但已存在的 Producer/Consumer 的读写不受影响（它们直接连接 Leader 读写）。

完整示例

示例一：观察 Controller 切换

场景：3 Broker 集群，观察 Controller 角色和切换。

操作前环境：3 个 Broker 运行中。

步骤：

# 1. 查看当前 Controller（通过 JMX 或日志）
grep "Active controller" /opt/kafka/logs/server.log
# 或通过 Metadata Quorum 查看
bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status
# NodeId  LeaderId  LeaderEpoch  Status
# 1        --        ...          (查看哪个是 Active Controller)

# 2. 停止 Active Controller（假设是 Broker 1）
kill $(jps | grep "server1" | awk '{print $1}')

# 3. 查看 Broker 2 日志
tail -f /opt/kafka/logs/server.log
# INFO Transitioning to Active Controller (kafka.controller.KafkaController)
# INFO Elected as Active Controller

# 4. 验证新 Controller
bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9097 describe --status
# 现在 LeaderId 变为 2（或 3）

操作前后对比：

示例二：Controller 驱动的 Leader 选举

场景：某个 Partition 的 Leader 所在的 Broker 宕机，观察 Controller 如何选举新 Leader。

操作前环境：Topic demo，3 分区 3 副本。Partition 0 的 Leader 在 Broker 1，ISR=[1,2,3]。

步骤：

# 1. 查看 Partition 0 的分布
bin/kafka-topics.sh --describe --topic demo --bootstrap-server localhost:9092
# Partition: 0  Leader: 1  Replicas: 1,2,3  Isr: 1,2,3

# 2. 停止 Broker 1
kill $(jps | grep "server1" | awk '{print $1}')

# 3. 再次查看 Partition 0（此时 Broker 2 已是新 Controller）
bin/kafka-topics.sh --describe --topic demo --bootstrap-server localhost:9097
# Partition: 0  Leader: 2  Replicas: 1,2,3  Isr: 2,3

操作前后对比：

易错场景

易错 1：期望通过"轮流停 Controller"来触发"负载均衡"

场景：认为 Controller 会主动平衡各 Broker 的 Leader 分布。

事实：Controller 只在 Broker 宕机或新加入时触发 Leader 选举，不会在正常运行中主动搬迁 Leader 以实现负载均衡。

如需主动平衡：使用 kafka-reassign-partitions.sh 或 kafka-leader-election.sh。

易错 2：Controller 所在 Broker 承载过多 Leader 分区

场景：Controller 同时承担大量 Leader 分区。

后果：Controller 自身消耗更多的 CPU/内存用于元数据管理，可能影响其处理请求的延迟。

最佳实践：大型集群中，考虑让 Controller 节点独立（process.roles=controller，不作为 Broker）。

面试高频考点

Q：Controller 故障会影响已连接的 Producer/Consumer 吗？

A：不会直接影响。Producer 和 Consumer 的读写直接与 Leader 副本所在的 Broker 通信，不经过 Controller。Controller 只负责管理动作（选举、分配）。但 Controller 故障期间如果还有其他 Broker 故障，无法及时触发 Leader 选举，会导致受影响分区的读写暂时不可用——直到新 Controller 选出。