多个 Kafka 生产者写入同一主题 - 如何负载平衡消费答案

【问题标题】：Multiple Kafka Producers writing to the same topic - how to load balance consumption多个 Kafka 生产者写入同一主题 - 如何负载平衡消费
【发布时间】：2020-05-24 17:03:37
【问题描述】：

所以我有一个设计，我有多个生产者 P1、P2、P3、P4 ... PN 写入具有 32 个分区的单个主题 T1。

另一方面，我在一个消费者组中最多有 32 个消费者。

我想对我的消息消耗进行负载平衡。

阅读文档我可以看到 3 个选项：
1.自己定义分区（缺点我必须知道最后一条消息发送到哪里或者为每个Producer P定义一个分区范围）
2. 定义一个键并将分区决策留给 Kafka 哈希算法（缺点 - 负载平衡将根据运气定义）

（根据 Chris 的回答，负载平衡应该留给哈希算法）-现实表明这并没有为消费者提供平等的分配，因为消费者绑定到分区，我必须了解哈希算法才能选择一个好的密钥——对我来说这听起来与选择分区相同（并且必须分配超过生产者）

我当前的代码使用 UUID 作为键。对所选分区以及消费者工作的分析表明，分布可能远非相等。我在下面复制它：

上图显示了使用 UUID 作为我的键的 5 分钟窗口内每个分区接收到的消息数量——当时我有 8 个消费者。消耗大约需要2分钟。红色的单元格显示其中一个消费者中有 9 个请求队列，而其他消费者的负载较低 - 或像绿色消费者一样为零负载。如果随机密钥不是一个好的选择，我应该选择什么？

没有分区，没有密钥，留给 Kafka 循环算法（缺点循环是生产者内部的 - 这意味着所有生产者都可以将消息发送到同一个分区 - 我也测试了这个选项，结果如下：

上图显示循环显然是生产者内部的。

我真的需要自己编写整体负载均衡算法吗？我错过了什么吗？

【问题讨论】：

标签： apache-kafka kafka-consumer-api kafka-producer-api

【解决方案1】：

在消费者之间平衡负载是 Kafka 的定义功能之一，它允许水平扩展。

生产者使用的记录密钥是允许它工作的原因。键定义了消息进入哪个分区，并且任何分区都将由一个消费者按顺序使用，因此您的生产者应使用产生均匀分布的键策略，并确保相关消息在排序很重要时具有相同的键（熊请记住，如果严格排序至关重要，则在飞行请求中还有其他考虑因素）。

前者是平衡负载的方式——消费者不涉及循环，分区只是在每个组的消费者之间尽可能均匀地共享，并且它们独立轮询。如果键分布良好，那么每个分区将具有大致相同数量的记录。

因此，要实现有效的负载平衡，您唯一的责任就是使用良好的策略来创建消息键，并使用至少与您计划将消费扩展到的分区一样多的分区来定义您的主题。

【讨论】：

如果我理解正确的话，您是说制作者应该谨慎选择密钥。根据我的理解，这与将负载平衡留给命运是一样的……我的意思是，在某些情况下，使用 key 定义分区是很好的，尤其是当您需要一个 key 多次通过一个主题时。
就我而言，顺序无关紧要。负载均衡可以。我不想在其他人不工作时将消息排在一个消费者中。 broker端没有负载均衡吗？
您好，您的理解是正确的。因为顺序无关紧要，所以是的，选择一个平衡的键，以便消息在分区之间均匀分布是您所需要的（实际上默认应该没问题）。组中的所有消费者独立并行工作，因此不需要负载平衡，组管理加入或离开组的消费者，以保持分区在成员之间均匀分布。
实际情况并非如此。我的密钥是生产者生成的 UUID。 UUID 是随机的，对 - 但它不能保证良好的分布。选择一个密钥真的让分配靠运气（实际上是 Kafka 哈希算法），这不是我需要的。我需要在分区上平均分配，Kafka 哈希算法不能保证。
好的，这就是您需要解决的问题 - 为了平衡消费，您需要一个关键策略，以实现跨分区均匀分布。
我猜想一下，Kafka的设计目标是处理高吞吐量，这就是它的散列方法和分区工作的原因。如果它是降低吞吐量的正确工具，可能值得考虑。