使用JMS队列的潜在缺陷？

Question

我被要求设计并实施一个系统,用于从大量设备接收大量自动传感器数据.此数据将定期生成,并作为xml在http帖子中发送到服务器.如果设备未从服务器收到特定确认,则设备将继续重新发送相同的数据.在通过事务将数据插入主数据库中的多个表之前,需要对该数据进行一些潜在的重载处理,并且还需要将一些数据点入队以重定向到其他外部URL.

我打算使用Java应用程序服务器(倾向于GlassFish)和servlet来接收传入的数据.我想实现某种排队机制来暂时存储数据,以便返回传感器的响应不依赖于所有中间处理.单独的独立队列也是数据重定向部分的要求.经过一些研究后,两个主要选择似乎是:

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

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

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

使用策略1,我很明显如何满足这些要求,但它可能不那么健壮和可扩展,并且比策略2更复杂,因为我需要编写自己的多线程代码来处理各种独立队列.我想知道在为此目的使用JMS队列时可能存在的潜在缺陷是什么,因为我之前从未使用过它们.

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

此外,我想知道是否有任何方法可以通过应用服务器管理工​​具暂停JMS队列处理或轻松查看队列中的内容(我会将一个对象列入消息xml加上一些其他数据,包括收到的时间戳,等等.我在这里阅读了一些处理相关问题的帖子,但希望得到一些直接反馈.基本上我想知道JMS不是一个合适的排队解决方案的实例(如果有的话),如果这是其中一个案例.任何意见是极大的赞赏.

Answer 1

Kaleb的回答很有说服力地讨论了JMS的好处,但既然你在询问陷阱,那么这就是我能想到的.

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

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