使用高级消费者读取 Kafka 日志时发生的分区滞后值答案

【问题标题】：Incensistent partition lag values when using high level consumer for reading Kafka logs使用高级消费者读取 Kafka 日志时发生的分区滞后值
【发布时间】：2016-02-13 07:39:14
【问题描述】：

我们所有的 30 个主题都是在我们的 kafka 中使用 10 个分区创建的。我们正在按分区监控所有主题/组 ID 的滞后。

我们正在使用 Fluentd 插件从 kafka 读取和路由日志。该插件是使用高级消费者实现的。我们为单个主题配置了一些消费者，为插件配置了一些消费者。总体而言，除了 3 个主题外，数据流过没有问题。

问题在于，对于正在处理的 30 个主题中的 3 个，我们看到分区滞后值不一致，即。查看特定主题/组 ID 的延迟值，某些分区的延迟远高于其他分区，有时高达 30k。但是，对于其他 27 个主题，所有分区的滞后数保持一致，一个主题/组 ID 的所有分区保持在彼此接近的范围内（例如，所有分区都在 12 到 18 之间）。

几乎每次我们重新启动 Fluentd 代理（它重新启动高级消费者）时，我们都会看到这 3 个主题的延迟开始平滑，有时它们会保持一致一段时间，然后延迟数字又开始变得曲折。这仅发生在 3 个主题中。但是当我们检查这 3 个主题的分布时，一切看起来都很正常。

我们对此感到不知所措。高级消费者不编写用于管理从分区中检索数据的代码。它是处理那部分的kafka lib。消费者代码指定的只是线程数。我们尝试了 10 和 5 次，在所有情况下（尤其是 10 和 5 线程），这 3 个主题的滞后不一致一直出现。每个主题的数据量都低于每小时 30k。

关于可能是什么原因的任何建议？有什么办法呢？

非常感谢您提前提供的帮助。

【问题讨论】：

标签： multithreading apache-kafka kafka-consumer-api fluentd

【解决方案1】：

根据所提供的详细信息，我将首先查看以下几点，我想您已经看过它们了。

比较 3 个主题与其他主题生成消息的趋势。还要检查发布到这些主题与其他主题的消息大小。
只需将有问题的 3 个主题移至另一个 fluentd 实例即可验证滞后行为。

如果您发现更多内容或通过一些微调解决问题，请告诉我

【讨论】：

感谢您的回复。是的，我做过那些。没有关于这些主题流或消息大小的具体内容。我们还有其他主题的流量越来越低。消息大小有点小。我已经启动了另一个只有这 3 个主题的 fluentd 服务器，并且出现了相同的不一致/之字形滞后值。我在新服务器上测试了 6 个其他主题，就像在原始服务器上一样，所有主题的行为都符合预期：所有分区的一致/平滑滞后值。我的猜测是，这与 Kafka 中的这 3 个主题有关。但无法猜测它会是什么。
忘了提同样的 3 个主题正在由另一个高级消费者使用 1 个线程处理，并且滞后都很顺利。
知道了。这三个主题的分区或复制数量有什么不同吗？在 fluentd 使用 3 个主题与其他主题的消息（意味着对数据库或任何其他内容的任何更新）之后，是否有任何特定的过程完成？ fluentd 上的垃圾收集如何？看起来还可以吗？
所有主题都以相同的方式实现，所以不，对它们进行分区没有什么不同。垃圾收集是我们还没有看过的东西。但是，仍然很难认为 fluentd 中的某些问题只影响这 3 个主题，而不影响其他 27 个主题。当我们通过 fluentd 以及另一个 HL 使用者使用 1 个线程运行这 3 个时，我们看不到这 3 个主题的滞后数字有任何锯齿形问题。因此，似乎只使用超过 1 个线程并且仅针对这 3 个主题会创建 zigzag 滞后值。
明白你的意思。您可以分享滞后模式的图片吗？