运维复杂度 同时运维 zk 和 kafka

Controller故障处理
Kafaka依赖一个单一Controller节点跟Zookeeper进行交互，
如果这个Controller发生故障，需要从broker中选择新的Controller
新的Controller选举成功后，重新从Zookeeper拉取元数据进行初始化，
并且需要通知其他broker更新ActiveControllerId
老的Controller需要关闭监听、事件处理线程和定时任务
分区数很多时，这个过程非常耗时，而且这个过程中Kafka集群不能工作

分区瓶颈
当分区数增加时，Zookeeper保存的元数据变多，Zookeeper集群压力变大，
达到一定级别后，监听延迟增加，给Kafaka的工作带来了影响


KIP-500用Quorum Controller代替之前的Controller
Quorum中每个Controller节点都会保存所有元数据
通过KRaft协议保证数据一致性
如果 Quorum Controller节点出故障了，新的Controller迁移会非常快

官方介绍，升级之后，Kafka可以轻松支持百万级别的分区

KRaft 通过Raft协议同步数据  Kafka Raft Metadata mode 

目前去除Zookeeper的Kafka代码KIP-500 已经在2.8版本发布



Kafka集群中会有一个broker被选举为Controller 负责跟Zookeeper进行交互
负责管理整个Kafka集群中所有分区和副本的状态
其他broker监听Controller节点的数据变化

Controller的选举依赖Zookeeper
选举成功后，Zookeeper 创建 /controller 临时节点

Controller具体职责
监听分区变化
当某个分区leader出现故障时，Controller为该分区选举新的leader
当检测到分区的ISR集合发生变化时，Controller会通知所有broker更新元数据
当某个topic增加分区时，Controller会负责重新分配分区

监听topic相关的变化
监听broker相关的变化
集群元数据管理




 kafka在zookeeper中的元数据  
 zookeeper在kafka中的应用