Kafka 2.8 新特征介绍
备注：本文修订于2021年5月23日
Kafka 2.8 新特征介绍
kafka官方发布了最新版本：kafka 2.8，发布时间是：2021年4月19日。
kafka 2.8 最大的特点是：移除了对zookeeper的依赖，见官网介绍：
Early access of replace ZooKeeper with a self-managed quorum
正式将ZooKeeper依赖移除，并替换为Kafka自我管理的仲裁机制
ZooKeeper是开源的分布式应用协调系统。在分布式系统中存在着大量的节点，它们各司其职，如果把各个节点比作各种小动物，那协调者就是动物园管理员，这也就是Zookeeper名称的由来。
大数据中的一个非常重要的优势是能使用众多廉价的机器来实现可靠存储。但是，廉价的机器发生故障的概率非常大，分布式领域希望使用多台机器组成一个集群，将数据存储在多台机器上(副本)，为了方便实现数据一致性，通常需要从集群中挑选一台Leader主节点用作处理数据的读写，而其他从节点拷贝数据。当主节点宕机，需要自动进行重新选举，实现高可用。上述场景中有一个非常重要的功能Leader选举，如何选举出一个主节点，并支持主节点宕机后自动触发重新选举，实现主从自动切换，实现高可用。使用ZooKeeper提供的临时顺序节点与事件监听机制，能非常轻松的实现Leader选举。
Kafka中存在众多的Leader选举，一个主题可以拥有多个分区(数据分片)，每一个数据分片可以配置多个副本，如何保证一个分区的数据在多个副本之间的一致性成为一个迫切的需求。Kafka的实现套路就是一个分区有多个副本，从中选举出一个Leader用来承担客户端的读写请求，从节点从主节点处拷贝内容，Leader节点根据数据在副本中成功写入情况，进行抉择来确定是否写入成功。故此处需要进行Leader选举，而基于ZooKeeper能轻松实现，从此一拍即合，开启了一段kafka牵手zookeeper的“蜜月之旅”。
Zookeeper的致命弱点
Zookeeper是集群部署，只要集群中超过半数节点存活，即可提供服务，例如一个由3个节点的Zookeeper，可允许1个Zookeeper节点宕机，集群仍然能提供服务；一个由５个节点的Zookeeper，允许2个节点宕机。但Zookeeper的设计是CP模型，即要保证数据的强一致性，必然在可用性方面做出牺牲。
Zookeeper集群中也存在所谓的Leader节点和从节点，Leader节点负责写，Leader与从节点可用接受读请求，但在Zookeeper内部节点在选举时整个Zookeeper无法对外提供服务。当然正常情况下选举会非常快，但在异常情况下就不好说了，例如Zookeeper节点发生Full GC，此时造成的影响将是毁灭性的。
如果Zookeeper节点频繁发生Full GC，此时与客户端的会话将超时，由于此时无法响应客户端的心跳请求(Stop World)，从而与会话相关联的临时节点将被删除，注意，此时是所有的临时节点会被删除，Zookeeper依赖的事件通知机制将失效，整个集群的选举服务将失效。
站在高可用性的角度，Kafka集群的可用性不仅取决于自身，还受到了外部组件的制约，从长久来看，显然都不是一个优雅的方案。
随着分布式领域相关技术的不断完善，去中心化的思想逐步兴起，去Zookeeper的呼声也越来越高，在这个过程中涌现了一个非常优秀的算法：Raft算法。
Raft算法有两个重要组成部分：Leader选举和日志复制，而日志复制为多个副本提供数据强一致性，并且一个显著的特点是Raft节点是去中心化的架构，不依赖外部的组件，而是作为一个协议簇嵌入到应用中的，即与应用本身是融合为一体的。
Raft算法为选主提供了另外一种可行方案，而且还无需依赖第三方组件，何乐而不为呢？故最终Kafka在2.8版本中正式废弃了Zookeeper，拥抱Raft。