# Kafka Controller * 控制器组件 aka. Controller * 作用：在 ZK 的帮助下管理和协调整个 Kafka 集群 * 任意一台 Broker 可以成为 Controller，但是只有一台会是 Controller * Controller 重度依赖 ZK ZK * 提供高可靠性的分布式协调服务框架 * ZK 使用文件系统的树形结构构建数据模型 * 每个节点称为 znode，可以保存一些元数据协调信息 * 以 znode 的持久性划分 * 持久性 znode * 不会因为 ZK 重启而消失 * 临时 znode * 与创建 znode 的 ZK session 绑定，session 结束，节点自动删除 * ZK 允许 Client 通过 watch 监控 znode * Kafka Controller 通过 watch 实现对 Kafka 集群的协调管理 ## 控制器的选取 * Broker 启动时，会尝试创建 ZK 中 /controller znode * 第一个创建 /controller 的 Broker 会是 Controller ## 控制器的功能 * topic 管理 * 当使用 kafka-topics 脚本时，后台工作通过 controller 完成 * 分区重分配 * i.e. kafka-reassign-partitions 脚本 * 对已有 topic 分区进行细粒度的分配 * Preferred Leader 选举 * 目的：Kafka 为了避免部分 Broker 负载过重而提供的一种换 Leader 的方案 * 集群成员管理（新增 Broker、Broker 主动关闭、Broker 宕机） * 自动检测 Broker * controller 通过 watch 机制检查 ZK 的 /brokers/ids 子节点数量变更 * 数据服务 * controller 向其他 Broker 提供数据服务 * controller 上保存了最全的集群元数据  ## 控制器故障转移 Failover * Controller 存在单点 * 故障转移：当运行中的 Controller 突然宕机，Kafka 能够快速感知，并立即启用备用 Controller 代替之前失败的 Controller，这个过程称为 Failover  ## Controller 设计原理 * Kafka 0.11 版本之前，设计复杂 * Controller 是多线程 * 每个 Broker 都创建一个对应的 Socket，再创建一个专属线程 * Controller 连接 ZK session，也会创建单独的线程处理 watch 机制的回调 * Controller 还会为 topic 删除创建额外的 IO 线程 * 这些线程会访问共享的 Controller 缓存数据 * 因此大量使用 ReentrantLock 同步机制，拖慢整个 Controller 处理速度 * 0.11 版本重构 * 把多线程方案改成单线程加事件队列的方案  * 事件处理线程 Event Executor Thread * 统一处理 controller event * 负责缓存状态变更工作 * 优势 * Controller 缓存只被一个线程处理，不需要同步机制保证线程安全 * 同步操作 ZK 全部改为异步 * ZK API 提供同步、异步两种方式 * 2.2 版本 * 支持不同优先级的请求处理，i.e. 抢占式处理 ## Tips * 如果发现 controller 出现问题，不需要重启 Kafka Broker * 只需要连接 ZK，手动删除 /controller