17 | 消费者组重平衡能避免吗？

Jul 11, 2019

17 | 消费者组重平衡能避免吗？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

17 | 消费者组重平衡能避免吗？

2019-07-11 胡夕来自北京

《Kafka核心技术与实战》

课程介绍



讲述：胡夕

时长12:57大小11.86M



你好，我是胡夕。今天我要和你分享的内容是：消费者组重平衡能避免吗?
其实在专栏第 15 期中，我们讲过重平衡，也就是 Rebalance，现在先来回顾一下这个概念的原理和用途。Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。
你可能会对这里提到的“协调者”有些陌生，我来简单介绍下。所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。
具体来讲，Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。
所有 Broker 在启动时，都会创建和开启相应的 Coordinator 组件。也就是说，所有 Broker 都有各自的 Coordinator 组件。那么，Consumer Group 如何确定为它服务的 Coordinator 在哪台 Broker 上呢？答案就在我们之前说过的 Kafka 内部位移主题 __consumer_offsets 身上。
目前，Kafka 为某个 Consumer Group 确定 Coordinator 所在的 Broker 的算法有 2 个步骤。
第 1 步：确定由位移主题的哪个分区来保存该 Group 数据：partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。
第 2 步：找出该分区 Leader 副本所在的 Broker，该 Broker 即为对应的 Coordinator。
简单解释一下上面的算法。首先，Kafka 会计算该 Group 的 group.id 参数的哈希值。比如你有个 Group 的 group.id 设置成了“test-group”，那么它的 hashCode 值就应该是 627841412。其次，Kafka 会计算 __consumer_offsets 的分区数，通常是 50 个分区，之后将刚才那个哈希值对分区数进行取模加求绝对值计算，即 abs(627841412 % 50) = 12。此时，我们就知道了位移主题的分区 12 负责保存这个 Group 的数据。有了分区号，算法的第 2 步就变得很简单了，我们只需要找出位移主题分区 12 的 Leader 副本在哪个 Broker 上就可以了。这个 Broker，就是我们要找的 Coordinator。
在实际使用过程中，Consumer 应用程序，特别是 Java Consumer API，能够自动发现并连接正确的 Coordinator，我们不用操心这个问题。知晓这个算法的最大意义在于，它能够帮助我们解决定位问题。当 Consumer Group 出现问题，需要快速排查 Broker 端日志时，我们能够根据这个算法准确定位 Coordinator 对应的 Broker，不必一台 Broker 一台 Broker 地盲查。
好了，我们说回 Rebalance。既然我们今天要讨论的是如何避免 Rebalance，那就说明 Rebalance 这个东西不好，或者说至少有一些弊端需要我们去规避。那么，Rebalance 的弊端是什么呢？总结起来有以下 3 点：
Rebalance 影响 Consumer 端 TPS。这个之前也反复提到了，这里就不再具体讲了。总之就是，在 Rebalance 期间，Consumer 会停下手头的事情，什么也干不了。
Rebalance 很慢。如果你的 Group 下成员很多，就一定会有这样的痛点。还记得我曾经举过的那个国外用户的例子吧？他的 Group 下有几百个 Consumer 实例，Rebalance 一次要几个小时。在那种场景下，Consumer Group 的 Rebalance 已经完全失控了。
Rebalance 效率不高。当前 Kafka 的设计机制决定了每次 Rebalance 时，Group 下的所有成员都要参与进来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。
关于第 3 点，我们来举个简单的例子。比如一个 Group 下有 10 个成员，每个成员平均消费 5 个分区。假设现在有一个成员退出了，此时就需要开启新一轮的 Rebalance，把这个成员之前负责的 5 个分区“转移”给其他成员。显然，比较好的做法是维持当前 9 个成员消费分区的方案不变，然后将 5 个分区随机分配给这 9 个成员，这样能最大限度地减少 Rebalance 对剩余 Consumer 成员的冲击。
遗憾的是，目前 Kafka 并不是这样设计的。在默认情况下，每次 Rebalance 时，之前的分配方案都不会被保留。就拿刚刚这个例子来说，当 Rebalance 开始时，Group 会打散这 50 个分区（10 个成员 * 5 个分区），由当前存活的 9 个成员重新分配它们。显然这不是效率很高的做法。基于这个原因，社区于 0.11.0.0 版本推出了 StickyAssignor，即有粘性的分区分配策略。所谓的有粘性，是指每次 Rebalance 时，该策略会尽可能地保留之前的分配方案，尽量实现分区分配的最小变动。不过有些遗憾的是，这个策略目前还有一些 bug，而且需要升级到 0.11.0.0 才能使用，因此在实际生产环境中用得还不是很多。
总而言之，Rebalance 有以上这三个方面的弊端。你可能会问，这些问题有解吗？特别是针对 Rebalance 慢和影响 TPS 这两个弊端，社区有解决办法吗？针对这两点，我可以很负责任地告诉你：“无解！”特别是 Rebalance 慢这个问题，Kafka 社区对此无能为力。“本事大不如不摊上”，既然我们没办法解决 Rebalance 过程中的各种问题，干脆就避免 Rebalance 吧，特别是那些不必要的 Rebalance。
就我个人经验而言，在真实的业务场景中，很多 Rebalance 都是计划外的或者说是不必要的。我们应用的 TPS 大多是被这类 Rebalance 拖慢的，因此避免这类 Rebalance 就显得很有必要了。下面我们就来说说如何避免 Rebalance。
要避免 Rebalance，还是要从 Rebalance 发生的时机入手。我们在前面说过，Rebalance 发生的时机有三个：
组成员数量发生变化
订阅主题数量发生变化
订阅主题的分区数发生变化
后面两个通常都是运维的主动操作，所以它们引发的 Rebalance 大都是不可避免的。接下来，我们主要说说因为组成员数量变化而引发的 Rebalance 该如何避免。
如果 Consumer Group 下的 Consumer 实例数量发生变化，就一定会引发 Rebalance。这是 Rebalance 发生的最常见的原因。我碰到的 99% 的 Rebalance，都是这个原因导致的。
Consumer 实例增加的情况很好理解，当我们启动一个配置有相同 group.id 值的 Consumer 程序时，实际上就向这个 Group 添加了一个新的 Consumer 实例。此时，Coordinator 会接纳这个新实例，将其加入到组中，并重新分配分区。通常来说，增加 Consumer 实例的操作都是计划内的，可能是出于增加 TPS 或提高伸缩性的需要。总之，它不属于我们要规避的那类“不必要 Rebalance”。
我们更在意的是 Group 下实例数减少这件事。如果你就是要停掉某些 Consumer 实例，那自不必说，关键是在某些情况下，Consumer 实例会被 Coordinator 错误地认为“已停止”从而被“踢出”Group。如果是这个原因导致的 Rebalance，我们就不能不管了。
Coordinator 会在什么情况下认为某个 Consumer 实例已挂从而要退组呢？这个绝对是需要好好讨论的话题，我们来详细说说。
当 Consumer Group 完成 Rebalance 之后，每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。如果某个 Consumer 实例不能及时地发送这些心跳请求，Coordinator 就会认为该 Consumer 已经“死”了，从而将其从 Group 中移除，然后开启新一轮 Rebalance。Consumer 端有个参数，叫 session.timeout.ms，就是被用来表征此事的。该参数的默认值是 10 秒，即如果 Coordinator 在 10 秒之内没有收到 Group 下某 Consumer 实例的心跳，它就会认为这个 Consumer 实例已经挂了。可以这么说，session.timeout.ms 决定了 Consumer 存活性的时间间隔。
除了这个参数，Consumer 还提供了一个允许你控制发送心跳请求频率的参数，就是 heartbeat.interval.ms。这个值设置得越小，Consumer 实例发送心跳请求的频率就越高。频繁地发送心跳请求会额外消耗带宽资源，但好处是能够更加快速地知晓当前是否开启 Rebalance，因为，目前 Coordinator 通知各个 Consumer 实例开启 Rebalance 的方法，就是将 REBALANCE_NEEDED 标志封装进心跳请求的响应体中。
除了以上两个参数，Consumer 端还有一个参数，用于控制 Consumer 实际消费能力对 Rebalance 的影响，即 max.poll.interval.ms 参数。它限定了 Consumer 端应用程序两次调用 poll 方法的最大时间间隔。它的默认值是 5 分钟，表示你的 Consumer 程序如果在 5 分钟之内无法消费完 poll 方法返回的消息，那么 Consumer 会主动发起“离开组”的请求，Coordinator 也会开启新一轮 Rebalance。
搞清楚了这些参数的含义，接下来我们来明确一下到底哪些 Rebalance 是“不必要的”。
第一类非必要 Rebalance 是因为未能及时发送心跳，导致 Consumer 被“踢出”Group 而引发的。因此，你需要仔细地设置 session.timeout.ms 和 heartbeat.interval.ms 的值。我在这里给出一些推荐数值，你可以“无脑”地应用在你的生产环境中。
设置 session.timeout.ms = 6s。
设置 heartbeat.interval.ms = 2s。
要保证 Consumer 实例在被判定为“dead”之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。
将 session.timeout.ms 设置成 6s 主要是为了让 Coordinator 能够更快地定位已经挂掉的 Consumer。毕竟，我们还是希望能尽快揪出那些“尸位素餐”的 Consumer，早日把它们踢出 Group。希望这份配置能够较好地帮助你规避第一类“不必要”的 Rebalance。
第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。我之前有一个客户，在他们的场景中，Consumer 消费数据时需要将消息处理之后写入到 MongoDB。显然，这是一个很重的消费逻辑。MongoDB 的一丁点不稳定都会导致 Consumer 程序消费时长的增加。此时，max.poll.interval.ms 参数值的设置显得尤为关键。如果要避免非预期的 Rebalance，你最好将该参数值设置得大一点，比你的下游最大处理时间稍长一点。就拿 MongoDB 这个例子来说，如果写 MongoDB 的最长时间是 7 分钟，那么你可以将该参数设置为 8 分钟左右。
总之，你要为你的业务处理逻辑留下充足的时间。这样，Consumer 就不会因为处理这些消息的时间太长而引发 Rebalance 了。
如果你按照上面的推荐数值恰当地设置了这几个参数，却发现还是出现了 Rebalance，那么我建议你去排查一下 Consumer 端的 GC 表现，比如是否出现了频繁的 Full GC 导致的长时间停顿，从而引发了 Rebalance。为什么特意说 GC？那是因为在实际场景中，我见过太多因为 GC 设置不合理导致程序频发 Full GC 而引发的非预期 Rebalance 了。
小结总而言之，我们一定要避免因为各种参数或逻辑不合理而导致的组成员意外离组或退出的情形，与之相关的主要参数有：
session.timeout.ms
heartbeat.interval.ms
max.poll.interval.ms
GC 参数
按照我们今天所说的内容，恰当地设置这些参数，你一定能够大幅度地降低生产环境中的 Rebalance 数量，从而整体提升 Consumer 端 TPS。
开放讨论说说在你的业务场景中，Rebalance 发生的频率、原因，以及你是怎么应对的，我们一起讨论下是否有更好的解决方案。
欢迎写下你的思考和答案，我们一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 28

