重平衡
1、rebalance概览
consumer group的rebalance本质上是一组协议，它规定了一个consumer group是如何达成一致来分配订阅topic的所有分区的。假设某个组下有20个consumer实例，该组订阅了一个有着l00个分区的topic。正常情况下，Kafka会为每个consumer平均分配5个分区。这个分配过程就被称为rebalance。当consumer成功地执行rebalance后，组订阅topic的每个分区只会分配给组内的一个consumer实例。
和旧版本consumer依托于ZooKeeper进行rebalance不同，新版本consumer使用了Kafka内置的一个全新的组协调协议(group coordination protocol)。对于每个组而言，Kafka的某个broker会被选举为组协调者(group coordinator)。coordinator负责对组的状态进行管理，它的主要职责就是当新成员到达时促成组内所有成员达成新的分区分配方案，即coordinator负责对组执行rebalance操作。
2、rebalance触发条件
- 组成员发生变更，比如新consumer加入组，或已有consumer主动离开组，再或是已有consumer崩溃时则触发rebalance。
- 组订阅opc数发生变更，比如使用基于正则表达式的订阅，当匹配正则表达式的新topic被创建时则会触发rebalance。
- 组订阅topic的分区数发生变更，比如使用命令行脚本增加了订阅topic的分区数。
真实应用场景中引发rebalance最常见的原因就是违背了第一个条件，特别是consumer崩溃的情况。这里的崩溃不一定就是指consumer进程“挂掉”或consumer进程所在的机器宕机。当consumer无法在指定的时间内完成消息的处理，那么coordinator就认为该consumer已经崩溃，从而引发新一轮rebalance。生产环境中用户一定要结合自身业务特点仔细调优consumer参数request.timeout.ms、max.poll.records和max.poll.interval.ms,以避免不必要的rebalance出现。
3、rebalance分区分配
在rebalance时group下所有的consumer都会协调在一起共同参与分区分配。Kafka新版本consumer默认提供了3种分配策略，分别是range策略、round-robin策略和sticky策略。
所谓的分配策略决定了订阅topic的每个分区会被分配给哪个consumer。
- range策略主要是基于范围的思想。它将单个topc的所有分区按照顺序排列，然后把这些分区划分成固定大小的分区段并依次分配给每个consumer；
- round-robin策略则会把所有topic的所有分区顺序摆开，然后轮询式地分配给各个consumer。
- sticky策略有效地避免了上述两种策略完全无视历史分配方案的缺陷，采用了“有黏性”的策略对所有consumer实例进行分配，可以规避极端情况下的数据倾斜并且在两次rebalance间最大限度地维持了之前的分配方案。
通常意义上认为，如果group下所有consumer实例的订阅是相同，那么使用round-robin会带来更公平的分配方案，否则使用range策略的效果更好。此外，sticky策略在0.11.0.0版本才被引入，故目前使用的用户并不多。新版本consumer默认的分配策略是range。用户根据consumer参数partition.assignment.strategy来进行设置。另外Kafka支持自定义的分配策略，用户可以创建自己的consumer分配器(assignor)。
针对rebalance过程中的分区分配，下面举一个简单的例子，加以说明。假设目前某个consumer group下有两个consumer:A和B。当第3个成员C加入时，满足了前面谈到的第一个触发条件，因此coordinator会执行rebalance,并根据range分配策略重新为A、B和C分配分区，如图所示。
由此可见，原先A和B分别处理3个分区的数据，rebalance之后A、B和C各自承担2个分区的消费，可以说这个分配方案非常公平，每个consumer上的负载是相同的。
4、rebalance generation
某个consumer group可以执行任意次rebalance。为了更好地隔离每次rebalance上的数据，新版本consumer设计了rebalance generation用于标识某次rebalance。generation这个词类似于JVM分代垃圾收集器中“分代”（严格来说，JVM GC使用的是generational)的概念。表示rebalance之后的一届成员，在consumer中它是一个整数，通常从0开始。
Kafka引入consumer generation主要是为了保护consumer group的，特别是防止无效offset提交。比如上一届的consumer成员由于某些原因延迟提交了offset,但rebalance之后该group产生了新一届的group成员，而这次延迟的offset提交携带的是旧的generation信息，因此这次提交会
被consumer group拒绝。很多Kafka用户在使用consumer时经常碰到的ILLEGAL GENERATION异常就是这个原
因导致的。事实上，每个group进行rebalance之后，generation号都会加l,表示group进入了一个新的版本。如图所示，Generation1时group有3个成员，随后成员2退出组，coordinator触发rebalance,consumer group进入到Generation2时代，之后成员4加入，再次触发rebalance,group进入到Generation3时代。
5、rebalance协议
前面提到过rebalance本质上是一组协议。group与coordinator共同使用这组协议完成group的rebalance。最新版本Kafka中提供了下面5个协议来处理rebalance相关事宜。
JoinGroup请求：consumer请求加入组SyncGroup请求：group leader把分配方案同步更新到组内所有成员中Heartbeat请求：consumer定期向coordinator汇报心跳表明自己依然存货LeaveGroup请求：consumer主动通知coordinator该consumer即将离组DescribeGroup请求：查看组的所有信息，包括成员信息、协议信息、分配方案以及订阅信息等。该请求类型主要供管理员使用。coordinator不使用该请求执行rebalance。
在rebalance过程中，coordinator主要处理consumer发过来的JoinGroup和SyncGroup请求。当consumer主动离组时会发送LeaveGroup请求给coordinator。
在成功rebalance之后，组内所有consumer都需要定期地向coordinator发送Heartbeat请求。而每个consumer也是根据Heartbeat请求的响应中是否包含REBALANCE IN PROGRESS来判断当前group是否开启了新一轮rebalance。
6、rebalance流程
consumer group在执行rebalance之前必须首先确定coordinator所在的broker,并创建与该broker相互通信的Socket连接。确定coordinator的算法与确定offset被提交到__consumer_offsets目标分区的算法是相同的。算法如下:
- 计算
Math.abs(groupID.hashCode) % offsets.topic.num.partitions参数值(默认是50)，假设是10 - 寻找
__consumer_offsets分区10的leader副本所在的broker，该即为这个group的coordinator。
成功连接coordinator之后便可以执行rebalance操作。目前rebalance主要分为两步：加入组和同步更新分配方案。
加入组：这一步中组内所有consumer(即group.id相同的所有consumer实例)向coordinator发送JoinGroup请求。当收集全JoinGroup请求后，coordinator从中选择一个consumer担任group的leader,并把所有成员信息以及它们的订阅信息发送给leader。特别需要注意的是，group的leader和coordinator不是一个概念。leader是某个
consumer实例，coordinator通常是Kafka集群中的一个broker。另外leader而非coordinator负责为整个group的所有成员制定分配方案。同步更新分配方案：这一步中leader开始制定分配方案，即根据前面提到的分配策略决定每个consumer都负责哪些topic的哪些分区。一旦分配完成，leader会把这个分配方案封装进SyncGroup请求并发送给coordinator。比较有意思的是，组内所有成员都会发送SyncGroup请求，不过只有leader发送的SyncGroup请求中包含了分配方案。
coordinator接收到分配方案后把属于每个consumer的方案单独抽取出来作为SyncGroup请求的response返还给各自的consumer。
consumer group分配方案是在consumer端执行的。Kafka将这个权力下放给客户端主要是因为这样做可以有更好的灵活性。比如在这种机制下用户可以自行实现类似于Hadoop那样的机架感知(rack-aware)分配方案。同一个机架上的分区数据被分配给相同机架上的consumer,减少网络传输的开销。而且，即使以后分区策略发生了变更，也只需要重启consumer应用即可，不必重启Kafka服务器。
Java 面试宝典是大明哥全力打造的 Java 精品面试题，它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题，而是一套完整的 Java 知识体系，一套你 Java 知识点的扫盲贴。
它的内容包括：
- 大厂真题：Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
- 原创内容：Java 面试宝典内容全部都是大明哥原创，内容全面且通俗易懂，回答部分可以直接作为面试回答内容。
- 持续更新：一次购买，永久有效。大明哥会持续更新 3+ 年，累计更新 1000+，宝典会不断迭代更新，保证最新、最全面。
- 覆盖全面：本宝典累计更新 1000+，从 Java 入门到 Java 架构的高频面试题，实现 360° 全覆盖。
- 不止面试：内容包含面试题解析、内容详解、知识扩展，它不仅仅只是一份面试题，更是一套完整的 Java 知识体系。
- 宝典详情：https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
- 宝典总览：https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
- 宝典进展：https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw
目前 Java 面试宝典累计更新 400+ 道，总字数 42w+。大明哥还在持续更新中，下图是大明哥在 2024-12 月份的更新情况：
想了解详情的小伙伴，扫描下面二维码加大明哥微信【daming091】咨询
同时，大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ，回复【面试题】 即可免费领取。
