在2.8版本之前，kafka都是强依赖zookeeper这个分布式服务协调管理工具的。在kafka2.8版本开始尝试从服务架构中去掉zookeeper，到了3.0版本这个工作基本上完成，这是kafka的一个非常重要的里程碑。
如果想要理解kafka3.0的新架构设计，实际上我们还是有必要理解kafka2.x版本中中zookeeper的作用是什么？为什么要在3.0版本中去掉？使用什么技术代替了kafka？
一、zookeeper保存哪些元数据信息？
在kafka2.x版本中，zookeeper很重要的一个作用就是保存kafka集群运行的元数据信息，其实就是kafka集群运行过程中所需的一些集群节点运行状态信息、配置信息等。
/opt/zookeeper/default/bin/zkCli.sh -server 127.0.0.1:2181
在根目录下包含这样一些子目录
可以看到在zk当中保存了很多kafka集群的元数据信息
- /admin ： 用于保存kafka集群管理相关的信息，如已经被删除的topic。
- /brokers ： 用于保存当前集群的所有broker的id，和已经创建未被删除的topic
- /cluster : 用于保存kafka集群的id，kafka的集群存在一个唯一的id及版本信息保存在这里
- /config : 集群运行过程中的客户端、服务端、主题、用户等配置信息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dAIP6IT1-1652404640088)(http://cdn.zimug.com/0289c4e095fbc57d28054f704597c848)]
- /controller ： 用于保存kafka集群控制器组件的信息，如：版本号、控制器在哪个broker上、时间戳信息。controller会在后面章节中介绍。
- /controller_epoch ：用于记录controller选举的次数，每完成一次controller选举，该数据就加1。
- /isr_change_notification ： ISR列表发生变更时候，发出的通知信息。
- /latest_producer_id_block ：每个 Producer 在初始化时都会被分配一个唯一的 PID，pid开始结束范围以及申请结果保存在这里。
- /log_dir_event_notification ：如果broker在向磁盘写入数据的时候出现异常，信息保存在这里。 controller监听到该目录的变化之后会进行相应的处理。
二、kafka强依赖zk所引发的问题
通过上面的介绍，可以看到zookeeper对于kafka来说非常重要，它几乎保存了kafka集群的所有运行时状态信息，包括controller的选举、分区的管理、ISR列表的管理等等。
既然zookeeper这么重要，为什么还要将它从3.0中去掉？zookeeper的缺点在哪里？
- zookeeper是zookeeper的外部服务组件，所有的操作都要通过大量的网络来交互来实现，网络的开销降低了集群的性能。
- kafka生产者、消费者、broker在之前的版本中都涉及到与zookeeper的通信，导致网络复杂度非常高，性能下降。
- 从运维的角度来说，zookeeper需要独立进行安装、启动、维护。如果zookeeper集群节点出现问题，也会影响整个kafka集群的稳定性。
- zookeeper的目录节点太多会极大的影响性能，同时每一个znode节点都有1M的数据限制。随着kafka集群变大，zookeeper本身的数据保存能力也影响性能。随着zk保存数据量的增大，有的时候zookeeper重启一次要花费10分钟以上。
- 因kafka集群所有的运行的元数据信息都保存在zookeeper，这就导致一些kafka集群的监控软件在实现监控服务能力时候，既要连接kafka又要连接broker服务实例。
三、zookeeper的替代方案
正因为zookeeper与kafka结合可能存在的上述问题，kafka官方提案提出了"Kafka on Kafka"，将Kafka的元数据存储在Kafka自身中，无需增加额外的外部存储及协调管理工具，比如：ZooKeeper等。
在kafka3.0中一个非常重要的思想是：kafka集群的元数据信息被当作kafka日志(即：kafka消息)存在，更新配置信息的方式就是向kafka发送一条消息，读取配置信息的方式就是读取kafka某个配置队列中的最后一条数据。所以不在需要依赖zookeeper。
- 上图中左侧是kafka2.0的服务架构，三个小人代表zookeeper集群，黄褐色图标代表controller，黑色图标代表broker，所有的broker依赖于一个被选举出来的controller对其进行控制管理。controller服务实例实际上是三个broker其中的一个，其中的一个broker被选举出来被赋予controller的角色。
- 在kafka3.0（KIP - 500）服务架构下，上图右侧一共四个broker，其中三个被赋予controller的角色。在三个controller中选举其中一个作为主控制器。
- zookeeper的分布式数据服务协调能力，在kafka3.0版本中被raft协议所替代，从而是leader controller的选举和分区副本一致性得到保证。
kafka在去掉zookeeper之后，部署运维更加简单，监控实现更加便捷，同时性能得到了较大幅度的提升，号称可以支持百万级的分区副本。
关注本专栏，以下内容已经书写完成，将陆续在CSDN发布
