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

时间:2013-09-04 03:02:36

标签: java architecture messaging

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

为非分布式应用程序使用消息传递队列有哪些优缺点?有没有人以这种方式使用过它?

谢谢,如果您需要更多信息,请与我们联系。

1 个答案:

答案 0 :(得分:1)

“消息队列”是指外部消息服务器吗?我的下面的答案假设你正在做的事情。如果您只是询问更一般的架构方法,让模块通过内存消息而不是方法调用进行部分或全部通信 - 有时这可能非常好。像番石榴的EvenBus这样的类很好地促进了这样的设计:https://code.google.com/p/guava-libraries/wiki/EventBusExplained

一方面,当一个简单的队列数据结构足够时,我通常会试图阻止人们使用JMS消息队列。有时我觉得JMS是一个进程间通信工具,它具有一对多(主题)和一对一的通信通道,它们恰好被命名为队列。是的,他们的访问模式类似于队列的访问模式,但在我看来,更重要的特征是他们的点对点消息传递功能。因此,我认为有时会让人们使用手提钻(JMS),而他们需要的只是一把螺丝刀(java.lang.Queue)。

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

我想你总是可以通过你自己的应用程序模块通过你自己的内部使用java.lang.Queues的类似消息传递的接口进行通信来推迟决定,但是如果你发现你的需要它。虽然在这里也要小心 - 尽早添加不必要的抽象有时会带来不值得的负担。