0

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

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

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

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

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

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

4

1 回答 1

1

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

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

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

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

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

于 2012-04-04T13:17:21.853 回答