kafka分区分配策略

前言

现有主流消息中间件都是生产者-消费者模型,主要角色都是:Producer -> Broker -> Consumer,上手起来非常简单,但仍有需要知识点需要我们关注,才能避免一些错误的使用情况,或者使用起来更加高效,例如本篇要讲的kafka分区分配策略。
在开始前我们先简单回顾一下kafka消息存储设计,如下图:

topic是一个逻辑概念,一个topic可以包含多个partition,partition才是物理概念,kafka将partition存储在broker磁盘上。如图,test_topic只有一个partition,那么在broker上就会一个test_topic-0的文件夹。在partition内部,kafka为方便管理和高效处理消息,进一步将消息的存储划分为多个segment,segment也是个逻辑概念,一个segment下主要包含:.log消息日志文件,存储实际消息的地方,.index索引文件,.timeindex时间索引文件。segment是滚动的,当达到配置的大小或者时间,kafka就会重新创建一个新的segment,并且会在一定的时间后将过期的segment删除。

其中每一个部分都是一个大的知识点,本次我们主要关注partition。一个partition会分配给一个consumer group中的一个consumer消费,partition是可扩展的,这为kafka消息消费提供强大扩展能力,如上只有一个patition,那么所有的消息都会发到这里,并且只能由一个消费者消费,这无疑会很慢。我们可以创建两个partition,然后起两个消费者,这样kafka就会为每个消费者分配一个分区,它们可以并发消费,消费速度得以提升。
那如果有3个partition呢,这个时候是怎么分的?如果有多个topic呢,这个时候又是怎么分的?如果有consumer上下线,又是怎么分呢?这就是我们接下来要讨论分区分配策略。

rebalance

在开始讨论分区分配策略之前,我们先了解一下rebalance这个概念。rebalance重平衡,是指在一定情况下,kafka将分区重新分配的过程。正常情况下我们的服务起来,分区分配好后,就稳定运行了,但一些情况下会导致kafka进行rebalance,将分区都重新分配一遍,这种情况主要包括:

  1. topic数发生了变化
  2. partition数发生了变化
  3. 消费者数发生了变化
  4. 消费者消费速度太慢,超过限制时间

举个例子,我们滚动发版,必然有的应用要先下线,再重新上线,这个时候对于kafka来说消费者就发生了变化,就会发生rebalance,rebalance也是按照我们配置的分区分配策略进行重新分配。
分区分配策略作用是将所有topic的partition按照一定规则分配给消费者,主要有4种分区分配策略,它们都实现了ConsumerPartitionAssignor接口,也可以实现该接口自定义分区分配算法。

分区的分配很容易会想到是有kafka server端计算和分配的,但其实不是,当触发分区分配时,kafka会从consumer中挑选一个作为leader,leader根据客户端配置的分配策略计算分区结果,然后发送回给kafka,再由kafka同步给其它的consumer follower。

举个例子,新增了一个消费者,rebalance过程大致如下:
该消费者发送一个请求告诉kafka,要加入消费者组。
kafka将消费者组状态切换到准备rebalance,关闭和消费者的所有链接,等待它们重新加入。
客户端重新申请加入,kafka从消费者组中挑选一个作为leader,其它的作为follower。
kafka将一些元信息同步给所有消费者。
follower不断发送请求给kafka,请求它们的partition。
leader根据分区分配策略计算分区结果,并将结果返回给kafka。
kafka将计算结果返回给follower。
所有消费者根据分区结果开始消费消息。

注意,rebalance的发生不是个好事情,kafka需要重新计算分区信息,重新分配,清理资源,当你的集群比较大的时候,频繁rebalance可能会影响性能。

4种分区分配策略

RangeAssignor

范围分配,按照每个topic的partition数计算出每个消费者应该分配的分区数量,然后分配。
假设有2个topic,每个topic有2个分区,如下:

T0:P00,P01
T1:P10,P11

有两个消费者C0,C1,那么range分配结果如下:

C0:P00,P10
C1:P01,P11

