Transactions 具有多个使用者但只有一个活动使用者的MQ队列

我们有一个MQ队列，它接收来自我们无法控制的外部系统的消息。 我们处理传入消息的系统是一个关键的系统，无论发生什么情况，都需要全天候启动和运行

传入消息的处理顺序也是不可协商的，这意味着我们需要完全按照它们到达的顺序来处理它们

为了确保我们的系统100%可用，我们将我们的系统部署到一组能够处理这些消息的物理机器上

一旦消息到达我们的系统，我们就建立了一种机制，以确保消息处理不会出现故障，同时由于并行处理而获得一些性能增益。对我们来说，性能的提高是一个很好的选择，但是这是一个副作用，因为我们的主要目标是在确保正确处理顺序的同时实现高可用性

我的想法是在每台机器上都有一个MDB，它能够处理传入的消息，但一次只有一个活动消费者

我们使用WebSphereMQ作为JMS提供程序，使用WebSphereApplicationServer8.5部署我们的应用程序

多个使用者侦听同一队列的问题似乎不是一个可行的解决方案，因为当消息大量到达时，它们将被循环传递给所有使用者，并且无法控制这将如何发生，消息很容易失去顺序

当我手动停止所有监听器时，除了一个监听器外，消息显然是按顺序处理的。但手动关闭和启动此类侦听器绝对不是HA解决方案

我们可以设置监控流程来检查系统的健康状况，并根据需要关闭或启动它们，但这在我看来仍然太弱。 事实上，我们想要的是让所有侦听器都启动并运行，但只有一个侦听器接收消息。如果这一个因为任何原因而下降，那么坐在那里的另一个将变得活跃并开始处理消息

最初，我们考虑使用主题而不是队列，但这会带来以下其他问题：

我们无法控制信息的来源

我们拥有的大量消息将使我们陷入困境，因为我们的订阅者不断减少，这些订阅者必须是持久的，因此，当我们返回时，将不得不处理大量待处理的消息

输入队列已经是集群的一部分，更改所有基础结构将需要大量工作

无论如何，在我看来，它必须是一个现有的模式，以适应这种情况。如有任何帮助和建议，将不胜感激

解决方案不必是特定的MQ解决方案，任何想法都是受欢迎的

---

提前感谢

在我看来，同步多个消费者不是什么大问题，是最有效的解决方案。我不知道在哪里必须记录处理结果（也许是JMS队列？），但我会在这之前尝试使用lightweitght代理。您可以使用时间戳或通过JMS实现计数器来保持顺序。 使用者可以并行执行，然后在支持队列中发布。然后，单个代理可以使用queuebrowser然后使用事务对其进行排序。该代理应该是“wathdogged”

---

Alessandro

创建第二个队列，我们将其称为“控制队列”。在该队列中，放入一条消息，我们将其称为“令牌”。更改应用程序处理如下：

在控制队列上侦听消息

从syncpoint下的控制队列获取令牌

将相同的令牌消息放回控制队列，也放回同步点下

从正常输入队列（也在同步点下）处理事务

提交

消息

循环

COMMIT

完成输入队列上的事务，并使令牌可供其他MDB使用。只有在同步点下具有令牌的MDB才能处理输入队列。但是，您可以让任意数量的MDB等待令牌。其中任何一个的失败都会让其他人立即接管

---

顺便说一下，不需要使用XA。WMQ的单阶段提交在这方面非常有效。

当应用程序试图通过MDB侦听器使用队列时，我们可以通过使用DEFSOPT（独占）定义队列来限制它们。这将确保只有一个应用程序可以使用该队列中的消息

---

如果我们希望只限制应用程序的一个实例，请将其定义为NOSHARE。因此，一个应用程序的一个实例一次可以获取队列上的消息。当当前代理解除锁定时，其他人将轮到他们。

谢谢ALessandro，请你更具体地说明你对轻量级代理的定义。这是一个将附加计数器或分析时间戳的小型消费者吗？只是一个简短的提示，我尝试使用JMSTimestamp将消息重新排序，但没有成功。通过分析一个月的工作数据，我们发现了这样一个事实：在很多情况下，我们会在同一毫秒内收到多条消息。最大值为每毫秒22条消息。非常感谢Rob。这看起来是个很好的主意，也很有趣。我需要创建一个POC spike，一旦我能让它工作起来，我就会带着我的发现回来。谢谢Rob。一切都如期进行。我注意到，与只有一个MDB消费者的情况相比，处理整个测试批的时间增加了一倍，与我的四个消费者并行运行的情况相比，处理整个测试批的时间大约慢了八倍（但消息的顺序不一致）。无论如何，它是有效的，我认为有办法提高处理时间。但遗憾的是，在写入队列时，无法将序列号附加到消息。那会很好地解决我的问题。然而，格雷亚