| 小菜鸟

Kafka 控制器（Controller）详解：集群的 “大脑”

Kafka 控制器是集群的核心协调者，负责管理分区状态、副本同步、代理（Broker）上下线、主题创建 / 删除等关键操作。它通过 ZooKeeper 实现集群元数据的管理与同步，确保整个 Kafka 集群的一致性和可用性。本文将深入解析控制器的核心功能、初始化过程、选举机制及关键管理流程。

控制器是 Kafka 集群中唯一的 Leader 协调节点，与分区的 Leader 副本（负责单分区读写）不同，它统筹整个集群的全局状态。其核心职责包括：

分区与副本管理：
- 监控分区状态（如 Online/Offline），在 Leader 故障时触发重新选举。
- 管理副本同步（ISR 列表维护），确保数据可靠性。
代理 lifecycle 管理：
- 处理 Broker 上线 / 下线事件，更新集群元数据。
- 在 Broker 故障时触发故障转移（Failover），重新分配分区所有权。
主题操作协调：
- 处理主题创建、删除、分区扩展等请求。
- 确保主题配置在集群中同步。
元数据同步：
- 向所有 Broker 广播元数据更新（如分区 Leader 变更、新 Broker 加入）。

理解控制器需先掌握以下关键概念：

术语	定义
controller_epoch	控制器世代号，记录控制器变更次数（初始为 0，每次选举新控制器加 1），用于区分过期请求。
leader_epoch	分区 Leader 世代号，记录单分区 Leader 变更次数，确保请求顺序性。
AR（Assigned Replicas）	分区的所有副本集合（包含 Leader 和 Follower）。
ISR（In-Sync Replicas）	与 Leader 保持同步的副本集合，只有 ISR 中的副本可被选为新 Leader。
优先副本（Preferred Replica）	AR 列表中的第一个副本，理想情况下应作为分区 Leader，用于负载均衡。
状态机	控制器通过 `PartitionStateMachine` 和 `ReplicaStateMachine` 管理分区和副本的状态变迁。

每个 Broker 启动时都会实例化 KafkaController 对象，但最终只有一个会成为 Leader 控制器。初始化步骤如下：

创建上下文（ControllerContext）：
缓存集群元数据，包括 Broker 列表、主题分区映射、AR/ISR 信息、controller_epoch 等。
初始化状态机：
- PartitionStateMachine：管理分区状态（4 种状态）：
  - NewPartition（0）：新建未分配 Leader；
  - OnlinePartition（1）：正常服务（有 Leader）；
  - OfflinePartition（2）：Leader 故障；
  - NonExistentPartition（3）：已删除。
- ReplicaStateMachine：管理副本状态（7 种状态）：
  - 如 NewReplica（新创建）、OnlineReplica（正常同步）、OfflineReplica（所在 Broker 故障）等。
注册 ZooKeeper 监听器：
控制器通过以下监听器感知集群变化：
- ControllerChangeHandler：监听 /controller 节点（控制器 Leader 变更）；
- BrokerChangeHandler：监听 /brokers/ids（Broker 上下线）；
- TopicChangeHandler：监听 /brokers/topics（主题创建 / 删除）；
- 其他监听器：处理分区重分配、优先副本选举等事件。
启动调度器与通信管理器：
- KafkaScheduler：定时任务（如优先副本均衡）；
- ControllerChannelManager：与其他 Broker 通信的网络组件。

控制器选举是确保集群有唯一协调者的关键过程，触发时机包括：

竞争创建 ZooKeeper 节点：
每个 Broker 启动时尝试在 ZooKeeper 中创建临时节点 /controller，内容为：
1
{"version":1,"brokerid":0,"timestamp":"1620000000000"}
第一个成功创建节点的 Broker 成为 Leader 控制器。
监听节点变更：
未成功创建节点的 Broker 会注册对 /controller 节点的监听器，当节点被删除（原控制器故障）时，重新触发选举。
更新 controller_epoch：
新控制器通过 ZooKeeper 原子操作递增 controller_epoch（存储在 /controller_epoch 节点），确保所有请求使用最新世代号，避免过期请求干扰。

当控制器故障（如 Broker 宕机），ZooKeeper 会删除 /controller 临时节点，触发以下流程：

控制器通过 BrokerChangeHandler 监听 /brokers/ids 节点（Broker 在此注册临时节点），处理上下线事件。

当新 Broker 加入集群时：

元数据更新：控制器将新 Broker 加入 ControllerContext，并通过 UpdateMetadataRequest 通知所有 Broker。
副本状态同步：若新 Broker 包含分区副本（如集群扩容时的预分配副本），ReplicaStateMachine 将其状态从 NewReplica 转为 OnlineReplica。
Leader 均衡：检查新 Broker 上的优先副本，若符合条件，触发 Leader 选举使其成为分区 Leader，平衡负载。

当 Broker 故障（节点被删除）时：

识别故障 Broker：控制器从 ControllerContext 中移除故障 Broker，标记其所有副本为 OfflineReplica。
分区 Leader 重选举：对故障 Broker 上的所有分区，通过 PartitionStateMachine 触发 Leader 选举（从 ISR 中选新 Leader）。
元数据广播：将新 Leader 信息通过 UpdateMetadataRequest 同步至全集群，确保生产者 / 消费者连接新 Leader。

创建主题：TopicChangeHandler 监听 /brokers/topics 节点，当新主题被创建时：
1. 控制器更新 ControllerContext 中的主题 - 分区映射；
2. 为新分区分配 AR 列表，初始化状态为 NewPartition；
3. 触发 Leader 选举，将分区状态转为 OnlinePartition。
删除主题：TopicDeletionHandler 监听 /admin/delete_topics 节点，控制器会：
1. 标记主题为删除状态，停止其分区的读写服务；
2. 通知所有 Broker 删除本地日志文件；
3. 从 ZooKeeper 中删除主题元数据。

当执行分区迁移（如节点下线、扩容）时，PartitionReassignmentHandler 监听 /admin/reassign_partitions 节点，控制器：