最近，confluent社区发表了一篇文章，主要讲述了Kafka未来的2.8版本将要放弃ZookeepeR，这对于Kafka用户来说，是一个重要的改进。之前部署Kafka就必须得部署ZookeepeR，而之后就只要单独部署Kafka就行了。
一、Kafka简介
Apache Kafka最早是由linkedin公司开发，后来捐赠给了Apack基金会。
Kafka被官方定义为分布式流式处理平台，因为具备高吞吐、可持久化、可水平扩展等特性而被广泛使用。目前Kafka具体如下功能：
消息队列,Kafka具有系统解耦、流量削峰、缓冲、异步通信等消息队列的功能。 分布式存储系统，Kafka可以把消息持久化，同时用多副本来实现故障转移，可以作为数据存储系统来使用。 实时数据处理，Kafka提供了一些和数据处理相关的组件，比如Kafka StReaMs、Kafka Connect，具备了实时数据的处理功能。
下面这张图是Kafka的消息模型：
通过上面这张图，介绍一下Kafka中的几个主要概念：
ProdUCeR和consuMeR: 消息队列中的生产者和消费者，生产者将消息推送到队列，消费者从队列中拉取消息。 consuMeR gRoup:消费者集合，这些消费者可以并行消费同一个topic下不同paRtITion中的消息。 bRokeR：Kafka集群中的服务器。 topic：消息的分类。 paRtITion：topic物理上的分组，一个topic可以有paRtITion，每个paRtITion中的消息会被分配一个有序的id作为oFFset。每个consuMeR gRoup只能有一个消费者来消费一个paRtITion。 二、Kafka和ZookeepeR关系
Kafka架构如下图：
从图中可以看到，Kafka的工作需要ZookeepeR的配合。那他们到底是怎么配合工作呢?
看下面这张图：
1、注册中心 1)bRokeR注册
从上面的图中可以看到，bRokeR分布式部署，就需要一个注册中心来进行统一管理。ZookeepeR用一个专门节点保存BRokeR服务列表，也就是 /bRokeRs/ids。
bRokeR在启动时，向ZookeepeR发送注册请求，ZookeepeR会在/bRokeRs/ids下创建这个bRokeR节点，如/bRokeRs/ids/[0…N]，并保存bRokeR的IP地址和端口。
这个节点临时节点，一旦bRokeR宕机，这个临时节点会被自动删除。
2) topic注册
ZookeepeR也会为topic分配一个单独节点，每个topic都会以/bRokeRs/topics/[topic_naMe]的形式记录在ZookeepeR。
一个topic的消息会被保存到多个paRtITion，这些paRtITion跟bRokeR的对应关系也需要保存到ZookeepeR。
paRtITion是多副本保存的，上图中红色paRtITion是leadeR副本。当leadeR副本所在的bRokeR发生故障时，paRtITion需要重新选举leadeR，这个需要由ZookeepeR主导完成。
bRokeR启动后，会把自己的BRokeR ID注册到到对应topic节点的分区列表中。
我们查看一个topic是xxx，分区编号是1的信息，命令如下：
[Root@Master] get /bRokeRs/topics/xxx/paRtITions/1/state {“contRolleR_epoch”:15,”leadeR”:11,”veRsion”:1,”leadeR_epoch”:2,”isR”:[11,12,13]}
当bRokeR退出后，ZookeepeR会更新其对应topic的分区列表。
3)consuMeR注册
消费者组也会向ZookeepeR进行注册，ZookeepeR会为其分配节点来保存相关数据，节点路径为/consuMeRs/{gRoup_id}，有3个子节点，如下图:
这样ZookeepeR可以记录分区跟消费者的关系，以及分区的oFFset。
2、负载均衡
bRokeR向ZookeepeR进行注册后，生产者根据bRokeR节点来感知bRokeR服务列表变化，这样可以实现动态负载均衡。
consuMeR gRoup中的消费者，可以根据topic节点信息来拉取特定分区的消息,实现负载均衡。
实际上，Kafka在ZookeepeR中保存的元数据非常多，看下面这张图：
随着bRokeR、topic和paRtITion增多，保存的数据量会越来越大。
三、ContRolleR介绍
经过上一节的讲述，我们看到了Kafka对ZookeepeR的依赖非常大，Kafka离开ZookeepeR是没有办法独立运行的。那Kafka是怎么跟ZookeepeR进行交互的呢?
如下图：
Kafka集群中会有一个bRokeR被选举为ContRolleR负责跟ZookeepeR进行交互，它负责管理整个Kafka集群中所有分区和副本的状态。其他bRokeR监听ContRolleR节点的数据变化。
ContRolleR的选举工作依赖于ZookeepeR，选举成功后，ZookeepeR会创建一个/contRolleR临时节点。
ContRolleR具体职责如下：
监听分区变化
比如当某个分区的leadeR出现故障时，ContRolleR会为该分区选举新的leadeR。当检测到分区的ISR集合发生变化时，ContRolleR会通知所有bRokeR更新元数据。当某个topic增加分区时，ContRolleR会负责重新分配分区。
监听topic相关的变化 监听bRokeR相关的变化 集群元数据管理
下面这张图展示了ContRolleR、ZookeepeR和bRokeR的交互细节：
ContRolleR选举成功后，会从ZookeepeR集群中拉取一份完整的元数据初始化ContRolleRcontext，这些元数据缓存在ContRolleR节点。当集群发生变化时，比如增加topic分区，ContRolleR不仅需要变更本地的缓存数据，还需要将这些变更信息同步到其他BRokeR。
ContRolleR监听到ZookeepeR事件、定时任务事件和其他事件后，将这些事件按照先后顺序暂存到linkedBlockingQueue中，由事件处理线程按顺序处理，这些处理多数需要跟ZookeepeR交互，ContRolleR则需要更新自己的元数据。
四、ZookeepeR带来的问题
Kafka本身就是一个分布式系统，但是需要另一个分布式系统来管理，复杂性无疑增加了。
1、运维复杂度
使用了ZookeepeR，部署Kafka的时候必须要部署两套系统，Kafka的运维人员必须要具备ZookeepeR的运维能力。
2、ContRolleR故障处理
Kafka依赖一个单一ContRolleR节点跟ZookeepeR进行交互，如果这个ContRolleR节点发生了故障，就需要从bRokeR中选择新的ContRolleR。如下图,新的ContRolleR变成了bRokeR3。
新的ContRolleR选举成功后，会重新从ZookeepeR拉取元数据进行初始化，并且需要通知其他所有的bRokeR更新ActiveContRolleRId。老的ContRolleR需要关闭监听、事件处理线程和定时任务。分区数非常多时，这个过程非常耗时，而且这个过程中Kafka集群是不能工作的。
3、分区瓶颈
当分区数增加时，ZookeepeR保存的元数据变多，ZookeepeR集群压力变大，达到一定级别后，监听延迟增加，给Kafka的工作带来了影响。
所以，Kafka单集群承载的分区数量是一个瓶颈。而这又恰恰是一些业务场景需要的。
五、升级
升级前后的架构图对比如下：
KIP-500用QuoRuM ContRolleR代替之前的ContRolleR，QuoRuM中每个ContRolleR节点都会保存所有元数据，通过KRaft协议保证副本的一致性。这样即使QuoRuM ContRolleR节点出故障了，新的ContRolleR迁移也会非常快。
官方介绍，升级之后，Kafka可以轻松支持百万级别的分区。
KaFAk团队把通过Raft协议同步数据的方式Kafka Raft Metadata Mode,简称KRaft
Kafka的用户体量非常大，在不停服的情况下升级是必要的。
目前去除ZookeepeR的Kafka代码KIP-500已经提交到tRunk分支，并且已经在的2.8版本发布。
Kafka计划在3.0版本会兼容ZookeepeR ContRolleR和QuoRuM ContRolleR，这样用户可以进行灰度测试。
六、总结
在大规模集群和云原生的背景下，使用ZookeepeR给Kafka的运维和集群性能造成了很大的压力。去除ZookeepeR是必然趋势，这也符合大道至简的架构思想。
