为什么选择 ActiveMQ，而不是简单的队列/互斥体？
明天我将介绍选择进程内消息队列实现的理由，但我无法阐明我的理由。 我的合作设计师建议我们仅使用基本的作业列表和互斥体来控制访问来实现一个简单的异步队列，我建议在嵌入式模式下使用 ActiveMQ。 我个人对 ActiveMQ 印象非常深刻，我希望有一些好的、可靠的论据来支持我的直觉印象。
如果重要的话，应用程序基本上是 1 个生产者/n 个消费者，具有特定于正在处理的各个作业的优先级和类型信息。
值得注意的是，到目前为止，该解决方案的可管理性和可扩展性还没有成为有力的论据。 如果有人能给我的论点更有说服力，我会很高兴。 论坛可以帮我解决一下吗？
Tomorrow I am presenting my rationale for choosing an in-process message queue implementation, and I'm unable to articulate my reasoning. My co-designers are proposing that we implement a simple asynchronous queue using just a basic list of jobs and a mutex to control access, where I'm suggesting ActiveMQ in embedded mode. I've personally been very impressed by ActiveMQ, and I would like to have some good, solid arguments to back up my gut impression.
If it matters, the application is basically 1 producer/n consumers, with priority and type information specific to the individual jobs being processed.
It's worth noting that so far the manageability and extensibility of the solution have not been powerful arguments. I'd love it if someone could give my arguments more punch. Can the forum help me out with that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你同事的论点并非没有道理。 将 ActiveMQ 添加到项目中就是添加另一个依赖项。 它的使用可能会更复杂，并且比定制解决方案占用的空间更大。 此外，既然您正在采用它，那么维护和保持工作顺利（错误等）很可能将成为您的责任。
也就是说，ActiveMQ（和其他队列）会做一些您可以自己编写的事情，但可能会很痛苦。 支持整个 JMS API 就是其中之一（尽管我假设您正在使用 Java...如果您没有使用 Java，那么这一点是无效的）。 在内存较高的情况下将多余的消息序列化到磁盘是另一种方法。 持久订阅者和消息选择器是我想到的其他一些事情。 看起来大多数都是花里胡哨的东西来满足您的需求，但它们对于可靠的消息传递变得非常重要。
无论您做出什么决定，都请将消息代理的最终选择封装在客户端代码之外，以便更轻松地进行切换。
Your coworkers arguments are not without merit. Adding ActiveMQ to the project is adding yet another dependency. It will probably be more complicated to use, and it will have a greater footprint than a custom solution. Also, since you are adopting it, it is likely going to become your responsibility to maintain and keep working smoothly - bugs and all.
That said, ActiveMQ (and other queues) will do things that you could write yourself, but might prove to be a pain. Supporting the entire JMS API is one of them (though I am presuming you are using Java...if you are not, then this point is not valid). Serializing excess messages to disk in high memory situations is another. Durable subscribers and message selectors are a few other things that come to mind. Mostly bells-and-whistles sort of thing for your needs it seems, but they become very important for reliable message delivery.
Whatever you decide, encapsulate the final choice of message broker away from the client code to make it easier to switch.
如果可管理性和可扩展性不是高优先级，那么我想知道您想要使用可管理消息队列的原因是什么？ 也许您的同事是对的，您真的不需要额外的功能集？
If manageability and extensibility are not high priorities then I have to wonder what your reasons are for wanting to use a manageable message queue? Maybe your colleagues are right, and you really don't need the extra feature set?
不必在奇怪的边缘情况下调试并发代码是一个很大的好处。 我不知道这个结构作为您整个项目的一部分有多重要，但是如果消息队列是您项目的重要组成部分，那么您可以通过使用其他人的实现来获得巨大的好处已经写好了，已经调试好，将为您维护。 如果它只是一个不重要子系统的一次性部分，那么您最终做什么可能并不重要。 但如果它很关键，我宁愿提交错误报告，也不愿花时间调试并发代码（我已经开始害怕了！）。
简而言之：不要让 NIH 综合症阻止您利用别人的工作来更快、更好、更便宜地完成您的工作。 但也不要小题大做。
Not having to debug concurrency code in weird edge cases is a big benefit. I don't know how important this structure is as part of your overall project, but if the message queue is a big part of your project, then you can reap tremendous benefits by using an implementation that someone else has written, already debugged, and will maintain for you. If it's just some one-off part of an unimportant subsystem, it probably doesn't matter what you end up doing. But if it's critical, I'd much rather file a bug report than spend my time debugging concurrency code (I'm already starting to recoil in fear!).
The short version: Don't let NIH syndrome stop you from using someone else's work to get your job done faster, better, and cheaper. But don't build a mountain out of a molehill, either.