22

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

  • 开火并忘记
  • 持久的消息集，可能会更新，直到发件人说删除它们

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

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

有没有人用过 MSMQ 做这样的事情？任何优点或缺点，可能会以某种方式影响投票的东西？

最后一件事，我们使用的是 .NET 2.0。

4

5 回答 5

22

我在处理ActiveMQ时有点偏见，但上面为 MSMQ 列出的几乎所有好处也确实适用于 ActiveMQ。

ActiveMQ 的其他一些好处包括

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

无论您选择 MSMQ 还是 ActiveMQ，我都建议您至少考虑使用NMS API，正如您所说，它已很好地集成到 Spring.NET 中。这个 API 有一个 MSMQ 实现，以及 TibCo、ActiveMQ 和 STOMP 的实现，它们将通过StompConnect支持任何其他 JMS 提供程序。

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

于 2008-09-16T14:00:06.540 回答
13

MSMQ 的优点。

  • 它内置在 Windows 中
  • 它支持事务，它还支持没有事务的队列
  • 设置起来真的很容易
  • 广告整合
  • 它很快，但您需要比较 ActiveMQ 和 MSMQ 以了解您的流量哪个更快。
  • .NET 支持它的诞生
  • 支持火与忘记
  • 如果您有只看的读者，您可以偷看队列。不确定您是否可以编辑队列中的消息。

缺点：

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

这是一个很好的MSMQ博客

于 2008-08-28T19:30:44.217 回答
7

看看zeromq。它是最快的消息队列之一。

于 2008-10-22T21:52:44.210 回答
3

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

作为参考，FEDEX 在 TIBCO EMS 作为其消息传递基础设施上运行。

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

如果我提供很多其他参考资料，您会感到非常惊讶。

于 2008-10-04T01:13:08.757 回答
3

在那个舞台上有很多选择......

免费：MantaRay 一个完全符合 JMS 的对等系统。Mantaray 的有趣之处在于，您只需要定义消息的去向，并且 MantaRay 无论如何都会将消息路由到它的目的地——因此它更能抵抗消息结构中单个节点的故障。

付费：在我的日常工作中，我管理一个具有数百个节点的 IBM WebSphere MQ 消息传递系统，并且发现它非常好。我们最近还购买了 Tibco EMS，它似乎也很好用。

保罗/

于 2008-10-22T21:41:22.920 回答