3

我有一个以非常高的速率（> 100,000/sec）填充的 JMS 队列。

每秒也可能有多条与同一实体有关的消息。（对 entity 的多次更新，每次更新都作为不同的消息。）

另一方面，我有一个消费者处理此消息并将其发送到其他应用程序。

现在，由于消费者无法应对传入消息的速度，整个设置正在放缓。

因为，消费者处理消息的速率有一个 SLA，所以我一直在玩弄让多个消费者并行行动以加快流程的想法。

所以，我想做的是

  • 多个消费者在队列上独立行动。
  • 每个消费者都可以自由地获取任何消息。
  • 抓取消息后，确保它是实体的最新版本。为此，我可以检查处理该实体的应用程序。
  • 如果它不是最新的，请升级版本并重试。

到目前为止，我一直在查找集成模式和 JMS 文档，但没有成功。

我欢迎以更优雅的方式解决这个问题的想法以及 Java 世界中任何已知的 API、模式。

4

3 回答 3

2

ActiveMQ 用一个叫做“消息组”的概念解决了这个问题。虽然它不是 JMS 标准的一部分，但一些与 JMS 相关的产品的工作方式类似。基本思想是将每条消息分配给一个“组”，该“组”指示相关且必须按顺序处理的消息。然后进行设置，以便每个组仅交付给一个消费者。因此，您可以获得组之间的负载平衡，但保证组内的按顺序交付。

于 2012-12-31T19:42:13.893 回答
0

大多数 EIP 框架和 ESB 都有可定制的重测序器。如果实体的数量不是太大，您可以为每个实体设置一个队列并在开始时重新排序。

于 2012-12-31T18:56:53.270 回答
0

对于那些对解决此问题的方法感兴趣的人：

由于问题是关于 JMS 的，我们可以看看Apache Camel 网站上的一个例子。

这种方法与CBR和选择性消费者等其他模式不同，因为消费者不知道它应该处理什么消息。让我把它放在一个现实世界的例子中：

我们有一个订单管理系统 (OMS)，它发送订单以由 ERP 处理。然后订单经过 6 个步骤，每个步骤都会在 Order_queue 上发布一个事件，通知新订单的状态。这里没什么特别的。OMS 使用该队列中的事件，但必须以它们发布的相同顺序处理每个订单的事件。每分钟发布的消息速率远大于消费者的吞吐量，因此延迟会随着时间的推移而增加。

解决方案要求：

  • 并行消费，包括尽可能多的消费者，以将队列大小保持在合理的数量。
  • 保证每个订单的事件都以相同的发布顺序进行处理。

实施：

在 OMS 方面 负责将订单发送到 ERP 的 OMS 流程确定将处理某个订单的所有事件的消费者，并将接收者名称与订单一起发送。这个过程如何知道收件人应该是什么？好吧，您可以使用不同的方法，但我们使用了一种非常简单的方法：Round Robin。

在 ERP 上 因为它为每个订单保留了收件人的姓名，所以它只是设置了要传递给所需收件人的消息。

在 OMS 消费者 上，我们部署了 4 个实例，每个实例使用不同的收件人名称并同时处理消息。

可以说我们创造了另一个瓶颈：数据库。但事实并非如此，因为订单行上没有并发。

一个缺点是，将订单发送到 ERP 的 OMS 流程必须了解有多少收件人正在工作。

于 2014-07-31T15:00:49.783 回答