使用JMS队列的潜在缺陷？

Question

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

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

1）应用服务器上安装一个数据库，并使用表格各种队列。队列将由Java应用程序处理，或者在应用程序服务器中运行，或者作为自己的服务单独运行。

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

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

随着战略1，我很明显如何满足这些要求，但它可能不如健壮性和可扩展性，并且比战略2更复杂，因为我需要编写自己的多线程代码来处理各种独立队列。我想知道为什么使用JMS队列可能存在的潜在缺陷，因为我从来没有和他们合作过。

，数据安全是一个大问题，所以我需要确保JMS可以保证在重新启动服务器，停电的情况下，无数据丢失，或者如果队列中获得某种原因非常大。例如，在一段时间内完成主数据库事务的问题可能会导致JVM耗尽内存，崩溃并丢失所有累积的数据？ （这将是噩梦场景）。

此外，我想知道是否有任何方法可以通过应用服务器管理工​​具暂停JMS队列处理，或者轻松看到队列中有什么（我将排队一个对象，这将是消息xml加上一些其他数据，包括收到的时间戳等）。我已经阅读了几篇关于相关问题的文章，但希望得到一些直接的反馈。基本上我想知道JMS不是合适的排队解决方案的实例（如果有的话），以及这是否是其中一种情况。任何意见是极大的赞赏。

Answer 1

卡莱布的有关JMS的好处，答案说得很雄辩，但因为你是问的陷阱，这是我能想到的。

• 并非所有的JMS实现是相等的。从理论上讲，你可以使用任何符合你需要的实现，但除非你准备好进行一些严重的负载测试和失败条件测试，否则根据你的特定用例，你不会知道某个特定的实现不会失败。
• 大多数JMS使用像关系数据库这样的事务性数据存储作为它们的后端。这意味着，您不必直接写入您熟悉的任何数据存储区，而必须依赖JMS实现在您和存储的消息之间的额外层。
• 虽然交换JMS实现找到一个完全符合你的需求似乎是因为同质JMS API的一个简单的努力，故障处理，JMS服务器监控，以及所有其他很酷的东西重要的功能，上面存在，如果你确实改变了你的实现，那么除了消息传递将会是一件麻烦事。

这就是说，我认为你会疯狂地写自己的DB而不是使用JMS。第一点，ActiveMQ是在许多企业环境中使用的可敬的JMS服务器。关于第二点，事实是，你最终会自己写这个额外的层来实现消息传递，而且你的代码不会有成千上万的眼睛的好处（或者是一组单纯的工作的付费开发者对客户做出回应并确保JMS的实施是可靠的）。关于第三点，以及后端数据存储的结果也是如此。使用JMS，您将长期保存自己的麻烦。

Answer 2

如果你想要去的JMS路线，独立JMS兼容的消息代理（从您的应用程序服务器分开）将是一个不错的选择。消息代理的范围从免费开源（如ActiveMQ在http://activemq.apache.org/或OpenMQ在https://mq.dev.java.net/）到大型商业解决方案（IBM的WebSphere MQ在http://www-01.ibm.com/software/integration/wmq/是最大的之一）。

消息中间商报价保证交付（提供服务器并聆听），你可以做相当多的位，以确保系统故障安全包括集成的备份代理服务器和即时备用电源。如果您的应用程序服务器没有收到消息，代理队列最终可能会耗尽空间，但是您可以分配巨大的队列深度（100 GB），并在消息未得到处理并且队列到达时让服务器发送警报一定比例。

你的Java应用程序将随后在不同的服务器上完全运行，并会以最快的速度连接到代理和拉断的消息队列的越好。如果应用程序服务器因任何其他原因崩溃或停止拾取消息，那么代理将只保留该队列中的所有消息，直到应用程序服务器再次开始拾取消息为止。