0%

Kafka指南-模块与职能划分

Kafka的是个复杂的系统,除了基本的Producer,Consumer,Broker外,为了实现完备的功能,Kafka中有许多重要的模块,本文梳理一下这些模块的划分,与他们负责的功能。

运行组件

基本上来说,正常的一个运行Kafka的业务,都需要4个组件:

  1. Broker。也就是Kafka服务器。
  2. Producer。也就是消息的生产者,负责把消息传入Broker。
  3. Consumer。消息的消费者,负责从Broker拉取消息。
  4. Zookeeper。Broker的运行需要Zookeeper保存一些元数据。

这四大组件的关系如下图所示:

流程也不用我多介绍了。
这里要提的一点就是,Consumer端不再感知Zookeeper了
这个其实是演进出来的,之前的Offset保存的方式导致了Consumer端必须要感知ZK的地址。
但是使用了新的Offset提交方式后,Consumer没有必要感知Zookeeper了,所以在新版本的启动参数中仅仅需要使用--bootstrap-server指定任意一个Broker地址就行了。

当然这个问题我也去搜集了一下答案:
新版kafka消费者、生产者配置为何使用bootstrap-servers而不是zookeeper服务器地址?

答案中提到了一个Kafka的提案,就是要取代Zookeeper。也是值得看一看的。

控制器

控制器,也叫Kafka Controller。
我们知道Kafka集群中,会有多个Broker,这些Broker并不是对等的关系,和Raft协议一样,其中一个Broker会被选举为Leader,也就是控制器,KafkaController。

为什么需要一个Leader呢?这个在我看来其实有两个原因。

  1. Zookeeper的性能有限。
  2. 避免复杂的逻辑。

在早期的Kafka版本中,其实没有控制器这个概念,所有的Broker都是对等的,很多复杂的逻辑难以解决,以及对ZK会造成很大的负载,笔者列举几个:

  1. 分区的ISR集合变更。每个分区的ISR集合,属于元数据,需要保存到每个Broker上的。分区的Leader副本所在的Broker会首先感知到该分区的ISR变更,它会把这个事件发布上ZK上,然后其他的Broker会监听到这个事件,更新自己的元数据。
  2. Leader副本出现问题。当一个分区的Leader副本出现问题时,需要重新选举出新的Leader副本,这个事件也是通过注册ZK的监听器实现的。
  3. Topic的分区分配,分区迁移,优先副本的选举:这是为了负载均衡的分布在不同的Broker上,如果没有Leader,随机的让这些决策由任意一个Broker去完成,会比较复杂。

所有加入KafkaController后,这个被选为Leader的Broker需要做很多事:

  1. 注册ZK的监听器,事件触发后,将信息传递给其他的Broker。
  2. 对集群的配置进行决策和任务发放

再具体一点:

  1. 分区Leader副本出现故障,选举出新的Leader副本
  2. ISR集合变更,通知给其他的Broker
  3. Topic的新增,删除,分区分配,分区迁移,副本管理
  4. 监听其他的Broker的变化,新增,删除等。

消费者协调器,组协调器

消费者协调器(ConsumerCoordinator),组协调器(GroupCoordinator)是为了解决旧版本的消费者再均衡问题而诞生的。

首先让我们思考一下消费组需要解决的问题。
通常来说,一个Topic会有多个分区,而每个分区,都会指派给一个Consumer会消费。

如上图所示,这个Topic共有4个partition,有3个Consumer。
Consumer0分配了P0和P1给它,Consumer1和Consumer2分别分配了P2和P3。

这样很美好,但是美好的事情总是不稳定。
如果Consumer0挂了呢?
那么我们需要把P0和P1分配给Consumer1和Consumer2。
如果多了一个Consumer加入,我们需要把P0分配给它。

这些就是消费者再均衡问题。
怎么解决这个问题呢?
旧版的Kafka中同样使用了很多的ZK的监听器去完成,很复杂。
问题有2:

  1. ZK负载较大。
  2. ZK本身的脑裂问题,会导致各个消费者拿到的消费组的状态不一致,产生问题。

解决这个问题的关键和Kafka的控制器的思路一致,我们需要引入Leader来完成重分配。
于是有了组协调器

组协调器(GroupCoordinator)

组协调器:Kafka将全部的消费组分成了多个子集,每个消费组的子集在服务端对应一个GroupCoordinator对其进行管理

组协调器是在服务端的,由某一个Broker担任。
有了组协调器后,某消费组中的所有消费者定时的向其发送心跳包,这样组协调器就能感知该消费组的消费者的个数变更,从而触发分区重分配。

好像解决重分配的问题,只要有了组协调器就行了?
是的,确实是的。

那么消费者协调器是干什么用的?
别急,等我慢慢道来。

消费者协调器

说到这个其实不能不提一个概念,分区分配规则
X个分区,Y个消费者,怎么分配分区给消费者呢?
当然我们可以轮询着来,但是作为一个完备的框架,这一层分配策略是需要抽象出来的,甚至可以由用户自定义的。

Kafka提供了消费者参数partition.assignment.strategy来进行配置,可选值如下:

  1. RangeAssignor:按照消费者总数和分区总数进行整除运算来获得一个跨度,然后将分区按照跨度进行平均分配,也是默认的分配策略。
  2. RoundRobinAssignor:轮询分配
  3. StickyAssignor:前面两种分配方式,都没有考虑分区和Consumer的状态,消费情况,以及之前的分配情况,这种分配结合前面两种状态来决定分配方式。

当然也可以进行自定义分配方式,需要我们在Consumer代码里进行编写。

所以问题来了,为什么配置是在Consumer端?
你可能想到了,灵活配置!

写到这儿,消费者协调器的存在就可以理解了,真正的分配其实并不是组协调器进行的,而是组协调器会在所有的Consumer中指定一个Leader,这个Leader就叫消费者协调器,真正的分配结果由这个Consumer来执行,消费者协调器把分配结果告诉组协调器,组协调器再通知给所有的消费者结果。

Welcome to my other publishing channels