KafKa消费者组重平衡能避免吗

Posted 2023-05-12

参考技术A Rebalance 是什么呢，Consumer Group下面的consumer需要重新获取订阅主题所属分区的消息，在协调者的帮助下，完成主题分区的重新分配，在整个过程中，Consumer实例都不能消费任何消息

对KafKa的TPS影响很大。

弊端如下：

1.影响TPS。

2.速度很慢，所有消费者都需要参与。

3.Rebalance 效率不高。

发生的时机：

1.订阅的主题数量发生变化

2.主题的分区数量发生变化

3.消费者组的消费数量发生变化

1和2情况一般是运维来操作，无法避免

但情况3是可以来讨论的，

第一类 网络问题 

合理设置额KafKa的心跳超时时长和心跳间隔，设置6s.间隔2s

第二类 消费者消费时间太长引起的

需要合理评估业务逻辑执行的时间，可以把这个值max.poll.interval.ms设置的大一些。要关注消费端的fullGC情况，合理设置jvm参数，避免fullGC时间太长。

这些其实是需要一些好的监控系统来实施。

Kafka 消费者意外地重新平衡

【中文标题】Kafka 消费者意外地重新平衡

【英文标题】：Kafka consumers rebalance unexpectedly

【发布时间】：2018-05-23 21:00:41

【问题描述】：

我们在 Java Kafka 消费者中看到了意想不到的重新平衡，如下所述。这些问题对任何人来说都很熟悉吗？有任何关于 API 或调试技术的提示来找出重新平衡的原因吗？

两个进程正在读取一个主题。有时，主题上的所有分区都会重新平衡到单个读取器进程。重新启动这两个进程后，分区变得均衡。

两个进程正在读取一个主题。有时，一长串的重新平衡会在阅读器之间反弹分区。我们在消费者上调用暂停/恢复来获得背压，这应该可以防止这种情况发生。

两个进程正在读取一个主题。有时，当看起来两个进程都读取正常时，会发生重新平衡。之后，阅读工作正常，但在处理过程中出现了问题。

我们预计分区不会在没有看到某些原因或故障的情况下重新平衡。

有时poll() 会卡住（超过超时时间），我们使用wakeup() 和close()，然后创建新的消费者。有时协调器心跳线程在消费者关闭后继续运行（我们已经看到了数千个）。时间似乎与重新平衡无关，因此重新平衡似乎是一个单独的问题，但也许心跳遇到了未记录的网络问题。

我们使用ConsumerRebalanceListener 来记录和处理某些重新平衡，但 Kafka API 似乎没有公开有关重新平衡原因的数据。

重新平衡是间歇性的，难以重现。它们以每秒 10,000 到 80,000 条的消息速率发生。我们在日志中看不到明显的错误。

我们的读取循环很简单 - 基本上是“在运行时，通过超时和错误处理轮询，然后将接收到的消息排入队列”。

人们提出了很好的相关问题，但答案对我们没有帮助：

Conditions in which Kafka Consumer (Group) triggers a rebalance What exactly IS Kafka Rebalancing? Continuous consumer group rebalancing with more consumers than partitions

配置：

Kafka 0.10.1.0（我们已经开始尝试 1.0.0，还没有测试结果） Java 8 代理和客户端 2 个代理，1 个 Zookeeper，稳定运行的进程，无需添加 5 个主题，其中 2 个有点忙。重新平衡发生在一个忙碌的人（主题“A”）。 主题 A 有 16 个分区和复制 2 个，并且在消费者开始之前创建。 一个进程写入主题 A；从主题 A 读取的两个进程。 每个读取器进程运行 16 个消费者。当 16 个分区均匀平衡时，部分消费者处于空闲状态。 消费者线程在轮询之间几乎不做任何工作。消息处理在与消费者不同的线程上异步进行。 主题 A 的所有消费者都在同一个消费者组中。 KafkaConsumer.poll() 的超时时间为 1000 毫秒。

影响再平衡的配置是：

max.poll.interval.ms=50000 max.poll.records=100 request.timeout.ms=40000

session.timeout.ms=20000

我们对这些使用默认值：

heartbeat.interval.ms=3000 （经纪人）group.max.session.timeout.ms=300000 （经纪人）group.min.session.timeout.ms=6000

【问题讨论】：

我们也遇到了同样的问题。 Kafka 0.10.0.1，12 个主题，每个主题有 10 个分区。每个主题都有不同的CG。有时一些 CG 重新平衡超过 5 分钟。进程重新启动后，一些 CG 需要长达 10 分钟才能开始消耗。自过去 2 个月以来没有找到任何解决方案，没有任何帮助

重新平衡是否足够快？因为日志清理器问题，我遇到了小组协调员的问题。您是否考虑过升级到此次要版本 (0.10.2.3) 的最新版本？

【参考方案1】：

查看gc日志，确保没有频繁的full gc，否则会导致心跳线程无法正常工作。