我们有一个MQ队列，该队列从我们的控制范围之外的外部系统接收消息. 我们的处理传入消息的系统是至关重要的系统，无论如何，都需要启动并运行27x7.
We have one MQ Queue which receives messages from an external system out of our control. Our system processing the incoming messages is a critical one and needs to be up and running 27x7 no matter what.
传入消息的处理顺序也不可商议，这意味着我们需要按照它们到达的顺序进行处理.
The order in which the incoming messages are processed is also not negotiable which means we need to process them in exactly the order they arrived.
为确保我们的系统100％可用，我们将系统部署到了能够处理这些消息的一堆物理计算机上.
To make sure our system is 100% available we deployed our system to a bunch of physical machines able to process those messages.
一旦消息到达我们的系统，我们就建立了一种机制，以确保消息处理不会出现混乱，同时由于并行处理而获得一些性能提升.对我们来说，性能提升是一个很好的选择，但是它却是一个副作用，因为我们的主要目标是在确保正确的处理顺序的同时实现高可用性.
Once the messages reached our system we put in place a mechanism to make sure the messages processing does not go out of order while also getting some performance gain as a result of the parallel processing. For us the performance gain is a good to have, however it is rather a side effect as our main goal is the high availability while assuring the right processing order.
我的想法是在每台计算机上都有一个MDB能够处理传入的消息，但一次只有一个活跃的使用者.
My thoughts were to have on every single machine an MDB able to process the incoming messages but only have one active consumer at a time.
我们正在使用Webshere MQ作为JMS提供程序，并使用Webshere Application Server 8.5来部署我们的应用程序.
We are using Webshere MQ as a JMS provider and Webshere Application Server 8.5 to deploy our application.
多个消费者监听同一个队列的问题似乎不是一个可行的解决方案，因为当消息大量到达时，它们将被循环传递给所有消费者，并且无法控制这种情况的发生并且消息很容易乱序.
The problem with multiple consumers listening to the same queue does not seem to be a workable solution as when messages arrive in bulk they would be round-robin passed to all consumers and there is no way to control how this is going to happen and the messages easily go out of sequence.
当我手动停止所有侦听器时，很明显，消息是按顺序处理的.但是手动关闭和启动此类侦听器绝对不是高可用性解决方案.
When I manually stopped all the listeners but one obviously the messages got processed in order. But manually shutting down and starting up such listeners is definitely not a HA solution.
我们可以采用监视程序来检查系统的运行状况，并根据需要关闭或启动设备，但这对我来说仍然太弱了. 实际上，我们想要的是使所有侦听器都启动并运行，但是只有一个接收消息.如果那个人由于某种原因摔倒了，那么坐在那里的另一个人将变得活跃并开始处理消息.
We could put in place monitoring processes to check for health of the system and shut things down or start them up as required but this still looks too weak to me. What we want in fact is to have all listeners up and running but only one receiving the messages. If that one goes down for whatever reasons then another one sitting there will become active and start processing messages.
最初，我们考虑使用主题而不是队列，但这会带来如下其他问题:
Initially we considered using a topic rather than a queue but this comes with other issues like below:
无论如何，我认为它必须是现有的模式才能适应这种情况.任何帮助，建议将不胜感激.
Anyway in my view it has to be an existing pattern to accommodate situations like this. Any help, suggestion would be greatly appreciated.
解决方案不必是特定的MQ，欢迎任何想法.
The solution does not have to be a specific MQ one, any idea is welcome.
预先感谢
推荐答案创建第二个队列，我们将其称为控制队列".在此队列中，输入一条消息，我们将其称为令牌".更改应用程序处理，如下所示:
Create a second queue, we'll call it the "control queue." Into this queue, put a single message, we'll call it the "token." Change application processing as follows:
COMMIT完成输入队列上的事务，并使令牌可用于其他MDB.除了具有令牌在同步点下的MDB之外，无法对输入队列进行任何处理.但是，可以有任意数量的MDB在令牌上等待.他们中的任何一个人的失败都会使其他人立即接手.
The COMMIT completes the transaction on the input queue and makes the token available to the other MDBs. No processing of the input queue can occur except by the MDB that has the token under syncpoint. However you can have any number of MDBs waiting on the token. A failure of any one of them allows the others to take over instantly.
顺便说一句，无需使用XA. WMQ的单阶段COMMIT与此配合得很好.
No need to use XA, by the way. WMQ's single-phase COMMIT works great with this.
更多推荐
具有多个使用者但只有一个活动的MQ队列
发布评论