Java WMQ/JMS无丢失和重复消息原则

如果JMS客户机应用程序要求不会丢失任何消息，也不会发送重复消息进行处理，并且每条消息都与其他消息无关（无批处理），那么哪种组合满足这些要求： -持久性+自动确认会话模式（异步使用者） -持久性+客户端确认会话模式 -持久性+事务会话 -还有别的吗？ 我已经阅读了有关事务会话和ack模式（例如这里和这里）的内容，在我看来，这三种可能性都是可以接受的。你同意吗？使用事务性会话或更高级的可靠性概念有什么好处

---

提前谢谢

如果您通过网络与任何JMS传输提供商交谈，请使用事务性会话，并确保应用程序检测并优雅地处理重复消息。为什么？请参阅第4.4.13节“消息的重复生成”，其中说明：

如果在客户端提交其在服务器上的工作之间发生故障 会话和提交方法返回时，客户端无法确定 事务已提交或回滚。同样的歧义 在非事务性发送之间发生故障时存在 持久消息和发送方法的返回

由JMS应用程序来处理这种模糊性。在某些方面 在某些情况下，这可能会导致客户端生成功能上重复的 信息

由于会话恢复而重新传递的消息不可用 被认为是重复的消息

考虑一个通过网络发出

COMMIT

的应用程序。如果应用程序收到指示连接已断开的错误，它如何知道这是在API调用到达传输提供商之前还是之后发生的？如果应用程序正在发送消息，唯一安全的做法是假定

提交失败，然后重新发送消息。接收消息的对象将再次看到它

类似地，如果一个接收消息的应用程序在
COMMIT
上出现错误，那么如果该消息被回滚，它将再次看到该消息。但是，应用程序不能假定它已回滚并丢弃刚刚收到的消息，因为这可能会导致消息丢失

因此，WMQ或任何其他JMS传输提供程序都不能提供dupe，但由于网络引入的模糊性，应用程序可能会收到dupe。这是最好的情况，假设一个事务性会话，并且应用程序能够优雅地处理重复。最糟糕的情况是，在事务处理会话之外，这种模糊性可能会导致应用程序丢弃消息。
是的，这三种组合肯定都能处理“没有丢失的消息”（因为这三种组合都有持久消息）。这三种方法都应该确保消息只写一次（因此没有重复）。我建议TransactiveSession提供最佳解决方案，因为事务会话可用于总结事务中的其他活动。当然，如果您只需要JMS，那么确认会话就更容易处理。