Kafka2.8 去除 Zookeeper

Kafka2.8 去除 Zookeeper

kafka目前的使用场景最多的还是网站用户行为分析，日志聚合等大数据处理场景，Kafka用户群体庞大，社区和资源完善，而且在2.8版本中去除了Zookeeper，部署非常容易。

Kafka中Zookeeper的作用？

• /brokers/ids:临时节点，保存所有broker节点信息，存储broker的物理地址、版本信息、启动时间等，节点名称为brokerID，broker定时发送心跳到zk，如过断开该节点会被删除
• /brokers/topics:临时节点，保存broker节点下所有的topic信息，每个topic节点包含一个固定的partitions节点，partitions的子节点就是topic分区，每个分区下保存一个state节点，保存着当前leader分区和ISR的brokerID，state由leader创建，如果leader宕机该节点删除，直到有新的leader选举产生，然后重新生成state节点

client 通过topic 找到topic树下的state节点，获取leader的brokerID，然后到broker树中找到broker的物理地址，client不会直连zk，而是通过配置的broker获取到zk中的信息。

一、Zookeeper的特性

• 临时节点
  临时节点是与会话关联的，一点创建该临时节点的会话结束，与之会被自动删除，无需应用方人工删除。
• 顺序节点
• 事件机制
  借助与事件机制，Zookeeper能及时通知存活的其他应用节点，重新触发选举，使得实现自动主从切换变的非常简单。

目前伴随着大数据、分布式领域的兴起。大数据中的一个非常重要的问题是如何使用众多廉价（发生故障概率高）的机器来实现可靠存储。为了实现数据一致性，通常需要从一个集群中挑选一台主节点用户处理数据的读写，其他节点从主节点拷贝数据，当主节点宕机，需要自动进行重新选举，实现高可用。这个就是Zookeeper的经典使用场景。

Kafka中存在众多的Leader选举，而基于Zookeeper能轻松实现

二、 Zookeeper缺点

Zookeeper是集群部署，只要集群中超过半数节点存活，即可提供服务。Zookeeper的设计是CP模型，即要保证数据的强一致性，必然在可用性方面做出牺牲。

Zookeeper集群中也存在所谓的Leader节点和从节点，Leader节点负责写，Leader与从节点可用接受读请求，但在Zookeeper内部节点在选举时整个Zookeeper无法对外提供服务。当然正常情况下选举会非常快，但在异常情况下就不好说了，例如Zookeeper节点发生full Gc，此时造成的影响将是毁灭性的。

Zookeeper节点如果频繁发生Full Gc，此时与客户端的会话将超时，由于此时无法响应客户端的心跳请求(Stop World)，从而与会话相关联的临时节点将被删除，此时是所有的临时节点会被删除，Zookeeper依赖的事件通知机制将失效，整个集群的选举服务将失效。

三、总结

站在高可用性的角度，Kafka集群的可用性不仅取决于自身，还受到了外部组件的制约，从长久来看，显然都不是一个好的解决方案。

随着分布式领域相关技术的不断完善，去中心化的思想逐步兴起， 在这个进程中涌现了一个非常优秀的算法：Raft协议。

Raft协议的两个重要组成部分：Leader选举（term+随机时间----先到先得，少数服从多数）、日志复制，而日志复制为多个副本提供数据强一致性提供了强一致性，并且一个显著的特点是Raft节点是去中心化的架构，不依赖外部的组件，而是作为一个协议簇嵌入到应用中的，即与应用本身是融合为一体的。

而且RocketMQ目前故障转移 就是基于raft协议，故最终Kafka在2.8版本中正式去除Zookeeper，拥抱Raft（无需依赖第三方组件）。