我有一个流应用程序（写在Spark/ Storm /什么都不重要）。Kafka被用作流事件的源。现在有一些事件与其他事件相比需要更大的资源（时间，CPU等）。
在各种框架中如何处理这些较大的消息存在特定于应用程序的细微差别。例如

1. spark streaming的批处理将被阻塞，除非该事件被处理。
2. Storm 可以继续处理事件，直到已经达到分区的最大未确认消息。
   因为在Kafka中，消息打包只能通过一些messageid par分区来实现，而不是在单个消息级别。每当这些更大的事件发生时，应用程序就会在某个时间点停止。这样做是为了解决重复消息处理的折衷问题（如果应用程序在处理这些大消息时死亡，那么您可以承担多少工作来重做，因为大消息之后的所有消息都需要重播）。另一个问题是延迟警报，因为即使我一个接一个地处理较大的消息，较大的消息也会被卡住，提交的偏移量不会移动。
   基于这种理解，我得出的结论是，当一个主题中所有消息的处理时间都相似时，Kafka更适合（至少spark和storm只给予在主题级别而不是在单个分区级别进行调整的选项）。
   因此，下面是我的选择
   1.或者我的分区策略应该确保一个主题中的所有消息（分区级别隔离不起作用）需要几乎相等的处理时间。
   1.使用流源，其中可以在单个消息ID级别进行acking，例如redis队列或rabitmq
   1.使重复消息处理的成本非常低（比如通过查找和检查消息是否已经被处理），并将最大未确认消息限制保持在非常高的水平。
   是否有其他选择来处理这些情况？