在非分布式应用程序中使用消息队列是否有意义答案

【问题标题】：Does it make sense to use messaging queues in a non-distributed application在非分布式应用程序中使用消息队列是否有意义
【发布时间】：2013-09-07 10:08:41
【问题描述】：

所以我打算编写一个适合生产者/消费者模式的应用程序。我当时正在考虑构建自己的生产者/消费者框架，但后来想到了我在工作中广泛使用的消息队列。考虑到我正在编写的应用程序的多个模块需要在单个服务器上作为该特定主机的客户端/控制器运行，我不能 100% 确定消息队列是否是正确的方法。

在非分布式应用程序中使用消息队列的优缺点是什么？以前有人这样用过吗？

谢谢，如果您需要更多信息，请告诉我。

【问题讨论】：

消息队列在失败的情况下提供持久性。这很重要吗？

标签： java architecture messaging

【解决方案1】：

“消息队列”是指外部消息服务器吗？我的以下答案假设这就是您所要求的。如果您只是询问更通用的架构方法，即通过内存消息而不是方法调用让模块部分或全部通信 - 是的，有时这可能非常好。像 guava 的 EvenBus 这样的类很好地促进了这样的设计：https://code.google.com/p/guava-libraries/wiki/EventBusExplained

一方面，当一个简单的队列数据结构就足够时，我通常会阻止人们使用 JMS 消息队列。有时我觉得 JMS 是一种进程间通信工具，具有一对多（主题）和一对一的通信通道恰好被命名为队列。是的，它们的访问模式类似于队列，但在我看来，更重要的特征是它们的点对点消息传递能力。所以我认为一个不幸的名字有时会导致人们在他们只需要一把螺丝刀（java.lang.Queue）时使用手提钻（JMS）。

另一方面，任何规则都有例外。我不能直接推荐一个在服务器重启期间线程安全且持久的 java.lang.Queue 实现（人们考虑 JMS 时经常需要的特性）。我确定有一些。找到一些并将它们与 JMS 进行比较。权衡业务需求、时间限制、可能的未来设计/要求等。我之前自己实现了一个，结果非常好（并且比通过网络向远程 JMS 服务器发送消息要快）——但只有你可以说如果这适合您的情况。

我想你总是可以推迟决定，让你的应用程序的模块通过你自己的类似消息传递的接口进行通信，该接口目前在内部使用 java.lang.Queues，但如果你发现你稍后会使用 JMS 需要。尽管在这里也要小心——尽早添加不必要的抽象有时会成为不值得的负担。

【讨论】：

感谢您的深入回答。我更多地考虑通过内存消息进行通信的模块架构方法。完全同意 JMS 将是一个手提钻，我查看了 EventBus，我认为这是值得探索的东西。