处理流应用程序中事件的倾斜处理时间

Question

我有一个流应用程序（用 Spark/storm/任何无关紧要的东西编写）。 Kafka 用作流事件的来源。现在，与其他事件相比，有些事件需要占用更大的资源（时间、CPU 等）。

如何在各种框架中处理这些较大的消息，存在特定于应用程序的细微差别。例如

1. spark Streaming 的批处理将被阻塞，除非事件得到处理。
2. storm 可能会继续处理事件，直到达到分区的最大未确认消息数。

因为在kafka中，消息确认只能通过某些messageid par分区来进行，但不能在单个消息级别上进行。每当这些较大的事件发生时，应用程序就会在某个时间点停止。这样做是为了解决重复消息处理的权衡（如果应用程序在处理这些大消息时死机，您可以重做多少工作，因为较大消息之后的所有消息都需要重播）。另一个问题是滞后警报，因为即使我在较大的消息之后处理消息，由于较大的消息被卡住，提交的偏移量也不会移动。

基于这种理解，我得出的结论是，当主题中所有消息的处理时间相似时，kafka 更适合（至少 Spark 和 Storm 只提供在主题级别调整事物的选项，而不是在单个分区级别）。

因此以下是我的选择

1. 我的分区策略应确保一个主题中的所有消息（分区级别隔离不起作用）需要几乎相同的处理时间。
2. 使用可以在单个消息 ID 级别进行确认的流源，例如 redis 队列或 Rabitmq
3. 使重复消息处理的成本非常低（比如说通过查找并检查消息是否已被处理）并将最大未确认消息限制保持在非常高的水平。

还有其他选择来处理这些情况吗？

Answer 1

您需要维护关键订单处理吗？如果您确实需要维护键的顺序，您可以使用专门的消费者，例如 Confluence 的并行消费者：https://github.com/confluenceinc/parallel-consumer。它并行处理不同的键，同时确保顺序处理具有相同键的记录。 （它也适用于无序键）这将并行处理来自同一分区的小型和大型记录（消除队头阻塞问题）。正如您所建议的，幂等机制在失败的情况下仍然有用。

请注意，Kafka 队列即将推出 KIP-923