JMS 事务 - 开销 - 如果可能，如何避免它？

Question

在我们的应用程序中，我们接收来自 JMS 主题的消息。

• 首先我想知道 JMS 是否遵循 FIFO 策略。如果不是，应用程序如何确定哪条消息是最新消息？

我们使用消息（持久订阅者和 JMS 会话进行事务处理，开销很大），因为消息保留在 JMS 服务器上，直到事务提交/结束。我们指定交易的原因是

• 我们正在使用缓存（休眠）技术和事务来使用它。因此，我们使用了两个事务，一个是 JMS tx，一个是缓存技术 tx。当我们使用消息并且我们希望全部或不发生任何事情时，直到消息被提交并将确认发送到 JMS。缓存 tx 将首先提交，然后立即 JMS tx 将提交下一个并确认消息，否则，两个 tx 都将回滚并重播消息。我们目前正在重播​​消息 3 次，如果仍然出现异常，则将消息发送到不可处理队列。

• 这工作正常，直到大量消息同时到达 JMS 并且需要我们的系统同时处理。

• 我想知道当你遇到这种情况时你是怎么做的。因为，维护持久订阅和事务会话对 JMS 服务器来说是一个很大的开销，并且会消耗服务器的性能。

Answer 1

JMS 规范中没有指定主题的消息排序，因此官方对此的回答是它是特定于 JMS 实现的。话虽如此，除非特别重写以执行其他操作，否则我认为消息将按 FIFO 顺序传递。

对于事务，我建议您考虑实现两阶段提交 XA 事务，这样您就不需要两个单独的事务。如果您的缓存实现支持 XA，那么 JMS 和 Cache（和 DB）事务将是一回事。

一般而言，我发现对于这些类型的事务消息，如果您必须使用事务消息，那么挤出性能的最佳方法是在一个事务中处理尽可能多的消息：

1. 开始交易
2. 检索 n 条消息（或所有消息直到超时）
3. 处理消息
4. 提交事务。
5. 转到 1。

另一种用 1 块石头杀死 2 只鸟的方法是在检索期间跳过对消息的处理，并将检索到的消息简单地写入事务数据存储。然后让一个单独的线程从存储中检索消息（按时间戳顺序）并处理它们（单独的线程 - = 单独的事务）。