Kafka2.8 去除 Zookeeper

6 篇文章 1 订阅
6 篇文章 0 订阅

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

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值