关于后端:Kafka分区分配策略

在上一篇文章中，咱们为大家具体介绍可 Kafka 的原理与外围概念，包含控制器选举及复原、分区 leader 的选举等，详情可见 Kafka 核心技术概念与架构原理，本次咱们来为大家具体解说 Kafka 等分区调配策略，心愿能对大家有所帮忙

Kafka 提供了消费者客户端参数 partition.assignment.strategy ⽤来设置消费者与订阅主题之间的分辨别 配策略。默认状况下此参数的值为：org.apache.kafka.clients.consumer.RangeAssignor，即采⽤ RangeAssignor 调配策略。除此之外，Kafka 中还提供了另外两种调配策略：RoundRobinAssignor 和 StickyAssignor。消费者客户端参数 partition.asssignment.strategy 能够配置多个调配策略，彼此之间 以逗号分隔。

RangeAssignor 调配策略

RangeAssignor 策略的原理是依照消费者总数和分区总数进⾏整除运算来取得⼀个跨度，而后将分区按 照跨度进⾏平均分配，以保障分区尽可能平均地调配给所有的消费者。对于每⼀个 topic，

RangeAssignor 策略会将生产组内所有订阅这个 topic 的消费者依照名称的字典序排序，而后为每个生产 者划分固定的分区范畴，如果不够平均分配，那么字典序靠前的消费者会被多调配⼀个分区。

假如 n = 分区数 / 消费者数量，m= 分区数 % 消费者数量，那么前 m 个消费者每个调配 n + 1 个分区，后⾯的（消费者数量 -m）个消费者每个调配 n 个分区。

如果生产组内有 2 个消费者 C0 和 C1，且都订阅了主题 t0 和 t1，并且每个主题都有 4 个分区，那么所订阅的所 有分区能够标识为：t0p0、t0p1、t0p2、t0p3、t1p0、t1p1、t1p2、t1p3。最终的调配后果为：

 消费者 C0：t0p0、t0p1、t1p0、t1p1 
消费者 C1：t0p2、t0p3、t1p2、t1p3

这样调配的很平均，那么此种调配策略可能⼀直放弃这种良好的个性呢？咱们再来看下另外⼀种状况。假如上⾯例⼦中 2 个主题都只有 3 个分区，那么所订阅的所有分区能够标识为：t0p0、t0p1、t0p2、t1p0、t1p1、t1p2。最终的调配后果为：
消费者 C0：t0p0、t0p1、t1p0、t1p1
消费者 C1：t0p2、t1p2

能够显著的看到这样的调配并不平均，如果将相似的情景扩⼤，有可能会呈现局部消费者过载的状况

RoundRobinAssignor 调配策略

RoundRobinAssignor 策略的原理是将生产组内所有消费者以及消费者所订阅的所有 topic 的 partition 按 照字典序排序，而后通过轮询⽅式一一将分区以此调配给每个消费者。RoundRobinAssignor 策略对应 的 partition.assignment.strategy 参数值为：org.apache.kafka.clients.consumer.RoundRobinAssignor。

如果同⼀个生产组内所有的消费者的订阅信息都是雷同的，那么 RoundRobinAssignor 策略的分区调配 会是平均的。假如生产组中有 2 个消费者 C0 和 C1，都订阅了主题 t0 和 t1，并且每个主题都有 3 个分区，那么所订阅的所 有分区能够标识为：t0p0、t0p1、t0p2、t1p0、t1p1、t1p2。最终的调配后果为：

 消费者 C0：t0p0、t0p2、t1p1 
消费者 C1：t0p1、t1p0、t1p2

如果同⼀个生产组内的消费者所订阅的信息是不雷同的，那么在执⾏分区调配的时候就不是齐全的轮询调配，有可能会导致分区调配的不平均。如果某个消费者没有订阅生产组内的某个 topic，那么在调配分区的时候此消费者将调配不到这个 topic 的任何分区。

假如生产组内有 3 个消费者 C0、C1 和 C2，它们共订阅了 3 个主题：t0、t1、t2，这 3 个主题别离有 1、2、3 个分区，即整个生产组订阅了 t0p0、t1p0、t1p1、t2p0、t2p1、t2p2 这 6 个分区。具体⽽⾔，消费者 C0 订阅的是主题 t0，消费者 C1 订阅的是主题 t0 和 t1，消费者 C2 订阅的是主题 t0、t1 和 t2，那么最终的调配后果为：

 消费者 C0：t0p0 
消费者 C1：t1p0 
消费者 C2：t1p1、t2p0、t2p1、t2p2

StickyAssignor 调配策略

Kafka 从 0.11.x 版本开始引⼊这种调配策略，它次要有两个⽬的：

• 分区的调配要尽可能的平均；
• 分区的调配尽可能的与上次调配的放弃雷同。

当两者发⽣抵触时，第⼀个⽬标优先于第⼆个⽬标。鉴于这两个⽬标，StickyAssignor 策略的具体 实现要⽐ RangeAssignor 和 RoundRobinAssignor 这两种调配策略要简单很多。

