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