提建议

16 | 揭开神秘的“位移主题”面纱

18 | Kafka中位移提交那些事儿

 写留言

精选留言(119)

Icedmaze
2019-07-11
在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待Rebalance的完成。这里想问的是，如果我有一个长耗时的业务逻辑需要处理，并且offset还未提交，这时候系统发生了Rebalance的话，是等待所有消费端当前消息都处理完成，再进行停止消费，并进行重新分配分区，还是说强制停止消费。如果强制停止消费的话，那么那些已经处理完成一半的数据并offset未提交的数据，势必会导致Rebalance后重新进行消费，导致数据产生重复消费。
展开
作者回复: 你所谓的处理是指业务上的处理逻辑。对于Kafka而言，从poll方法返回消息的那一刻开始这条消息已经算是“消费”完成了。
共 9 条评论
55
Liam
2019-07-11
问个小白问题，如何排查得知broker rebalance 过多，通过broker日志吗？什么日志呢
作者回复: 去找Coordinator所在的broker日志，如果经常发生rebalance，会有类似于"(Re)join group" 之类的日志
共 7 条评论
45
What for
2020-02-03
老师您好！请问如果使用 Standalone Consumer，是不是也不会发生 rebalance 了？感觉专栏里对 Standalone Consumer 就是提了两句，没有太多的介绍，相较于订阅模式它们有什么特点嘛？
作者回复: 不会。standalone consumer就没有rebalance一说了。它的特点主要是灵活和。虽然社区一直在改进rebalance的性能，但大数据量下consumer group机制依然有很多弊病（比如rebalance太慢等），所以很多大数据框架(Spark /Flink)的kafka connector并不使用group机制，而是使用standalone consumer
共 3 条评论
33
Icedmaze
2019-07-12
那可否认为，之前poll的数据还是会被继续进行业务逻辑处理，若在rebalance停止消费期间offset并未进行提交，可能会造成该partition里面的同一批消息被重新分配给其他消费实例，造成重复消费问题。
作者回复: 是的
31
李奕慧
2019-07-11
“每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。”这个是后台自动触发的还是每次主动poll消息触发的啊？
作者回复: 0.10.1之前是在调用poll方法时发送的，0.10.1之后consumer使用单独的心跳线程来发送
共 3 条评论
24
诗泽
2019-07-11
如果同一个group 的不同consumer 设置的session.timeout.ms 的不一样怎么办？协调者以最后一个consumer 为准吗？
作者回复: 取最大的
共 2 条评论
19
墨渊战神01
2019-07-11
Consumer 消费时间过长为啥会导致rebalance？是不能及时发心跳导致coordinator认为该consumer挂了吗？
作者回复: consumer主动关闭会主动向Coordinator发送LeaveGroup请求，从而让Coordinator第一时间开启rebalance
共 2 条评论
18
千屿
2019-07-11
我遇到一个很奇怪的问题，我消费者单线程使用订阅模式消费主题，主题下有三个分区，但是每次启动消费者，只能消费到一个分区的数据，在启动的日志里已经显示了该group已经分配到了三个分区，可是只会poll一个分区的数据。当我用多线程启动三个消费者实例是正常的，启动两个实例只能消费到两个分区数据，求各位大神指点下，谢谢了!
作者回复: 是否是因为某个分区的数据量太多，造成了其他分区的“假饿死”？
共 4 条评论
14
丘壑
2019-07-11
根据公式计算记过：partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)只可能是一个分区值，该分区值对于的leader副本的broker也只可能是集群中的一台，那么一个group进行位移提交的时候，只能是与集群中的一台broker进行交互了？这样是不是就会有性能瓶颈啊，没有充分利用集群中的broker啊，
作者回复: 不同的group id会被哈希到不同的分区上，从而不同的broker能充当不同group的Coordinator
13
不能扮演天使
2019-09-06
老师问个问题，max.poll.interval.ms是拉取的时间间隔，如果过了这个时间没有拉取则会发生重平衡，但是什么情况consumer会不拉取呢？上面mongodb的例子那是业务逻辑处理重，但是对于kafka来说poll()之后就已经算是消费完了，为啥这个参数的设置还要依赖消费的后序业务处理？
作者回复: 因为poll和业务处理通常是在一个线程中，因此业务处理速度会影响poll调用频率
共 6 条评论
12
注定非凡
2019-11-04
1 什么是重平衡 A ：让一个Consumer Group下所有的consumer实例就如何消费订阅主题的所有分区达成共识的过程。 B ：在重平衡过程中，所有Consumer实例共同参与，在协调者组件的帮助下，完成订阅分区的分配。 C ：整个过程中，所有实例都不能消费任何消息，因此对Consumer的TPS影响很大 2 为什要避免重平衡 A ：Rebalance影响Consumer端的TPS，因为重平衡过程中消费者不能消费消息 B ：Rebalance很慢，如果有数百个消费者实例，整个过程耗时可能达到几个小时 C ：Rebalance效率低，这个过程是全员参与，通常不考虑局部性原理，但局部性原理对系统性能提升特别重要。 D ：真实的业务场景中，很多Rebalance都是计划外或是不必要的。 3 何时会触发重平衡 A ：组成员数量发生变化 B ：订阅主题数量发生变化 C ：订阅主题分区数发生变化。 4, 要避免哪些重平衡最常见的是消费者数发生变化触发的重平衡，其他的重平衡是不可避免的，但消费者数量变化是可避免的 A ：Consumer实例增加当启动一个配置相同的group.id值的consumer程序时，就是向这个组中增加一个消费者实例，这中秋情况一般是我们为了提升消费者端的TPS，是计划内的，所以也不用避免。 B ：Consumer实例减少（1）按计划的减少消费者实例，同样不用避免（2）计划外的减少触发的重平衡才是我们要关注的。 5 如何避免重平衡在某些情况下，Consumer实例会被Coordinateor错误地认为“已停止”，进而被踢出Group。这种情况导致的重平衡是需要避免的。 A ：Consumer实例不能及时的发送心跳请求当消费者组完成重平衡后，每个Consumer实例都会定期地向Coordinator发送心跳请求，如这个心跳请求没有被及时发送，Coordinator就会认为该Consumer已经掉线，将其从组中移除，并开启新一轮重平衡。解决：Consumer端设置：》Session.timeout.ms：默认为10秒，表示10秒内Coordinator没有收到Group下某个Consumer实例的心跳，就认为实例下线。这个可以适当的增大》heartbeat.interval.ms：控制发送心跳请求的频率，频繁的发送心跳请求会额外消耗带库资源。》max.poll.interval.ms：限定Consumer端应用程序两次调用poll方法的最大时间间隔。默认值是5分钟，表示如果Consumer程序在5分钟之内无法消费完poll方法返回的消息，那么consumer会主动的发起“离开组”的请求，建议：session.timeout.ms=6s Heartbeat.interval.ms=2s 保证Consumer实例在判定为“dead”之前，能够发送至少3轮的心跳请求，即session.timeout.ms >=3 * heartbeat.interval.ms。 B ：Consumer消费时间过长消费者端处理了一个很重的消费逻辑，耗时较长，导致Consumer端应用程序两次调用poll方法的时间超出设置的最大时间间隔。解决： 1，将max.poll.interval.ms参数设置较大一些 2，优化消费者端业务逻辑，压缩消费耗时 C ：GC影响 Consumer端的GC表现也会导致频繁的重平衡，频繁的Ful GC会导致长时间的断顿。解决： JVM调优。
展开
11
Berk
2020-04-20
老师您好, 我们在生产环境中有一个90个分区的主题。部署了三十台机器的consumer group. 每个consumer理论上消费三个分区。我们发现有时rebalance发生后，分区不能平均的分配到consumer group中。极端情况下有的consumer被分到三十个分区。请问老师这种情况应该如何排查？
作者回复: 这是可能的。你可以试试换一个分配策略，比如设置partition.assignment.strategy=org.apache.kafka.clients.consumer.RoundRobinAssignor试试。后引入的RoundRobinAssingor在对抗极端情况时比默认的RangeAssignor要均匀一些，不妨试试
共 2 条评论
11
Sruby
2020-03-30
将consumer端的业务逻辑放到另外一个线程中处理，是不是可以避免Consumer 消费时间过长的问题，同时提高消费速率？
作者回复: 可以啊。这的确是一种办法
共 3 条评论
10
冬风向左吹
2020-03-26
如果代码升级，进程要重启，岂不是每次升级都会导致rebalance???
作者回复: hmmm.... 是这样的，所以社区2.4引入了静态consumer group成员，某种程度上可以规避这样的问题
共 2 条评论
10
miwucc
2019-09-16
从0.10.1.x开始，客户端貌似已经把心跳线程和业务线程分开了，这样的话max.poll.interval.ms还是会影响心跳导致rebanlance吗？另外加入某个broker主分区挂掉，broker重新选组是不是也要引发reblance？
作者回复: 会的。max.poll.interval.ms是rebalance的超时时间。broker端Coordinator挂掉不会引发rebalance
共 4 条评论
8
钱
2019-08-16
1：rebalance是啥？ Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。 2：rebalance有啥弊端？ 2-1：Rebalance 影响 Consumer 端 TPS。这个之前也反复提到了，这里就不再具体讲了。总之就是，在 Rebalance 期间，Consumer 会停下手头的事情，什么也干不了。 2-2：Rebalance 很慢。如果你的 Group 下成员很多，就一定会有这样的痛点。还记得我曾经举过的那个国外用户的例子吧？他的 Group 下有几百个 Consumer 实例，Rebalance 一次要几个小时。在那种场景下，Consumer Group 的 Rebalance 已经完全失控了。 2-3：Rebalance 效率不高。当前 Kafka 的设计机制决定了每次 Rebalance 时，Group 下的所有成员都要参与进来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。 3：rebalance啥时候发生？ 3-1：组成员数量发生变化 3-2：订阅主题数量发生变化 3-3：订阅主题的分区数发生变化 4：rebalance的算法是啥？ 4-1：全员参与的分区分配策略——目前的算法，也是rebalance慢的根源 4-2：粘性的分区分配策略——尽量不动没有问题的分区，重新分配有问题的分区 5：rebalance能否避免？不能完全避免只能最大限度的设置更为合理的参数，来避免非必要的rebalance，比如这些参数 5-1：session.timeout.ms 5-2：heartbeat.interval.ms 5-3：max.poll.interval.ms 5-4：GC参数疑问？ rebalance的算法为啥最早是全员参与的方式？kafka起源于大数据，估计分区数比较多的情况应该早已经猜到。另外，粘性的分区分配策略具体是怎么实现的，听起来不难，但是写kafka的人都实现的不佳，想必不是那么容易的，老师觉得实现的痛点在哪里？
展开
8
z.l
2019-07-12
”0.10.1之前是在调用poll方法时发送心跳的的，0.10.1之后consumer使用单独的心跳线程来发送“，是否意味着0.10.1之前如果一批消息的消费时间超过了session.timeout.ms，也会触发rebalabce?此时是不是应该保证max.poll.records个消息的消费时间必须小于session.timeout.ms？
作者回复: 是的
8
花开成海
2019-07-12
请问，内部topic可以增加分区数量吗？有实践过吗？有一个很大集群，内部topic某个分区的副备偶发的被剔除isr然后再加入，观察发现这个分区的写入较大，所以希望增加分区数量。
作者回复: 别增加。目前源代码中内部topic的分区被hard code成50了，如果后面修改会造成各种问题。已经有对应的bug来解决此事了，但代码还没有merge
7
杨陆伟
2019-12-15
消费者给协调者踢出后，还会继续保持心跳并重新连上吗？
作者回复: 一旦Coordinator将consumer踢出组，该consumer实例会禁掉心跳并等待前端主线程重新加入组
6
其实我很屌
2019-07-19
老师你好，问下，一个group.id内所有topic和分区的消费信息都是放在offset topic的一个分区里吗？
作者回复: 嗯，是的
6

