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

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

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

再平衡由群组协调员精心策划，涉及与群组中所有消费者的沟通。要深入了解消费者组再平衡协议，请参阅 Kafka 峰会的 Matthias J. Sax 和 Gwen Shapira 的 The Magical Rebalance Protocol of Apache Kafka 的关于 Kafka 的再平衡协议你一直想知道但不敢问的一切。

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

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

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

注意 - 来自 youtube 的帖子也不错 - https://www.youtube.com/watch?v=QaeXDh12EhE

注意 - 良好的堆栈溢出帖子 - Kafka Consumer Rebalancing takes too long

注意 - 从 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 注册表等）用于各种目的。

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

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

• 对于主题，它的元数据可以是主题分区和/或副本以及它们的存储位置（哪个代理）
• 在消费者组的情况下，可能是属于该组的消费者数量以及他们从哪些分区消费消息等。

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

所以，如果有任何变化：

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

将触发重新平衡。在消费者群体再平衡的情况下，消费者应用程序需要足够强大以适应此类场景。

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

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

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