看起来很顺畅,也很均衡,但如果T0新增一个P02呢,那么分配就会如下:

C0:P00,P01,P10
C1:P02,P11

看起来也还好,毕竟两个人分3个苹果,会有人多一个。那如果T1也新增一个P12呢,那么分配就会如下:

C0:P00,P01,P10,P11
C1:P02,P12

看起来好像不怎么好了,C0又多了一个分区,如果有更多的topic有这种情况,那么C0的压力无疑会比C1大很多。
这是由于range分配是按照每个topic来计算的,这可能会导致consumer的分配不均匀。

RoundRobinAssignor

循环分配,按照所有topic的partition循环分配。
假设有2个topic,每个topic有2个分区,如下:

T0:P00,P01
T1:P10,P11

有两个消费者C0,C1,那么循环分配结果如下:

C0:P00,P10
C1:P01,P11

如果T0新增一个P02呢,那么分配就会如下:

C0:P00,P02,P10
C1:P01,P11

如果T1也新增一个P12呢,那么分配就会如下:

C0:P00,P02,P11
C1:P01,P10,P12

和range不同这里每个消费者分到的分区数还是相等的。按照循环分配逻辑,消费者分配到分区数偏差不会超过1。

StickyAssignor

range和roundrobin的问题是,当发生rebalance的时候,分区的分配结果变化会很大,理想情况是分配结果不要有很大变化,例如消费者可能根据partition做了本地缓存,分配结果都变了相当于缓存都失效了,可能对消费者会有影响。所有有了StickAssignor,粘性分配,从字面理解,粘性分配就是原本是你的,还是尽量分配给你,例如发生rebalance的时候。粘性分配的核心思想是优先保证分区分配均衡,然后尽可能保留现有的分配结果。

假设有3个topic,每个topic有3个分区,如下:

T0:P00,P01,P02
T1:P10,P11,P12
T2:P20,P21,P22

有3个消费者C0,C1,C2,那么roundrobin分配结果如下:

C0:P00,P10,P20
C1:P01,P11,P21
C2:P02,P12,P22

假设C2下线了,触发了rebalance,roundrobin重新分配结果如下:

C0:P00,P02,P11,P20,P22
C1:P01,P10,P12,P21

可以看到T0,T1的也重新分配了,有4个partition重新分配了。如果使用sticky分配,结果就会是:

C0:P00,P10,P20,P20,P22
C1:P01,P11,P21,P21,

可以看到,T0,T1的没有任何变化,还是原来的消费者,这就是粘性的含义。

CooperativeStickAssignor

上面的3种分配策略使用的都是eager协议,eager协议的特点是整个rebalance会"stop the world",消费者会放弃当前的分区,关闭连接,资源清理,然后静静等待分配结果。
CooperativeStickAssignor是2.4版本开始提供的,使用的cooperative协议,在sticky的基础上,优化rebalance过程,可以从RebalanceProtocol源码中看到这两个协议的解释:

ConsumerPartitionAssignor接口默认就指定了eager协议,如图:

CooperativeStickAssignor重写了这个协议,使用cooperative,如图:

还是上面的例子,假设C2下线了,触发了rebalance,使用sticky分配,结果就会是:

C0:P00,P10,P20,P20,P22
C1:P01,P11,P21,P21,

看起来和sticky并没有什么区别,毕竟它们都是sticky,但实际过程上有很大的差别,sticky会先放弃所有的分区,清理数据,然后再重新分配,整个过程较复杂耗时,而coopertive则比较轻量,首先会将原来的分区分配给原来的持有者,再rebalance重新分配P20,P21,P22分区。
关于eager、cooperative协议可以参考这篇文章:https://www.cnblogs.com/listenfwind/p/14146727.html

总结

这4种分区分配策略是可以配置的,客户端通过partition.assignment.strategy参数进行设置,默认是RangeAssignor。

欢迎关注我的github:https://github.com/jmilktea/jtea

热门相关:冉冉心动   闺范   修真界败类   万古至尊   上神来了