如果您想在运行 .NET 2.0 及更高版本的 Windows 下使用队列产品来实现持久消息传递,目前有哪些 MSMQ 替代方案?我知道 ActiveMQ(http://activemq.apache.org/),并且我看到了对 WSMQ 的引用(指向 http://wsmq.net),但该网站似乎已关闭。

还有其他选择吗?

有帮助吗?

解决方案

我对 Tibco EMS(Java JMS 消息传递规范的实现)赞不绝口。Tibco EMS 对 .NET 客户端提供出色的支持 - 包括 WinCE 上的 Compact Framework .NET。(他们也有 C 客户端库。)

因此,如果您正在构建涉及在 Windows、Unix (AIX/Solaris)、Linux 或 Mac OS X 上运行的消息传递代码的异构分布式应用程序,那么 Tibco EMS 就是您的最佳选择。

在这里查看我的文章:

使用 JMS 进行分布式软件开发

我曾经在 Microsoft 工作,并在那里使用 MSMQ 进行了一些实现。但你知道,微软只关心Windows。他们依靠第三方向其他平台提供 MSMQ 客户端。我与 Tibco EMS 的相遇是一次更好的经历。很明显,Tibco 比 Microsoft 更了解消息传递。Tibco 也致力于支持不同的客户端绑定本身。这就是为什么他们最终将产品名称从 Tibco JMS 更改为 Tibco EMS(企业消息服务)。

我确实围绕 Tibco EMS 构建了异构软件系统。滚动的 C# .NET Winform 客户端通过 Tibco EMS 消息传递与 Java/JBoss 中间层交互。(还有使用 Compact Framework .NET Tibco 客户端的 WinCE 工业嵌入式计算机。)

我的 JMS 著作链接

其他提示

这里可能不是“最佳实践”建议......但基于现实生活的需要和经验:我们有分布式系统,60 个盒子运行,每 10 个客户端都执行任务 X,并且它们需要从队列中取出下一个任务。队列正在从另一个“客户端”提供......

我们使用了进程间通信,我们使用了 MSMQ,我们尝试了服务代理......从长远来看,它是行不通的,因为您将应用程序的控制权交给了 Microsoft。只要满足您的需求,它就可以很好地发挥作用。当你需要一些不受支持的东西时,它就会变成地狱。

对我们来说最好的解决方案是:使用 SQL 数据库表作为队列。不要在那里重新发明轮子,因为你会犯错误(锁)。有关于如何做到这一点的信息,这非常简单,我们每 24 小时处理超过 200K 消息(60x10 = 600 个并发读取和写入队列)。这是除了处理其余应用程序内容的同一 SQL 服务器之外......

MSMQ 不起作用的一些原因:

  1. 当您需要将队列的逻辑更改为不是 FIFO,而是“最旧的红色消息”或“最旧的蓝色消息”之类的逻辑时,您无法做到这一点。(我知道人们会说什么,你可以通过 红色队列 和一个 蓝色队列..但是,如果队列的数量/类型根据应用程序的管理方式是动态的并且每天都在变化,该怎么办?)

  2. 它增加了一个故障点和部署噩梦(队列是一个故障点,您需要在所有盒子上设置正确的权限来读取/写入消息等,在企业软件中,您为这些类型的事情付出了血汗钱) 。SQL 服务器...所有客户端都已经从数据库中写入/读取,这只是又一张表..

RabbitMQ 框架 这里似乎被忽视了。如果人们仍然关心的话,它确实有一个 .NET 2.0 代码库,并且带有类似于 netMsmqBinding 的 WCF 绑定。该绑定自然至少需要.NET 3.0,并且它比内置的netMsmqBinding具有更多功能。最重要的是,它对 Mono 友好。值得一看。

SQL 2005 怎么样? 服务经纪人?

为什么不使用ActiveMQ?:)

如果成本不是问题(还有 Express SKU)然后看看80万磅重的大猩猩。WebSphere MQ(MQ 系列)。它几乎可以在任何平台上运行,并支持如此多不同的队列管理器和消息传递模式,因此实际上不适合在此处列出它们。

如果高可用性很重要,那么 Amazon SQS 值得关注。如果消息来自不同的物理位置,则不会有太多额外开销。便宜且可扩展!

Redis 是这个平台上的另一个热门品种。检查他们基于 Set 的队列实现以及 Pub/Sub 模式。看起来很有前途

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top