明天我将介绍我选择进程内消息队列实现的理由，但我无法阐明我的理由。我的共同设计者建议我们实现一个简单的异步队列，只使用一个基本的作业列表和一个互斥体来控制访问，我建议在嵌入式模式下使用 ActiveMQ。 ActiveMQ 给我个人留下了深刻的印象，我希望有一些好的、可靠的论据来支持我的直觉。
如果重要的话，应用程序基本上是 1 个生产者/n 个消费者，具有特定于正在处理的各个作业的优先级和类型信息。
值得注意的是，到目前为止，解决方案的可管理性和可扩展性还没有成为强有力的论据。如果有人可以让我的论点更有力，我会很高兴。论坛可以帮我解决这个问题吗？
【问题讨论】：
如果可管理性和可扩展性不是高优先级，那么我想知道您想要使用可管理消息队列的原因是什么？也许您的同事是对的，您真的不需要额外的功能集？
【讨论】：
不必在奇怪的边缘情况下调试并发代码是一个很大的好处。我不知道这个结构作为您整个项目的一部分有多重要，但如果消息队列是您项目的重要组成部分，那么您可以通过使用其他人的实现来获得巨大的好处已编写，已调试，并将为您维护。如果它只是一个不重要的子系统的某个一次性部分，那么你最终会做什么可能并不重要。但如果它很关键，我宁愿提交错误报告也不愿花时间调试并发代码（我已经开始害怕退缩了！）。
简短版本：不要让 NIH 综合症阻止您使用他人的工作来更快、更好、更便宜地完成工作。但是，也不要从鼹鼠丘中建造一座山。
【讨论】：
你同事的论点并非没有道理。将 ActiveMQ 添加到项目中会添加另一个依赖项。它的使用可能会更复杂，并且比定制解决方案占用的空间更大。此外，由于您正在采用它，因此维护和保持平稳运行可能会成为您的责任 - 错误等等。
也就是说，ActiveMQ（和其他队列）会做一些您可以自己编写的事情，但可能会很痛苦。支持整个 JMS API 就是其中之一（尽管我假设您使用的是 Java……如果您不是，那么这一点是无效的）。在高内存情况下将多余的消息序列化到磁盘是另一种方法。持久订阅者和消息选择器是我想到的其他一些事情。看起来大部分都是花里胡哨的东西来满足您的需求，但它们对于可靠的消息传递变得非常重要。
无论您决定什么，将消息代理的最终选择封装在远离客户端代码的地方，以便于切换。
【讨论】：