java - 使用 JMS 队列的潜在陷阱？

Question

我被要求设计和实现一个系统，用于从大量设备接收大量自动传感器数据。此数据将定期生成，并以 xml 格式在 http post 中发送到服务器。如果设备没有收到来自服务器的特定确认，它们将继续重新发送相同的数据。在通过事务将数据插入主数据库中的多个表之前，需要对这些数据进行一些潜在的繁重处理，此外，一些数据点需要排队以重新定向到其他外部 url。

我计划使用带有 servlet 的 Java 应用程序服务器(倾向于 GlassFish)来接收传入数据。我想实现某种排队机制来临时存储数据，以便返回给传感器的响应不依赖于所有中间处理。单独的独立队列也是数据重定向部分的要求。在做了一些研究之后，两个主要选项似乎是:

1) 在应用服务器上安装数据库并为各种队列使用表。队列将由 Java 应用程序处理，该应用程序可以在应用程序服务器中运行，也可以作为自己的服务独立运行。

2) 使用数据库支持的 JMS 解决方案来实现排队。

我对 JMS 不是很熟悉，但从我读到的内容来看，它似乎是这种情况下更好的解决方案。主要要求是传感器数据在处理之前不会丢失或从队列中删除，并且或多或少按顺序处理。我们还希望能够轻松地在特定时间停止某些队列的处理，但仍然让它们积累数据，并且这些消息永远不会自动过期。

对于策略 1，我很清楚如何满足这些要求，但与策略 2 相比，它的健壮性和可扩展性可能较差，而且开发起来更复杂，因为我需要编写自己的多线程代码来处理各种独立队列。我想知道为此目的使用 JMS 队列可能存在哪些潜在缺陷，因为我以前从未使用过它们。

数据完整性是一个大问题，因此我需要确保 JMS 可以保证在服务器重启、断电或队列因某种原因变得非常大的情况下不会丢失数据。例如，在一段时间内完成主数据库事务的问题是否可能导致 JVM 内存不足、崩溃并丢失所有累积数据？ (这将是噩梦场景)。

此外，我想知道是否有任何方法可以通过应用程序服务器管理工​​具暂停 JMS 队列处理或轻松查看队列中的内容(我将排队一个对象，该对象将是消息 xml 加上其他一些数据，包括收到的时间戳等)我在这里阅读了一些处理相关问题的帖子，但想获得一些直接反馈。基本上我想知道 JMS 不是合适的排队解决方案的实例(如果有的话)，以及这是否属于其中一种情况。非常感谢任何建议。

Answer 1

Kaleb 的回答非常 Eloquent 地谈到了 JMS 的好处，但既然你问的是陷阱，这就是我能想到的。

• 并非所有 JMS 实现都是平等的。从理论上讲，您可以使用适合您需要的任何实现，但除非您准备好进行一些严格的负载测试和故障条件测试，否则您无法知道特定的实现在您的特定用例下不会失败。
• 大多数 JMS 使用事务性数据存储(如关系数据库)作为后端。这意味着您不能直接写入您熟悉的任何数据存储，而必须依赖 JMS 实现在您和存储的消息之间的额外层。
• 虽然交换 JMS 实现以找到完全符合您需求的实现可能看起来是一项简单的工作，因为同质的 JMS API、故障处理的关键特性、JMS 服务器监控以及上面存在的所有其他很酷的东西如果您确实更改了您的实现，除了消息传递之外将是一个处理麻烦的问题。

就是说，我认为您自己写入数据库而不是使用 JMS 会很疯狂。关于第一点，ActiveMQ 是一种在许多企业环境中使用的古老的 JMS 服务器。关于第二点，事实是你最终会自己编写额外的层来实现消息传递，而你的代码将不会受益于成千上万的眼睛(或一组付费开发人员，他们是唯一的工作)响应客户并确保 JMS 实现可靠)。关于第三点，后端数据存储也是如此。使用 JMS，从长远来看，您会省去麻烦。