惠东做网站,策划公司网站,wordpress+移动端m,wordpress表单的增加与查询最近#xff0c;confluent社区发表了一篇文章#xff0c;主要讲述了Kafka未来的2.8版本将要放弃Zookeeper#xff0c;这对于Kafka用户来说#xff0c;是一个重要的改进。之前部署Kafka就必须得部署Zookeeper#xff0c;而之后就只要单独部署Kafka就行了。[1]1.Kafka简介Ap… 最近confluent社区发表了一篇文章主要讲述了Kafka未来的2.8版本将要放弃Zookeeper这对于Kafka用户来说是一个重要的改进。之前部署Kafka就必须得部署Zookeeper而之后就只要单独部署Kafka就行了。[1]1.Kafka简介Apache Kafka最早是由Linkedin公司开发后来捐献给了Apack基金会。Kafka被官方定义为分布式流式处理平台因为具备高吞吐、可持久化、可水平扩展等特性而被广泛使用。目前Kafka具体如下功能消息队列,Kafka具有系统解耦、流量削峰、缓冲、异步通信等消息队列的功能。分布式存储系统Kafka可以把消息持久化同时用多副本来实现故障转移可以作为数据存储系统来使用。实时数据处理Kafka提供了一些和数据处理相关的组件比如Kafka Streams、Kafka Connect具备了实时数据的处理功能。下面这张图是Kafka的消息模型[2]通过上面这张图介绍一下Kafka中的几个主要概念producer和consumer: 消息队列中的生产者和消费者生产者将消息推送到队列消费者从队列中拉取消息。consumer group:消费者集合这些消费者可以并行消费同一个topic下不同partition中的消息。brokerKafka集群中的服务器。topic消息的分类。partitiontopic物理上的分组一个topic可以有partition每个partition中的消息会被分配一个有序的id作为offset。每个consumer group只能有一个消费者来消费一个partition。2.Kafka和Zookeeper关系Kafka架构如下图从图中可以看到Kafka的工作需要Zookeeper的配合。那他们到底是怎么配合工作呢看下面这张图2.1 注册中心2.1.1 broker注册从上面的图中可以看到broker分布式部署就需要一个注册中心来进行统一管理。Zookeeper用一个专门节点保存Broker服务列表也就是 /brokers/ids。broker在启动时向Zookeeper发送注册请求Zookeeper会在/brokers/ids下创建这个broker节点如/brokers/ids/[0...N]并保存broker的IP地址和端口。❝这个节点临时节点一旦broker宕机这个临时节点会被自动删除。❞2.1.2 topic注册Zookeeper也会为topic分配一个单独节点每个topic都会以/brokers/topics/[topic_name]的形式记录在Zookeeper。一个topic的消息会被保存到多个partition这些partition跟broker的对应关系也需要保存到Zookeeper。partition是多副本保存的上图中红色partition是leader副本。当leader副本所在的broker发生故障时partition需要重新选举leader这个需要由Zookeeper主导完成。broker启动后会把自己的Broker ID注册到到对应topic节点的分区列表中。我们查看一个topic是xxx分区编号是1的信息命令如下[rootmaster] get /brokers/topics/xxx/partitions/1/state
{controller_epoch:15,leader:11,version:1,leader_epoch:2,isr:[11,12,13]}
❝当broker退出后Zookeeper会更新其对应topic的分区列表。❞2.1.3 consumer注册消费者组也会向Zookeeper进行注册Zookeeper会为其分配节点来保存相关数据节点路径为/consumers/{group_id}有3个子节点如下图:这样Zookeeper可以记录分区跟消费者的关系以及分区的offset。[3]2.2 负载均衡broker向Zookeeper进行注册后生产者根据broker节点来感知broker服务列表变化这样可以实现动态负载均衡。consumer group中的消费者可以根据topic节点信息来拉取特定分区的消息,实现负载均衡。❝实际上Kafka在Zookeeper中保存的元数据非常多看下面这张图随着broker、topic和partition增多保存的数据量会越来越大。❞3.Controller介绍经过上一节的讲述我们看到了Kafka对Zookeeper的依赖非常大Kafka离开Zookeeper是没有办法独立运行的。那Kafka是怎么跟Zookeeper进行交互的呢如下图[4]Kafka集群中会有一个broker被选举为Controller负责跟Zookeeper进行交互它负责管理整个Kafka集群中所有分区和副本的状态。其他broker监听Controller节点的数据变化。Controller的选举工作依赖于Zookeeper选举成功后Zookeeper会创建一个/controller临时节点。Controller具体职责如下监听分区变化❝比如当某个分区的leader出现故障时Controller会为该分区选举新的leader。当检测到分区的ISR集合发生变化时Controller会通知所有broker更新元数据。当某个topic增加分区时Controller会负责重新分配分区。❞监听topic相关的变化监听broker相关的变化集群元数据管理下面这张图展示了Controller、Zookeeper和broker的交互细节Controller选举成功后会从Zookeeper集群中拉取一份完整的元数据初始化ControllerContext这些元数据缓存在Controller节点。当集群发生变化时比如增加topic分区Controller不仅需要变更本地的缓存数据还需要将这些变更信息同步到其他Broker。Controller监听到Zookeeper事件、定时任务事件和其他事件后将这些事件按照先后顺序暂存到LinkedBlockingQueue中由事件处理线程按顺序处理这些处理多数需要跟Zookeeper交互Controller则需要更新自己的元数据。4.Zookeeper带来的问题Kafka本身就是一个分布式系统但是需要另一个分布式系统来管理复杂性无疑增加了。4.1 运维复杂度使用了Zookeeper部署Kafka的时候必须要部署两套系统Kafka的运维人员必须要具备Zookeeper的运维能力。4.2 Controller故障处理Kafaka依赖一个单一Controller节点跟Zookeeper进行交互如果这个Controller节点发生了故障就需要从broker中选择新的Controller。如下图,新的Controller变成了broker3。新的Controller选举成功后会重新从Zookeeper拉取元数据进行初始化并且需要通知其他所有的broker更新ActiveControllerId。老的Controller需要关闭监听、事件处理线程和定时任务。分区数非常多时这个过程非常耗时而且这个过程中Kafka集群是不能工作的。4.3 分区瓶颈当分区数增加时Zookeeper保存的元数据变多Zookeeper集群压力变大达到一定级别后监听延迟增加给Kafaka的工作带来了影响。所以Kafka单集群承载的分区数量是一个瓶颈。而这又恰恰是一些业务场景需要的。5.升级升级前后的架构图对比如下KIP-500用Quorum Controller代替之前的ControllerQuorum中每个Controller节点都会保存所有元数据通过KRaft协议保证副本的一致性。这样即使Quorum Controller节点出故障了新的Controller迁移也会非常快。官方介绍升级之后Kafka可以轻松支持百万级别的分区。❝Kafak团队把通过Raft协议同步数据的方式Kafka Raft Metadata mode,简称KRaft❞Kafka的用户体量非常大在不停服的情况下升级是必要的。目前去除Zookeeper的Kafka代码KIP-500已经提交到trunk分支并且计划在未来的2.8版本发布。Kafaka计划在3.0版本会兼容Zookeeper Controller和Quorum Controller这样用户可以进行灰度测试。[5]6.总结在大规模集群和云原生的背景下使用Zookeeper给Kafka的运维和集群性能造成了很大的压力。去除Zookeeper是必然趋势这也符合大道至简的架构思想。Reference[1]参考1: https://www.confluent.io/blog/kafka-without-zookeeper-a-sneak-peek/[2]参考2: https://blog.csdn.net/Zidingyi_367/article/details/110490910[3]参考3: https://www.jianshu.com/p/a036405f989c[4]参考4: https://honeypps.com/mq/kafka-controller-analysis/[5]参考5: https://mp.weixin.qq.com/s/ev6NM6hptltQBuTaCHJCQQ
