点击上方“芋道源码”,选择“设为星标”
管她前浪,还是后浪?
能浪的浪,才是好浪!
每天 8:55 更新文章,每天掉亿点点头发...
源码精品专栏
在上个月 30 号, confluent 发布了一篇文章,文章上说在 Kafka 2.8 版本上将支持内部的 quorum 服务来替换 ZooKeeper 的工作。
![](https://i-blog.csdnimg.cn/blog_migrate/3629a1aeeae30acc850c95eb75684e6a.png)
其实去年我写的 Kafka 控制器事件处理全流程这篇文章已经提到这一点。
![](https://i-blog.csdnimg.cn/blog_migrate/c65bc270bdb8911c6b5f61f998ed2138.png)
今天再稍微展开来说说。
ZooKeeper 的作用
ZooKeeper 是一个开源的分布式协调服务框架,你也可以认为它是一个可以保证一致性的分布式(小量)存储系统。特别适合存储一些公共的配置信息、集群的一些元数据等等。
它有持久节点和临时节点,而临时节点这个玩意再配合 Watcher 机制就很有用。
当创建临时节点的客户端与 ZooKeeper 断连之后,这个临时节点就会消失,并且订阅了节点状态变更的客户端会收到这个节点状态变更的通知。
![](https://i-blog.csdnimg.cn/blog_migrate/401e369cf10c92f3ef9f088eb1cccc3b.png)
所以集群中某一服务上线或者下线,都可以被检测到。因此可以用来实现服务发现,也可以实现故障转移的监听机制。
Kafka 就是强依赖于 ZooKeeper,没有 ZooKeeper 的话 Kafka 都无法运行。ZooKeeper 为 Kafka 提供了元数据的管理,例如一些 Broker 的信息、主题数据、分区数据等等。
在每个 Broker 启动的时候,都会和 ZooKeeper 进行交互,这样 ZooKeeper 就存储了集群中所有的主题、配置、副本等信息。
![](https://i-blog.csdnimg.cn/blog_migrate/2329502041e10d44da3e39f63ac871c9.png)
还有一些选举、扩容等机制也都依赖 ZooKeeper 。
例如控制器的选举:每个 Broker 启动都会尝试在 ZooKeeper 注册/controller临时节点来竞选控制器,第一个创建/controller节点的 Broker 会被指定为控制器。
竞争失败的节点也会依赖 watcher 机制,监听这个节点,如果控制器宕机了,那么其它 Broker 会继续来争抢,实现控制器的 failover。
从上面就可以得知 ZooKeeper 对 Kafka 来说很重要 。
那为什么要抛弃 ZooKeeper
软件架构都是演进的,之所以要变更那肯定是因为出现了瓶颈。
先来看看运维的层面的问题。
首先身为一个中间件,需要依赖另一个中间件,这就感觉有点奇怪。
你要说依赖 Netty 这种,那肯定是没问题的。但是 Kafka 的运行需要提供 ZooKeeper 集群,这其实有点怪怪的。
就等于如果你公司要上 Kafka 就得跟着上 ZooKeeper ,被动了增加了运维的复杂度。
好比你去商场买衣服,要买个上衣,服务员说不单卖,要买就得买一套,这钱是不是多花了?
所以运维人员不仅得照顾 Kafka 集群,还得照顾 ZooKeeper 集群。
再看性能层面的问题。
ZooKeeper 有个特点,强一致性 。
如果 ZooKeeper 集群的某个节点的数据发生变更,则会通知其它 ZooKeeper 节点同时执行更新,就得等着大家(超过半数)都写完了才行,这写入的性能就比较差了。
![](https://i-blog.csdnimg.cn/blog_migrate/ad67cdc7ce0c3979ab868b2bd7b018ba.png)
然后看到上面我说的小量 存储系统了吧,一般而言,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。
图来自 confluent
这个协议是基于 Raft 的,协议具体就不展开了,就理解为它能解决 Controller Leader 的选举,并且让所有节点达成共识。
在之前基于 Zookeeper 实现的单个 Controller 在分区数太大的时候还有个问题,故障转移太慢了。
当 Controller 变更的时候,需要重新加载所有的元数据到新的 Controller 身上,并且需要把这些元数据同步给集群内的所有 Broker。
而 Controller Quorum 中的 Leader 选举切换则很快,因为元数据都已经在 quorum 中同步了,也就是 quorum 的 Broker 都已经有全部了元数据,所以不需要重新加载元数据!
并且其它 Broker 已经基于 Log 存储了一些元数据,所以只需要增量更新即可,不需要全量了。
这波改造下来就解决了之前元数据过多的问题,可以支持更多的分区!
最后
可能看到这里有人会说,那为何一开始不这么实现?
因为 ZooKeeper 是一个功能强大且经过验证的工具,在早期利用它来实现一些功能,多简单哟,都不需要自己实现。
要不是 ZooKeeper 的机制导致了这个瓶颈,也不可能会有这个改造的。
软件就是这样,没必要重复造轮子,合适就好。
欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢:
已在知识星球更新源码解析如下:
最近更新《芋道 SpringBoot 2.X 入门》系列,已经 20 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。
获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。
文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)