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(无需依赖第三方组件)。