（此文转载自乐字节）
ZooKeeper 的作用
ZooKeeper 是一个开源的分布式协调服务框架，你也可以认为它是一个可以保证一致性的分布式(小量)存储系统。特别适合存储一些公共的配置信息、集群的一些元数据等等。
它有持久节点和临时节点，而临时节点这个玩意再配合 Watcher 机制就很有用。 当创建临时节点的客户端与 ZooKeeper 断连之后，这个临时节点就会消失，并且订阅了节点状态变更的客户端会收到这个节点状态变更的通知。
所以集群中某一服务上线或者下线，都可以被检测到。因此可以用来实现服务发现，也可以实现故障转移的监听机制。
Kafka 就是强依赖于 ZooKeeper，没有 ZooKeeper 的话 Kafka 都无法运行。ZooKeeper 为 Kafka 提供了元数据的管理，例如一些 Broker 的信息、主题数据、分区数据等等。
在每个 Broker 启动的时候，都会和 ZooKeeper 进行交互，这样 ZooKeeper 就存储了集群中所有的主题、配置、副本等信息。
还有一些选举、扩容等机制也都依赖 ZooKeeper 。
例如控制器的选举：每个 Broker 启动都会尝试在 ZooKeeper 注册/controller临时节点来竞选控制器，第一个创建/controller节点的 Broker 会被指定为控制器。
竞争失败的节点也会依赖 watcher 机制，监听这个节点，如果控制器宕机了，那么其它 Broker 会继续来争抢，实现控制器的 failover。
从上面就可以得知 ZooKeeper 对 Kafka 来说很重要。
那为什么要抛弃 ZooKeeper 软件架构都是演进的，之所以要变更那肯定是因为出现了瓶颈。
先来看看运维的层面的问题。
首先身为一个中间件，需要依赖另一个中间件，这就感觉有点奇怪。
你要说依赖 Netty 这种，那肯定是没问题的。但是 Kafka 的运行需要提供 ZooKeeper 集群，这其实有点怪怪的。
就等于如果你公司要上 Kafka 就得跟着上 ZooKeeper ，被动了增加了运维的复杂度。 好比你去商场买衣服，要买个上衣，服务员说不单卖，要买就得买一套，这钱是不是多花了？
所以运维人员不仅得照顾 Kafka 集群，还得照顾 ZooKeeper 集群。
再看性能层面的问题。
ZooKeeper 有个特点，强一致性。
如果 ZooKeeper 集群的某个节点的数据发生变更，则会通知其它 ZooKeeper 节点同时执行更新，就得等着大家（超过半数）都写完了才行，这写入的性能就比较差了。
然后看到上面我说的小量存储系统了吧，一般而言，ZooKeeper 只适用于存储一些简单的配置或者是集群的元数据，不是真正意义上的存储系统。
如果写入的数据量过大，ZooKeeper 的性能和稳定性就会下降，可能导致 Watch 的延时或丢失。
所以在 Kafka 集群比较大，分区数很多的时候，ZooKeeper 存储的元数据就会很多，性能就差了。
还有，ZooKeeper 也是分布式的，也需要选举，它的选举也不快，而且发生选举的那段时候是不提供服务的！
基于 ZooKeeper 的性能问题 Kafka 之前就做了一些升级。
例如以前 Consumer 的位移数据是保存在 ZooKeeper 上的，所以当提交位移或者获取位移的时候都需要访问 ZooKeeper ，这量一大 ZooKeeper 就顶不住。
所以后面引入了位移主题（Topic 是 __consumer_offsets），将位移的提交和获取当做消息一样来处理，存储在日志中，避免了频繁访问 ZooKeeper 性能差的问题。
还有像一些类似乐字节这样的大公司，可能要支持百万分区级别，这目前的 Kafka 单集群架构下是无法支持稳定运行的，也就是目前单集群可以承载的分区数有限。
所以，Kafka 需要去 ZooKeeper 。
所以没了 Zookeeper 之后的 Kafka 的怎样的？
没了 Zookeeper 的 Kafka 就把元数据存储到自己内部了，利用之前的 Log 存储机制来保存元数据。
就和上面说到的位移主题一样，会有一个元数据主题，元数据会像普通消息一样保存在 Log 中。
所以元数据和之前的位移一样，利用现有的消息存储机制稍加改造来实现了功能，完美！
然后还搞了个 KRaft 来实现 Controller Quorum。
这个协议是基于 Raft 的，协议具体就不展开了，就理解为它能解决 Controller Leader 的选举，并且让所有节点达成共识。
在之前基于 Zookeeper 实现的单个 Controller 在分区数太大的时候还有个问题，故障转移太慢了。
当 Controller 变更的时候，需要重新加载所有的元数据到新的 Controller 身上，并且需要把这些元数据同步给集群内的所有 Broker。
而 Controller Quorum 中的 Leader 选举切换则很快，因为元数据都已经在 quorum 中同步了，也就是 quorum 的 Broker 都已经有全部了元数据，所以不需要重新加载元数据！
并且其它 Broker 已经基于 Log 存储了一些元数据，所以只需要增量更新即可，不需要全量了。
这波改造下来就解决了之前元数据过多的问题，可以支持更多的分区！
最后
可能看到这里有人会说，那为何一开始不这么实现？
因为 ZooKeeper 是一个功能强大且经过验证的工具，在早期利用它来实现一些功能，多简单哟，都不需要自己实现。
要不是 ZooKeeper 的机制导致了这个瓶颈，也不可能会有这个改造的。
软件就是这样，没必要重复造轮子，合适就好。
PS：给大家推荐个特别牛的Kafka自学课程，B站：BV1Bf4y1W7B6