假如生产组内有 3 个消费者：C0、C1 和 C2，它们都订阅了 4 个主题：t0、t1、t2、t3，并且每个主题有 2 个分区，也就是说整个生产组订阅了 t0p0、t0p1、t1p0、t1p1、t2p0、t2p1、t3p0、t3p1 这 8 个分区。最终的调配后果如下

 消费者 C0：t0p0、t1p1、t3p0 
消费者 C1：t0p1、t2p0、t3p1 
消费者 C2：t1p0、t2p1

这样初看上去仿佛与采⽤ RoundRobinAssignor 策略所调配的后果雷同，但事实是否真的如此呢？再假 设此时消费者 C1 脱离了生产组，那么生产组就会执⾏再均衡操作，进⽽生产分区会重新分配。如果采⽤ RoundRobinAssignor 策略，那么此时的调配后果如下：

 消费者 C0：t0p0、t1p0、t2p0、t3p0 
消费者 C2：t0p1、t1p1、t2p1、t3p1

如调配后果所示，RoundRobinAssignor 策略会依照消费者 C0 和 C2 进⾏从新轮询调配。⽽如果此时使⽤ 的是 StickyAssignor 策略，那么调配后果为：

 消费者 C0：t0p0、t1p1、t3p0、t2p0 
消费者 C2：t1p0、t2p1、t0p1、t3p1

能够看到调配后果中保留了上⼀次调配中对于消费者 C0 和 C2 的所有调配后果，并将原来消费者 C1 的“负 担”调配给了残余的两个消费者 C0 和 C2，最终 C0 和 C2 的调配还放弃了平衡。

如果发⽣分区重调配，那么对于同⼀个分区⽽⾔有可能之前的消费者和新指派的消费者不是同⼀个，对 于之前消费者进⾏到⼀半的解决还要在新指派的消费者中再次复现⼀遍，这显然很节约系统资源。StickyAssignor 策略如同其名称中的“sticky”⼀样，让调配策略具备⼀定的“粘性”，尽可能地让前后两次分 配雷同，进⽽缩小系统资源的损耗以及其它异常情况的发⽣。

例如生产组内有 3 个消费者：C0、C1 和 C2，集群中有 3 个主题：t0、t1 和 t2，这 3 个主题别离有 1、2、3 个分区，也就是说集群中有 t0p0、t1p0、t1p1、t2p0、t2p1、t2p2 这 6 个分区。消费者 C0 订阅了主题 t0，消费者 C1 订阅了主题 t0 和 t1，消费者 C2 订阅了主题 t0、t1 和 t2。

如果此时采⽤ RoundRobinAssignor 策略，那么最终的调配后果如下所示：

 消费者 C0：t0p0 
消费者 C1：t1p0 
消费者 C2：t1p1、t2p0、t2p1、t2p2

如果此时采⽤的是 StickyAssignor 策略，那么最终的调配后果为：

 消费者 C0：t0p0 
消费者 C1：t1p0、t1p1 
消费者 C2：t2p0、t2p1、t2p2

这是⼀个最优解（消费者 C0 没有订阅主题 t1 和 t2，所以不能调配主题 t1 和 t2 中的任何分区给 它，对于消费者 C1 也可同理推断）。如果此时消费者 C0 脱离了生产组，那么 RoundRobinAssignor 策略的调配后果为：

 消费者 C1：t0p0、t1p1 
消费者 C2：t1p0、t2p0、t2p1、t2p2

RoundRobinAssignor 策略保留了消费者 C1 和 C2 中原有的 3 个分区的调配：t2p0、t2p1 和 t2p2（针对后果集 1）。⽽如果采⽤的是 StickyAssignor 策略，那么调配后果为：

 消费者 C1：t1p0、t1p1、t0p0 
消费者 C2：t2p0、t2p1、t2p2

StickyAssignor 策略保留了消费者 C1 和 C2 中原有的 5 个分区的调配：t1p0、t1p1、t2p0、t2p1、t2p2。

Kafka 分区调配策略咱们就说到这里，下一篇文章，咱们将给大家带来 Kafka 调优指南。

更多福利

云智慧已开源集轻量级、聚合型、智能运维为一体的综合运维治理平台 OMP（Operation Management Platform），具备 纳管、部署、监控、巡检、自愈、备份、复原 等性能，可为用户提供便捷的运维能力和业务管理，在进步运维人员等工作效率的同时，极大晋升了业务的连续性和安全性。点击下方地址链接，欢送大家给 OMP 点赞送 star，理解更多相干内容～

GitHub 地址：https://github.com/CloudWise-…
Gitee 地址：https://gitee.com/CloudWise/OMP

微信扫描辨认下方二维码，备注【OMP】退出 AIOps 社区运维治理平台 OMP 开发者交换群，与 OMP 我的项目 PMC 当面交换，和更多行业大佬一起交流学习～