为什么使用ActiveMQ，而不是简单的Queue / Mutex？

Question

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

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

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

Answer 1

你的同事的论点并非毫无根据。将ActiveMQ添加到项目中又添加了另一个依赖项。使用它可能会更复杂，并且它将比自定义解决方案具有更大的占用空间。此外，由于您正在采用它，因此维护并保持顺利运行可能会成为您的责任 - 错误和所有。

也就是说，ActiveMQ（以及其他队列）会做你自己写的东西，但可能会很痛苦。支持整个JMS API就是其中之一（虽然我假设您使用的是Java ...如果不是，那么这一点无效）。在高内存情况下将多余的消息序列化到磁盘是另一种情况。持久订阅者和消息选择器是我想到的其他一些事情。大多数钟声和口哨似乎都符合您的需求，但它们对于可靠的消息传递非常重要。

无论您做出什么决定，都要将最终选择的消息代理从客户端代码中分离出来，以便更容易切换。

Answer 2

如果可管理性和可扩展性不是高优先级那么我不得不想知道你想要使用可管理的消息队列的原因是什么？也许你的同事是对的，你真的不需要额外的功能集吗？

Answer 3

不必在奇怪的边缘情况下调试并发代码是一个很大的好处。我不知道这个结构作为整个项目的一部分有多重要，但如果消息队列是项目的重要组成部分，那么你可以通过使用别人的实现来获得巨大的好处已编写，已经调试过，并将为您维护。如果它只是一个不重要的子系统的一次性部分，那么你最终做什么并不重要。但是，如果它很关键，我宁愿提交错误报告，而不是花时间调试并发代码（我已经开始恐惧了！）。

简短版本：不要让NIH综合症阻止您使用其他人的工作来更快，更好，更便宜地完成工作。但是，也不要用小山丘建造一座山。