我正在阅读一篇博客，其中一个观点是“如果你正在使用队列，那么你就搞砸了”，在JMS的背景下。
我在想，我们甚至需要JMS吗？一个简单的替代方案是，如果你需要异步执行某些操作，为什么不在某个地方将一个作业请求放在一个表中，并让每个X时间单位轮询数据库以寻找新的工作？
这种方法比JMS简单，易于理解，并且基本上消除了应用程序的依赖性。
如果我使用我描述的替代品，我会失去什么？也许人们失去了使用JMX来管理事物的可能性，但是如果你的工作“队列”是从表中提取的，你可以编写一些简单的代码来“管理”处理。
答案 0 :(得分：3)
我正在阅读一篇博客，其中一篇 分数是'如果你正在使用队列， 你在JMS的背景下搞砸了。
这是完全错误的。
如果不合适，可以选择使用队列，但如果是JMS则是一个不错的选择。
如果我是你，我会更加清楚我在互联网上读到的内容。听起来像是作者喜欢制作煽动性言论来为他的博客增添趣味并提升他的Google Analytics统计数据。这是一个人的意见，仅此而已。
轮询解决方案更复杂，浪费了CPU周期，而且在我看来并不是实时。
如果需要异步处理，可以使用Executor或FutureTask。如果你需要asynch，这些将是队列的合理替代品。
答案 1 :(得分：2)
我真的很想知道你在哪里阅读。 JMS是经过验证的技术，但与所有解决方案一样，您也可以滥用它。如果需要安排任务，可以使用众多任务调度库之一。 以下是概述：http://java-source.net/open-source/job-schedulers
答案 2 :(得分：0)
对于只是异步处理的非常简单的要求，您可以使用java.util.concurrent包中的任何合适的类。
如果您需要交易或保证作业必须在提交后成功完成，即使遇到系统故障（软件甚至硬件崩溃），或者您想将作业处理卸载到另一个流程，您还需要其他解决方案。
JMS方法可以相对较少的努力提供非常复杂的解决方案。
消息传递（或JMS）是一种非常标准的集成解决方案，可以解决保持作业异步提交的问题，并保持与实际处理分离的任务提交。基于消息传递的解决方案可以通过增加“工作处理器”的数量来轻松扩展。线程在工作队列中侦听。流量将自动负载平衡。消息传递系统还可以提供事务支持，即如果作业处理失败，则会自动将消息放回队列，以便可以重试。
许多企业集成模式都基于消息系统（面向消息的中间件）。这本关于Enterprise Integration Patterns by Gregor Hohpe的书籍介绍了如何在应用程序中使用消息传递的最常用模式。
数据库方法需要另一个进程
1）轮询表中的新作业＆＃39;，在处理应用程序启动作业处理时更新行的状态，最后将作业的行状态更新为“完成”＃ 39; （或从表中完全删除作业）。 2）如果在工作处理过程中出现问题，应将工作状态更改回“新工作”状态。在桌子上，以便'轮询'＃39;机制可以再次获得工作。此外，还需要编写一些恢复线程＆＃39;在系统启动时找出可能处于不一致状态的工作并将它们放回“新的”工作中。说再次开始处理。
总而言之，构建基于数据库的集成解决方案需要花费很多精力。它还将“工作提交者”和“工作提交者”紧密地联系在一起。和＆＃39;工作处理器＆＃39;数据库模式的应用程序打破了数据库的封装。如果你的工作处理器＆＃39;有多个线程（如果你想扩展你可能需要它），那么你需要确保只有一个线程接收工作并更新＆＃39;那个＆＃39;行。
JMS解决方案可以非常轻松地解决这个问题，而无需手动编码所有这些逻辑。
当然，如果你使用队列，你不会搞砸。但是你应该有一些有效的用例来介绍消息传递中间件。
答案 3 :(得分：0)
这种方法比JMS简单，易于理解，并且基本上消除了应用程序的依赖性。
嗯，如果你来自数据库背景，这是唯一的。我认为没有什么比为每个州的变化发送信息更容易了，而且忘掉它了＃39;。
面向消息的中间件（例如JMS）的一个优点是性能更高 - 您可以拥有1M msgs /秒的速率 - 但更大的好处通常是更简洁的架构：多个组件插入的消息总线。现在您可以进行一对一的通信，但是在2年内您可能想要记录该流量，在3年内您可能希望监控错误，并且在4年内您可能希望自动记录和重放并测试它。