【Kafka核心原理解析】之技术概念与架构原理

原创
01/24 14:33
阅读数 5.1K

简介

Kafka起初是由LinkedIn公司采⽤Scala语⾔开发的⼀个多分区、多副本且基于ZooKeeper协调的分布式 消息系统,现已捐献给Apache基⾦会。⽬前Kafka已经定位为⼀个分布式流式处理平台,它以⾼吞吐、 可持久化、可⽔平扩展、⽀持流数据处理等多种特性被⼴泛使⽤。在0.10版本之前,Kafka主要定位是分布式、⾼吞吐、低延迟的消息引擎,平时⼯作中常⽤的消息中间件还有很多,⽐如RabbitMQ,RocketMQ等。

从0.10版本开始,Kafka提供了连接器(kafka connect)和流处理(kafka stream),定位也从消息引擎变为流式处理平台。⽬前⽐较流⾏的另⼀个流式处理平台Pulsar。Pulsar与Kafka的对⽐也被⼤家津津乐道,其⼤部分都是对⽐ Pulsar 和 Kafka 在性能、架构和特性⽅⾯的区别。

Kafka一些重要概念

  • Producer:消息⽣产者,向 Kafka Broker 发消息的客户端。
  • Consumer:消息消费者,从 Kafka Broker 取消息的客户端。
  • Consumer Group:消费者组(CG),消费者组内每个消费者负责消费不同分区的数据,提⾼消费能 ⼒。⼀个分区只能由组内⼀个消费者消费,消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的⼀个订阅者。
  • Broker:⼀台 Kafka 机器就是⼀个Broker。⼀个集群由多个 Broker 组成。⼀个 Broker 可以容纳多个 Topic。
  • Topic:可以理解为⼀个队列,Topic 将消息分类,⽣产者和消费者⾯向的是同⼀个Topic。
  • Partition:为了实现扩展性,提⾼并发能⼒,⼀个⾮常⼤的Topic 可以分布到多个 Broker (即服务器)上,⼀个Topic可以分为多个Partition,每个Partition是⼀个有序的队列。
  • Replica:副本,为实现备份的功能,保证集群中的某个节点发⽣故障时,该节点上的Partition数据不丢失,且 Kafka仍然能够继续⼯作,Kafka提供了副本机制,⼀个Topic的每个分区都有若⼲个副本,⼀个 Leader和若⼲个Follower。
  • Leader:每个分区多个副本的“主”副本,⽣产者发送数据的对象,以及消费者消费数据的对象,都 是 Leader。
  • Follower:每个分区多个副本的“从”副本,实时从 Leader中同步数据,保持和Leader数据的同步。Leader 发⽣故障时,某个Follower 还会成为新的Leader。
  • Offset:消费者消费的位置信息,监控数据消费到什么位置,当消费者挂掉再重新恢复的时候,可以从消费位置继续消费。
  • Zookeeper:Kafka集群能够正常⼯作,需要依赖于 Zookeeper,Zookeeper 帮助 Kafka 存储和 管理集群信息。

Kafka原理

控制器选举及恢复

控制器是Kafka的核⼼组件之⼀,它的主要作⽤是在 ZooKeeper 的帮助下协调和管理整个Kafka集群。 Kafka 利⽤ZooKeeper 的领导者选举机制,每个Broker 都会参与竞选主控制器,但是最终只会有⼀个 Broker 可以成为主控制器。

控制器有以下⼏个职责:

  • 监听分区相关的变化,例如:运⾏kafka-reassign-partitions.sh 脚本对已有主题分区的细粒度的分配功能
  • 监听主题相关的变化
  • 监听broker相关的变化

控制器选举:每个代理节点都会作为ZooKeeper的客户端,向ZooKeeper 服务端尝试创建 /controller 临时节点,但是最终只有 1 个Broker 可以成功创建临时节点。因为 /controller 节点是临时节点,当主控制器出现故障或者会话失效时,临时节点会被删除。此时所有的Broker 都会重新竞选 Leader,也就是尝试创建 /controller临时节点。

Kafka控制器将Broker节点信息存放在 ZooKeeper 的 /controller节点上,每个broker都会在内存中保存当前控制器的brokerid值,这个值可以标识为activeControllerId,每个broker还会对/controller节点添加监听器,以此来监听此节点的数据变化。

