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