message-queue - 为什么是 ActiveMQ，而不是简单的 Queue/Mutex？

Question

明天我将介绍我选择进程内消息队列实现的基本原理，但我无法阐明我的推理。我的合作设计者提议我们实现一个简单的异步队列，只使用基本的作业列表和互斥锁来控制访问，我建议在嵌入式模式下使用 ActiveMQ。我个人对 ActiveMQ 印象非常深刻，我希望有一些好的、可靠的论据来支持我的直觉。

如果重要的话，应用程序基本上是 1 个生产者/n 个消费者，具有特定于正在处理的单个作业的优先级和类型信息。

值得注意的是，到目前为止，该解决方案的可管理性和可扩展性并不是强有力的论据。如果有人能给我的论点更多的冲击，我会很高兴的。论坛能帮我解决这个问题吗？

Answer 1

你同事的论点并非没有道理。将 ActiveMQ 添加到项目是添加另一个依赖项。使用起来可能会更复杂，并且比自定义解决方案占用空间更大。此外，由于您正在采用它，因此维护和保持顺利工作很可能成为您的责任 - 错误等等。

也就是说，ActiveMQ(和其他队列)会做一些你可以自己编写的事情，但可能会很痛苦。支持整个 JMS API 就是其中之一(尽管我假设您正在使用 Java...如果您不是，那么这一点是无效的)。在高内存情况下将多余的消息序列化到磁盘是另一个问题。持久订阅者和消息选择器是其他一些想到的东西。看起来主要是花里胡哨的东西，但它们对于可靠的消息传递变得非常重要。

无论您做出什么决定，都将消息代理的最终选择从客户端代码中封装起来，以便于切换。