为什么kafka 2.8 要抛弃zk
1.运维问题
原生部署zk需要强制部署 zk，这使得kafka运维人员需要同时具备运维zk和kafka的能力
2.为了保证可用性
原生kafka与zk交互是依赖单个broker即Controller，如果旧broker故障了，会选举出一个
新的Controller节点。新的Controller继任成功，会从zk上拉取元数据同步初始化，同时通知其他broker更新
新的ActiveControllerID。且旧broker需要关闭监听、事件处理线程和定时任务。这个过程如果partition特别多，
那么就会导致整个过程非常漫长，且这个过程kafka是无法处理消息的，处于不可用状态
3.分区瓶颈
当分区数增加时，<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Zookeeper</font>保存的元数据变多，<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Zookeeper</font>集群压力变大，达到一定级别后，监听延迟增加，
给<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Kafaka</font>的工作带来了影响。所以，<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Kafka</font>单集群承载的分区数量是一个瓶颈。而这又恰恰是一些业务场景需要
的。
升级
<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">KIP-500</font>用<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Quorum Controller</font>代替之前的<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Controller</font>，<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Quorum</font>中每个<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Controller</font>节点都会保存所有
元数据，通过<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">KRaft</font>协议保证副本的一致性。这样即使<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Quorum Controller</font>节点出故障了，新的<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">Controlle</font>
<font style="color:rgb(10, 191, 91);background-color:rgb(243, 245, 249);">r</font>迁移也会非常快。
即由单个Controller变成了多个Controller，即由独裁变为了议会制
升级kafka后，官方说轻松支持百万partition