为什么kafka在2.8版本之后就弃用了ZooKeeper作为注册中心（详解kafka底层架构原理）？

kafka作为消息队列中重要一员的存在，它在大数据处理、日志记录等领域有着广泛的应用，本篇文章着手讲述kafka在底层架构上面为何会在2.8版本后弃用ZooKeeper作为中间件。

一、消息队列的功能

首先我们需要了解什么是消息队列，其实消息队列的本质就是一层中间件，在客户端与服务端通信时，由于传输的消息过多，服务端并不能够对消息进行及时处理，这时候消息队列就应运而生了，它就好比是学校门口的外卖柜，如果有消息来了，并不会马上被处理，而是等到服务端有空闲时再会进行处理。因此消息队列有几大功能：

（1）异步处理：

应用A发送消息到队列中，服务端的应用B不需要立刻处理，而是可以选择一个自己空闲的时候，再从队列中取出消息进行处理

（2）应用解耦：

在应用A发送消息到队列中后，假如这时应用B突然挂掉了，也不会影响应用A继续处理其他的服务

（3）流量削峰：

如果同一时间有大量请求打到应用A，应用B也不用立刻在同一时间处理大量请求，而是可以在一段平稳的时间按照自己速率来处理请求：

二、剖析kafka的底层架构原理

首先我们从最基础的消息队列看起：

很好理解，消息队列在这里就是一个中间层，用来协调生产者A与消费者B之间的服务通信，但是这样一个中间件只有一个生产者与消费者未免有点浪费，于是我们想到可以让多个生产者与多个消费者同时使用一个消息队列：

虽然这样增加了消息队列的可用性，但是多个生产者与消费者会同时争抢这个消息队列，导致陷入等待，那么我们可以根据不同消息的类型，将不同类型的消息分到不同的队列中，俗称topic

但是一个消息队列容量过大，当消费者想取出某一特定部分消息还是很慢，那么我们可以将消息队列氛围不同的partition分区，让每个消费者负责特定的patition分区：

但是如果将所有partition部署到一台机器上会导致单机负载过高，我们可以将不同的partition部署到多台机器上，这里每台机器就被称为broker：

但是如果broker所在的主机挂掉了，导致其所包含的partition消息丢失怎么办，没事，没有什么是多复制几份解决不了的，我们可以给每个partition多加几个副本就好，同时设置leader节点与follower节点，leader负责与生产者、消费者进行消息的转发处理，而follower只需要同步leader的信息，这样即使主节点leader挂掉了，也可以选择下一个follower作为新的主节点，提高可靠性，而leader与follower之间的同步也被称为replicas：

但是，如果考虑极端情况，所有的broker都挂掉了，岂不是数据完全丢失了，不用怕，我们可以定义持久化策略（数据一旦存储永远不会丢失），将存储的消息持久化到磁盘中，这样即使是电脑重启宕机数据也不会丢失，只需要从磁盘中读写即可

至此，有关于kafka的大致底层架构讲解完毕，那么问题来了，既然2.8版本之前的kafka依赖于ZooKeeper，那么在哪些功能方面需要ZooKeeper呢？

三、kafka使用ZooKeeper

我们看到，由于kafka会将一个消息队列分散为多个partition部署到多台机器上，这时如果有消费者来了想要取消息，必须获得对应partition分区所在的主机ip地址，那这时我们如何获取呢？总不能把ip地址写死在程序里吧，这时就需要注册中心来完成类似的功能。

注册中心的功能：

服务注册：

在分布式系统中，各个服务实例在启动时会向注册中心注册自己，包括服务的地址、端口、版本号等信息。这样，注册中心就能维护一个当前所有可用服务实例的目录。

服务发现：

客户端或其他服务需要调用某个服务时，可以通过注册中心查询该服务的所有可用实例。注册中心提供了一种机制，使得服务消费者能够找到服务提供者。

负载均衡：

注册中心通常与负载均衡器配合使用，后者可以根据注册中心提供的信息，将请求分发到不同的服务实例，以实现负载均衡，常见的负载均衡算法包括轮询、一致性哈希、随机、加权等。

故障转移和容错：

当某个服务实例不可用时，注册中心可以帮助客户端或负载均衡器重新路由请求到其他健康的服务实例，从而提高系统的容错能力。

配置管理：

在一些架构中，注册中心还可以用来管理和分发配置信息，使得服务实例能够根据配置动态调整行为。

健康检查：

注册中心可以配合健康检查机制，定期检查服务实例的健康状况，及时移除不健康的实例，保证服务质量。

而ZooKeeper作为注册中心的一种，kafka便使用ZooKeeper作为它的注册中心，来简化对于各种组件的管理，ZooKeeper在管理过程中，会定期与各个组件进行通信，如果当前组件挂掉了会移除当前broker，来保证kafka集群的服务状态

看到这里想必我们会思考，ZooKeeper作为kafka集群的注册中心不是挺好的吗，那为什么又要对它进行弃用呢，原因就在于ZooKeeper作为注册中心实在太重了，有很多功能压根用不到，还会增加维护成本与资源占用，举个例子：

ZooKeeper具有强一致性的特性，同时ZooKeeper也是基于分布式进行部署，也就是说如果有一个节点信息发生了更改，其他节点信息也要同步进行更改，如果数据量小同步速度快可以接受，但是如果大数据量场景下，同步速度就会显得有点差强人意了，而ZooKeeper的选举机制等也会带慢kafka集群的性能，因此kafka弃用ZooKeeper也就显得理所当然了

四、2.8版本后的Kraft模式

kafka2.8.0版本引入了基于Raft共识协议的新特性，由于篇幅有限，想了解raft协议的小伙伴可以自行了解，它允许kafka集群在没有ZooKeeper的情况下运行，KRaft的优势有以下几点：

简化部署：

Kafka 集群不再依赖外部的 ZooKeeper 集群，简化了部署和运维的复杂性。

提高性能：

由于元数据管理不再依赖 ZooKeeper，Kafka 集群的性能得到了提升，尤其是在元数据读写方面。

增强可扩展性：

KRaft 模式支持更大的集群规模，可以有效地扩展到数百万个分区。

更快的控制器故障转移：

控制器（Controller）的选举和故障转移速度更快，提高了集群的稳定性。

KRaft模式下，kafka集群中的一些节点被指定为控制器（Controller），它们负责集群的元数据管理和共识服务，所有的元数据都存储在kafka内部的主题中，而不是ZooKeeper，控制器通过KRaft协议来确保元数据在集群中的准确复制，这种模式使用了基于时间的存储模型，通过定期快照来保证元数据日志不会无限增长

综上所述，有关于kafka的底层架构以及2.8弃用ZooKeeper的原因就介绍完了，如果小伙伴看到这里有收获的话，不妨点个赞收藏一下，祝好！！！