作者 | 草捏子
来源 | 草捏子（ID:chaycao）
头图 | CSDN 下载自东方IC
在《Kafka消费者的使用和原理》中已经提到过“再均衡”的概念，我们先回顾下，一个主题可以有多个分区，而订阅该主题的消费组中可以有多个消费者。每一个分区只能被消费组中的一个消费者消费，可认为每个分区的消费权只属于消费组中的一个消费者。但是世界是变化的，例如消费者会宕机，还有新的消费者会加入，而为了应对这些变化，让分区所属权的分配合理，这都需要对分区所属权进行调整，也就是所谓的“再均衡”。本文将对再均衡的相关知识进行详细叙述。
触发时机
首先，我们需要了解什么情况下会触发再均衡，在前文已经提到了消费者数量的变化，是需要再均衡的。在使用 Kafka 时，除了消费者数量可能会变化，分区数量也同样可能变化，我们可以人为的对分区数量进行修改，但是 Kafka 只允许增加分区，所以我们只能把分区数量调大，不能调小，否则会收到InvalidPartitionException异常。关于为什么不能减少分区，可参考下面的回答：
按 Kafka 现有的代码逻辑，此功能是完全可以实现的，不过也会使得代码的复杂度急剧增大。实现此功能需要考虑的因素很多，比如删除掉的分区中的消息该作何处理？如果随着分区一起消失则消息的可靠性得不到保障；如果需要保留则又需要考虑如何保留。直接存储到现有分区的尾部，消息的时间戳就不会递增，如此对于 Spark、Flink 这类需要消息时间戳（事件时间）的组件将会受到影响；如果分散插入到现有的分区中，那么在消息量很大的时候，内部的数据复制会占用很大的资源，而且在复制期间，此主题的可用性又如何得到保障？与此同时，顺序性问题、事务性问题、以及分区和副本的状态机切换问题都是不得不面对的。反观这个功能的收益点却是很低，如果真的需要实现此类的功能，完全可以重新创建一个分区数较小的主题，然后将现有主题中的消息按照既定的逻辑复制过去即可。
简单来说，就是做这个功能需要考虑很多因素，这样会把代码弄的很复杂，而收益却很低，而且存在替代方案来实现该效果，创建一个分区数小的主题，再把当前主题迁移过去。
除了消费者、分区数量的变化，还有一种情况，也需要进行再均衡。当消费者订阅主题时使用的是正则表达式，例如 “test.*”，表示订阅所有以 test 开头的主题，当有新的以 test 开头的主题被创建时，则需要通过再均衡将该主题的分区分配给消费者。
再均衡的三种触发时机，我们已经清楚了，下面我们看下再均衡是如何实现的。
协调者
再均衡，将分区所属权分配给消费者。因此需要和所有消费者通信，这就需要引进一个协调者的概念，由协调者为消费组服务，为消费者们做好协调工作。在 Kafka 中，每一台 Broker 上都有一个协调者组件，负责组成员管理、再均衡和提交位移管理等工作。如果有 N 台 Broker，那就有 N 个协调者组件，而一个消费组只需一个协调者进行服务，那该**由哪个 Broker 为其服务？**确定 Broker 需要两步：
1、计算分区号
partition = Math.abs(groupID.hashCode() % offsetsTopicPartitionCount)
根据groupID的哈希值，取余offsetsTopicPartitionCount（内部主题__consumer_offsets的分区数，默认50）的绝对值，其意思就是把消费组哈希散列到内部主题__consumer_offsets的一个分区上。确定协调者为什么要和内部主题扯上关系。这就跟协调者的作用有关了。协调者不仅是负责组成员管理和再均衡，在协调者中还需要负责处理消费者的偏移量提交，而偏移量提交则正是提交到__consumer_offsets的一个分区上。所以这里需要取余offsetsTopicPartitionCount来确定偏移量提交的分区。
2、找出分区Leader副本所在的Broker
确定了分区就简单了，分区Leader副本所在的Broker上的协调者，就是我们要找的。
这个算法通常用于帮助定位问题。当一个消费组出现问题时，我们可以先确定协调者的Broker，然后查看Broker端的日志来定位问题。
交互方式
现在我们再重新看下，触发再均衡的时机，前面说到有三种情况触发再均衡，分别是消费者数量的增加或减少、分区数的增加和新创建主题，其中消费者数量增加、分区数增加和新创建主题，这都是必须是人为操作，算是计划内的再均衡。而消费者数量减少则除了是人为操作，也可能因为其他原因导致，属于计划之外的再均衡，这是我们需要关心的，毕竟再均衡的开销还是很大的，所有消费者都会停止工作，所以我们应尽量避免不必要的再均衡。下面我们看下影响消费者数量减少的参数有哪些：
这一小节主要讲了协调者如何通知消费者开始再均衡，以及如何设置参数避免不必要的再均衡，下面我们看下再均衡的流程是怎么样的。
流程
1、当消费者收到协调者的再均衡开始通知时，需要立即提交偏移量；
2、消费者在收到提交偏移量成功的响应后，再发送JoinGroup请求，重新申请加入组，请求中会含有订阅的主题信息；
4、Leader 消费者收到J oinGroup 响应后，根据消费者的订阅信息制定分配方案，把方案放在SyncGroup 请求中，发送给协调者。普通消费者在收到响应后，则直接发送 SyncGroup 请求，等待 Leader 的分配方案；
5、协调者收到分配方案后，再通过SyncGroup 响应把分配方案发给所有消费组。
6、当所有消费者收到分配方案后，就意味着再均衡的结束，可以正常开始消费工作了。
参考：
1、《深入理解Kafka》
2、《Kafka核心技术与实战》
3、Kafka之Group 状态变化分析及Rebalance过程: https://matt33.com/2017/01/16/kafka-group/#Consumer-初始化时-group-状态变化