当/controller节点的数据发⽣变化时,每个broker都会更新⾃身内存中保存的activeControllerId。如果 broker在数据变更前是控制器,在数据变更后⾃身的brokerid值与新的activeControllerId值不⼀致,那 么就需要“退位”,关闭相应的资源。有可能控制器由于异常⽽下线,造成/controller这个临时节点被⾃动 删除;也有可能是其他原因将此节点删除了。

当/controller节点被删除时,每个broker都会进⾏选举。如果有特殊需要,则可以⼿动删除/controller节点来触发新⼀轮的选举,当然关闭控制器对应的broker以及⼿动向/controller节点写⼊新的brokerid所对应的数据同样可以触发新⼀轮的选举。

分区leader的选举

分区leader副本的选举由Kafka Controller 负责具体实施。当创建分区(创建主题或增加分区都有创建分区的动作)或分区上线(⽐如分区中原先的leader副本下线,此时分区需要选举⼀个新的leader上线来 对外提供服务)的时候都需要执⾏leader的选举动作。

基本思路是按照AR集合中副本的顺序查找第⼀个存活的副本,并且这个副本在ISR集合中。⼀个分区的 AR集合在分配的时候就被指定,并且只要不发⽣重分配的情况,集合内部副本的顺序是保持不变的,⽽ 分区的ISR集合中副本的顺序可能会改变。注意这⾥是根据AR的顺序⽽不是ISR的顺序进⾏选举的。举个 例⼦,集群中有3个节点:broker0、broker1、broker2,在某⼀时刻具有3个分区且副本因⼦为3的主题

quickstart的具体信息如下:

此时关闭broker0,那么对于分区2⽽⾔,存活的AR就变为[1,2],同时ISR变为[2,1]。此时查看主题 quickstart的具体信息,分区2的leader就变为了1⽽不是2。

如果ISR集合中没有可⽤的副本,那么此时还需要再检查⼀下所配置的unclean.leader.election.enable参 数(默认值为false)。如果这个参数配置为true,那么表示允许从⾮ISR列表中选举leader,从AR列表 中找到第⼀个存活的副本即为leader。

当分区进⾏重分配的时候也需要执⾏leader的选举动作。这个选举策略⽐较简单:从重分配的AR列表中 找到第⼀个存活的副本,且这个副本在⽬前的ISR列表中。当发⽣优先副本的选举时,直接将优先副本设置为leader即可,AR集合中的第⼀个副本即为优先副本。

还有⼀种情况就是当某节点被优雅地关闭(也就是执⾏ControlledShutdown)时,位于这个节点上的 leader副本都会下线,所以与此对应的分区需要执⾏leader的选举。这⾥的具体思路为:从AR列表中找 到第⼀个存活的副本,且这个副本在⽬前的ISR列表中,与此同时还要确保这个副本不处于正在被关闭的 节点上。

Kafka的核心概念我们就介绍到这里,下一篇文章,我们将为大家带带来Kafka分区分配策略的介绍。

写在最后

近年来,在AIOps领域快速发展的背景下,IT工具、平台能力、解决方案、AI场景及可用数据集的迫切需求在各行业迸发。 基于此,云智慧在2021年8月发布了AIOps社区,旨在树起一面开源旗帜,为各行业客户、用户、研究者和开发者们构建活跃的用户及开发者社区,共同贡献及解决行业难题、促进该领域技术发展。
社区先后 开源 了数据可视化编排平台-FlyFish、运维管理平台 OMP 、云服务管理平台-摩尔平台、 Hours 算法等产品。
 
可视化编排平台-FlyFish:
项目介绍:https://www.cloudwise.ai/flyFish.html
Github地址: https://github.com/CloudWise-OpenSource/FlyFish
Gitee地址: https://gitee.com/CloudWise/fly-fish
行业案例:https://www.bilibili.com/video/BV1z44y1n77Y/
部分大屏案例:
您可以添加小助手(xiaoyuerwie)备注:飞鱼。加入开发者交流群,可与业内大咖进行1V1交流!
也可通过小助手获取云智慧AIOps资讯,了解FlyFish最新进展!

 

展开阅读全文
加载中

作者的其它热门文章

打赏
0
9 收藏
分享
打赏
0 评论
9 收藏
0
分享
返回顶部
顶部