kafka + 消费者组的根本原因是重新平衡

Question

Kafka 机器作为 hortonworks 包的一部分安装，kafka 版本是 0.1X

我们运行 deeg_data 个应用程序，使用来自 kafka 个主题的数据

最后几天我们看到我们的应用程序 – deeg_data 失败了，我们开始寻找根本原因

在 kafka 集群上，我们看到以下行为

/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --group deeg_data --describe --bootstrap-server kafka1:6667
To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files>
where num_of_file > 0
GC log rotation is turned off
Consumer group ‘deeg_data’ is rebalancing

从 kafka 端 kafka 集群是健康的，所有主题都是平衡的，所有 kafka 代理都已启动并正确签署到 zookeeper

一段时间（几个小时）后，我们再次运行以下内容，但没有关于 - Consumer group ‘deeg_data’ is rebalancing

的错误

我们得到以下正确结果

/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --group deeg_data --describe --bootstrap-server kafka1:6667
To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files>
where num_of_file > 0
GC log rotation is turned off
GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG OWNER
deeg_data pot.sdr.proccess 0 6397256247 6403318505 6062258 consumer-1_/10.3.6.237
deeg_data pot.sdr.proccess 1 6397329465 6403390955 6061490 consumer-1_/10.3.6.237
deeg_data pot.sdr.proccess 2 6397314633 6403375153 6060520 consumer-1_/10.3.6.237
deeg_data pot.sdr.proccess 3 6397258695 6403320788 6062093 consumer-1_/10.3.6.237
deeg_data pot.sdr.proccess 4 6397316230 6403378448 6062218 consumer-1_/10.3.6.237
deeg_data pot.sdr.proccess 5 6397325820 6403388053 6062233 consumer-1_/10.3.6.237.
.
.
.

所以我们想了解为什么会得到：

Consumer group ‘deeg_data’ is rebalancing

出现上述状态的原因是什么，以及为什么我们得到 rebalancing

我们也有不错的post(https://www.confluent.io/blog/kafka-consumer-multi-threaded-messaging/)

集团再平衡当消费者组中的消费者之间需要重新分配分区时，会触发消费者组重新平衡：新的消费者加入该组；现有消费者离开该组；现有消费者更改订阅；或分区被添加到订阅的主题之一。

重新平衡由组协调器协调，它涉及与组中所有消费者的沟通。要更深入地了解消费者组再平衡协议，请参阅来自 Kafka 峰会的 Matthias J. Sax 所著的关于 Kafka 的再平衡协议您一直想知道但不敢问的一切和 Gwen Shapira 所著的 Apache Kafka 神奇的再平衡协议。

关于消费者客户端代码，分配给它的一些分区可能会在重新平衡期间被撤销。在旧版本的重新平衡协议中，称为急切重新平衡，分配给消费者的所有分区都被撤销，即使它们将再次分配给同一个消费者。使用较新的协议版本，增量协作重新平衡，只有重新分配给另一个消费者的分区才会被撤销。您可以在 Konstantine Karantasis 的这篇博客 post 和 Sophie Blee-Goldman 的这篇博客 post 中了解有关新再平衡协议的更多信息。

无论协议版本如何，当分区即将被撤销时，消费者必须确保记录处理完成并为该分区提交偏移量，然后再通知组协调器可以安全地重新分配分区.

在每个消费者模型的线程中启用自动偏移提交，您不必担心组重新平衡。一切都由 poll 方法自动完成。但是，如果您禁用自动偏移量提交并手动提交，则您有责任在发送加入组请求之前提交偏移量。您可以通过两种方式执行此操作：

注意 - 也不错 post 来自 you-tube - https://www.youtube.com/watch?v=QaeXDh12EhE

注意 - 良好的堆栈溢出 post -

注意 - 从 ENV 方面来看，由于我们的 zookeeper 服务器安装在 VM 机器上并且 VM 机器使用非 ssd 磁盘，并且关于交换消耗，那么我认为我们还需要考虑 post - https://community.cloudera.com/t5/Community-Articles/Zookeeper-Sizing-and-Placement/ta-p/247885

Answer 1

Kafka 中的重新平衡是一种协议，被各种组件（Kafka 连接、Kafka 流、Schema 注册表等）用于各种目的。

在最简单的形式中，只要任何 [=30] 发生变化，就会触发重新平衡=]元数据.

现在，元数据这个词可以有很多含义 - 例如：

对于主题，它的元数据可以是主题分区 and/or 副本及其存储位置（哪个代理）
在消费者组的情况下，它可能是作为该组一部分的消费者的数量以及他们正在使用来自等的消息的分区。

以上示例绝不是详尽无遗的，即主题和消费者组的元数据更多，但我不会在这里详细介绍。

因此，如果有任何变化：

主题的分区或副本数，例如添加、删除或不可用
一个消费者组中的消费者数量，如添加或移除
其他类似的变化...

重新平衡将被触发。在消费者群体重新平衡的情况下，消费者应用程序需要足够健壮才能满足这种情况。

所以重新平衡是一项功能。但是，在您的情况下，它似乎发生得非常频繁，因此您可能需要调查客户端应用程序和集群上的日志。

以下是一些可能有用的参考资料：

Rebalance protocol - 关于这个主题的一篇非常好的媒体文章
Consumer rebalancing - 另一个 post 关注消费者再平衡的 SO

kafka + 消费者组的根本原因是重新平衡

kafka + what chould be the root cause for Consumer group is rebalancing

apache-kafka

kafka-consumer-api