嘿，我有一些需要按顺序处理的消息队列。现在这个处理过程涉及到调用Web服务（有时可能会出现故障），所以我必须使消息检索具有事务性。据我所知，如果在中途出现任何异常，整个事务都会回滚，而消息不会丢失，对吗？
但是，消息消费者也需要高可用性，所以我有两个监听器实例同时监听我的队列。现在，事务是否会确保第二个监听器实例不会检索到另一个消息，直到第一个监听器完全完成了第一个消息的处理？还是说我需要做更多的工作，以确保在前一个消息完全处理完之前，不会发送队列中的任何消息。
如果需要任何其他配置，它应该在MQ还是监听器上进行？
我正在使用WebSphere MQ作为消息代理，并使用Spring Integration来检索消息。感谢您的帮助。
编辑：
使用令牌的第一个问题是队列管理器本身的高可用性。持有此令牌的队列必须是某个队列管理器的一部分。现在，如果我们发生故障，那个控制队列将不再可访问。这意味着我们需要准备另一个控制队列以备不时之需。
在正常操作期间，我们不能让侦听器侦听DR控制队列。（假设我们有一种机制可以确保“数据”队列完全复制）。侦听器实例应该知道故障转移已经启动，以便在正常操作期间停止监听控制队列并切换到副本。我无法仅使用侦听器实例来完成此操作。实际生产者将消息放入队列中，将通知侦听器实例停止监听正常操作的控制队列，并切换到副本。如果存在任何中间连接问题（而正常操作队列管理器实际上没有故障），这可能会有些棘手，但这是一个极端情况。
处理控制队列的高可用性之后，我们在低负载场景下面临与不可共享相同的问题。现在，我们偶尔会出现负载峰值，但也有低谷期（在夜间等）。这个令牌系统不是真正的反应式吧？它更像是定期的事情。所以，假设几个小时内我们没有收到任何消息。由于令牌消息不断触发一个实例接着另一个实例，因此侦听器仍将不断检查队列。这使其更像是轮询程序。我可能也可以拥有多个侦听器实例，每个实例在不同的小时段轮询吧？它不是真正的事件驱动。
但是，消息消费者也需要高可用性，所以我有两个监听器实例同时监听我的队列。现在，事务是否会确保第二个监听器实例不会检索到另一个消息，直到第一个监听器完全完成了第一个消息的处理？还是说我需要做更多的工作，以确保在前一个消息完全处理完之前，不会发送队列中的任何消息。
如果需要任何其他配置，它应该在MQ还是监听器上进行？
我正在使用WebSphere MQ作为消息代理，并使用Spring Integration来检索消息。感谢您的帮助。
编辑：
使用令牌的第一个问题是队列管理器本身的高可用性。持有此令牌的队列必须是某个队列管理器的一部分。现在，如果我们发生故障，那个控制队列将不再可访问。这意味着我们需要准备另一个控制队列以备不时之需。
在正常操作期间，我们不能让侦听器侦听DR控制队列。（假设我们有一种机制可以确保“数据”队列完全复制）。侦听器实例应该知道故障转移已经启动，以便在正常操作期间停止监听控制队列并切换到副本。我无法仅使用侦听器实例来完成此操作。实际生产者将消息放入队列中，将通知侦听器实例停止监听正常操作的控制队列，并切换到副本。如果存在任何中间连接问题（而正常操作队列管理器实际上没有故障），这可能会有些棘手，但这是一个极端情况。
处理控制队列的高可用性之后，我们在低负载场景下面临与不可共享相同的问题。现在，我们偶尔会出现负载峰值，但也有低谷期（在夜间等）。这个令牌系统不是真正的反应式吧？它更像是定期的事情。所以，假设几个小时内我们没有收到任何消息。由于令牌消息不断触发一个实例接着另一个实例，因此侦听器仍将不断检查队列。这使其更像是轮询程序。我可能也可以拥有多个侦听器实例，每个实例在不同的小时段轮询吧？它不是真正的事件驱动。
第三个问题是插入令牌消息的问题。在第一次安装或回退期间，我们需要手动插入此令牌（因为令牌有时会在故障转移中丢失）。我们不能让其中一个监听器实例执行此操作，因为如果一个监听器实例找不到消息，这意味着其他某个监听器实例拥有该令牌。因此，这个逻辑必须是独立的。如果我们真的将一些有意义的信息放入这个令牌消息中，那么它必须是一个工具，而不是通过UI插入的方式。
我想第一个和第三个问题并不是真正的问题，只是额外的开销，如果我们选择轮询器实现，则不需要这些。第二个问题最让我困扰。