Kafka 控制器(Controller)

Kafka 的 controller 是管理和协调整个 Kafka 集群的核心组件。根据部署模式的不同，Controller 有两种实现方式：

• 传统 ZooKeeper 模式：依赖外部 ZooKeeper 进行元数据管理和选举
• KRaft 模式：使用内置 Raft 协议，无需 ZooKeeper（Kafka 2.8+ 支持，3.3+ 生产就绪， 4.0 彻底舍弃 zookeeper）

传统 ZooKeeper 模式

Controller 选举和管理

Kafka 的 controller 是在 zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中的任意一个 Broker 都能充当控制器角色，但是，同一时间只能有一个控制器存在。

Controller 的选举规则是：当 broker 启动的时候，都会尝试去 zookeeper 中创建 /controller 节点，第一个成功创建 /controller 节点的 broker 就会被指定为控制器。

Controller 会主动向各个 broker 广播元数据更新，并发送更新元数据的请求。

如果控制器出问题，可以从 zookeeper 中删除 /controller 节点，触发 controller 的重新选举 rmr /controller

KRaft 模式（无 ZooKeeper 架构）

KRaft Controller 架构

KRaft（Kafka Raft）模式使用内置的 Raft 一致性协议替代 ZooKeeper 进行元数据管理。

核心组件：

• Controller Quorum（控制器仲裁组）：由 3 或 5 个 Controller 节点组成
• Active Controller（活跃控制器）：Raft leader，负责处理所有元数据更新
• Standby Controllers（备用控制器）：Raft followers，热备状态，快速故障切换
• 元数据日志：存储在专用的 __cluster_metadata 内部 topic 中

KRaft Controller 工作原理

1. Raft 选举：使用 Raft 算法选举 leader controller
2. 元数据存储：所有集群元数据存储在 __cluster_metadata topic 的单分区中
3. 状态同步：Controller 通过 Raft 协议保持状态一致性
4. Broker 通信：Broker 从 Controller 拉取元数据增量更新

选举机制对比

特性	ZooKeeper 模式	KRaft 模式
选举依赖	外部 ZooKeeper	内置 Raft 协议
选举机制	临时节点争抢	Raft leader 选举
故障切换时间	分钟级	秒级（近瞬时）
元数据存储	ZooKeeper znodes	Kafka topic

Controller 的作用

主题管理：创建、删除主题和增加分区(kafka-topics.sh)。

分区重分配：kafka-reassign-partitions.sh。

Preferred 领导者选举：为了避免 Broker 负责过高而提供的一种更换 Leader 的方案。

集群成员管理：

• ZooKeeper 模式：根据 Watch 功能和 zookeeper 临时节点组合实现的自动监测新增 broker、broker 主动关闭、broker 宕机。Zookeeper 的 Watch 机制会通知 Controller Broker 的变化。
• KRaft 模式：通过心跳机制和元数据日志监控 broker 状态变化。

数据服务：控制器上保存了集群的元数据，其他所有 broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

Controller 保存的数据

1. 某个 broker 上的所有分区，所有副本
2. 某组 topic 的所有分区，所有副本
3. 当前存活的所有副本
4. 正在进行重分配的分区列表
5. 某组分区下的所有副本
6. 当前存活的 broker 列表
7. 正在关闭中的 broker 列表
8. 正在进行 preferred leader 选举的分区
9. 分配给每个分区的副本列表
10. topic 列表
11. 每个分区的 leader 的 ISR 信息
12. 移除某个 topic 的所有信息

KRaft vs ZooKeeper 对比

优势对比

方面	ZooKeeper 模式	KRaft 模式	KRaft 优势
架构复杂度	需要管理两套系统	单一系统	✅ 简化部署和运维
扩展性	~20万分区上限	数百万分区	✅ 大规模集群支持
故障恢复	分钟级	秒级	✅ 快速故障切换
启动时间	需加载 ZK 状态	状态已在内存	✅ 快速启动
监控复杂度	两套监控体系	统一监控	✅ 简化监控
安全模型	两套安全配置	统一安全模型	✅ 简化安全管理

性能对比

ZooKeeper 模式瓶颈：

• Controller需要同时维护ZooKeeper持久化存储和向Broker的RPC通信
• 元数据变更需要Controller写入ZooKeeper后再通过RPC通知各个Broker
• 大量watch机制和RPC调用带来额外开销

KRaft 模式改进：

• 直接 Controller → Broker 通信
• 基于 Kafka 高性能日志存储
• 事件驱动的元数据传播

部署建议

ZooKeeper 模式：

# ZooKeeper 集群配置（奇数节点）
zookeeper.connect=zk1:2181,zk2:2181,zk3:2181

KRaft 模式：

# Controller 仲裁配置
process.roles=controller  # 专用 controller 节点
# 或
process.roles=broker,controller  # 组合模式（仅适用开发环境）

controller.quorum.voters=1@controller1:9093,2@controller2:9093,3@controller3:9093

迁移考虑

何时选择 KRaft：

• ✅ 新部署的 Kafka 集群（推荐）
• ✅ 需要大规模分区支持
• ✅ 希望简化运维复杂度
• ✅ 要求快速故障恢复

何时保持 ZooKeeper：

• ⚠️ 现有生产环境（迁移需谨慎）
• ⚠️ 依赖 ZooKeeper 的其他系统
• ⚠️ 需要某些 KRaft 尚不支持的特性

限制和注意事项

KRaft 模式限制：

• Combined 模式不建议生产使用
• 某些管理工具可能需要适配
• 迁移过程需要仔细规划

版本要求：

• Kafka 2.8+：Tech Preview
• Kafka 3.3+：生产就绪
• Kafka 3.5+：ZooKeeper 官方弃用