多播、消息传递、ActiveMQ 对比MSMQ？

Question

我正在为我们的产品开发消息/通知系统。基本要求是：

• 火灾后忘记
• 一组持久的消息，可能会更新，保留在那里，直到发件人说删除它们

这些库将用 C# 编写。Spring.NET 刚刚发布了一个里程碑构建，其中包含许多不错的消息传递抽象，这非常棒 - 我计划广泛使用它。我的基本问题归结为消息代理的问题。我的架构看起来像应用程序 -> 消息代理队列 -> 服务器应用程序，用于侦听，将所有消息分派到它们需要去的地方，并处理这些长期消息的生命周期 -> 消息代理队列或主题 -> 侦听应用。

最后，问题：我应该使用哪个消息代理？我偏向于 ActiveMQ - 我们在上一个项目中使用了它并且很喜欢它。我真的想不出对它的任何攻击，除了它是 Java，并且需要将 java 安装在服务器上的某个地方，这对于一些将使用该服务的人来说可能很难推销。我一直在考虑的另一个选择是 MSMQ。由于某种未知的原因，我对它有偏见，而且它似乎也没有很好的多播支持。

有人用 MSMQ 做过类似的事情吗？有什么优点或缺点，或者可能以某种方式影响投票的东西吗？

最后一件事，我们正在使用 .NET 2.0。

Answer 1

我在工作时有点偏见 ActiveMQ 但几乎上面列出的 MSMQ 的所有优点也确实适用于 ActiveMQ。

ActiveMQ 的更多好处包括

• 大力支持 跨语言客户端访问和多协议支持
• 极好的支持 企业集成模式
• 一吨 高级功能 喜欢 独占队列 和 消息组

您提到的主要缺点是 ActiveMQ 代理是用 Java 编写的；但如果您确实需要，您可以在 IKVM 上将其作为 .net 程序集运行，或者将其作为 Windows 服务运行，或者通过 GCJ 将其编译为 DLL/EXE。MSMQ 可能是也可能不是用 .NET 编写的 - 但它的实现方式并不重要，对吗？

无论您选择 MSMQ 还是 ActiveMQ，我都建议至少考虑使用 网管接口 正如你所说，它很好地集成到了 Spring.NET 中。该 API 有一个 MSMQ 实现，以及 TibCo、ActiveMQ 和 STOMP 的实现，它们将通过以下方式支持任何其他 JMS 提供程序： Stomp连接.

因此，通过选择 NMS 作为您的 API，您将避免锁定任何专有技术 - 然后您可以随时轻松切换消息传递提供商；而不是将您的代码全部锁定到专有 API 中

Answer 2

MSMQ 的优点。

• 它内置于 Windows 中
• 支持事务，也支持无事务的队列
• 设置非常简单
• 广告集成
• 它很快，但您需要比较 ActiveMQ 和 MSMQ 的流量才能知道哪个更快。
• .NET 支持它的诞生
• 支持即发即忘
• 如果您有只是看一眼的读者，您可以查看队列。不确定是否可以编辑队列中的消息。

缺点：

• 4MB消息大小限制
• 2GB 队列大小限制
• 队列项目保存在磁盘上
• 不是主流的微软产品，文档有点不确定，或者是我已经有几年没有使用它了。

这是一个很好的博客 消息队列

Answer 3

看一眼 零MQ. 。它是最快的消息队列之一。

Answer 4

我建议您查看 TIBCO Enterprise Messaging Service - EMS，这是一种高性能消息传递产品，支持多播、路由、支持 JMS 规范并提供企业范围的功能，包括您的需求，例如使用文件/数据库的即发即忘和消息持久化共享状态。

作为参考，FedEx在TIBCO EMS上作为其消息基础结构运行。

http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp

如果我提供很多其他参考资料，你真的会感到惊讶。

Answer 5

在这个领域有很多选择......

自由的：MantaRay 是一个完全符合 JMS 的点对点系统。Mantaray 有趣的部分是，您只需要定义消息的去向，MantaRay 无论如何都会路由它，将您的消息发送到它的目的地 - 因此它更能抵抗消息传递结构中各个节点的故障。

有薪酬的：在我的日常工作中，我管理一个具有数百个节点的 IBM WebSphere MQ 消息传递系统，并发现它非常好。我们最近还购买了Tibco EMS，看起来用起来也不错。

保罗/