文章目录
传统 ZooKeeper 模式Controller 选举和管理
KRaft 模式（无 ZooKeeper 架构）KRaft Controller 架构KRaft Controller 工作原理选举机制对比
Controller 的作用Controller 保存的数据KRaft vs ZooKeeper 对比优势对比性能对比部署建议迁移考虑限制和注意事项
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 工作原理
Raft 选举：使用 Raft 算法选举 leader controller元数据存储：所有集群元数据存储在 __cluster_metadata topic 的单分区中状态同步：Controller 通过 Raft 协议保持状态一致性Broker 通信：Broker 从 Controller 拉取元数据增量更新
选举机制对比
特性ZooKeeper 模式KRaft 模式选举依赖外部 ZooKeeper内置 Raft 协议选举机制临时节点争抢Raft leader 选举故障切换时间分钟级秒级（近瞬时）元数据存储ZooKeeper znodesKafka 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 保存的数据
某个 broker 上的所有分区，所有副本某组 topic 的所有分区，所有副本当前存活的所有副本正在进行重分配的分区列表某组分区下的所有副本当前存活的 broker 列表正在关闭中的 broker 列表正在进行 preferred leader 选举的分区分配给每个分区的副本列表topic 列表每个分区的 leader 的 ISR 信息移除某个 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 PreviewKafka 3.3+：生产就绪Kafka 3.5+：ZooKeeper 官方弃用