如果您想在Windows下使用排队产品进行持久消息传递，运行.NET 2.0及更高版本，那么今天存在哪些MSMQ替代品？我知道ActiveMQ（http://activemq.apache.org/），我看到了对WSMQ的引用（指向http://wsmq.net），但该网站似乎已关闭。
还有其他选择吗？
答案 0 :(得分：17)
可能不是这里的“最佳实践”建议......但是基于现实生活中的需求和经验： 我们有分布式系统，运行每10个客户端的60个盒子都执行任务X，他们需要从队列中接受下一个任务。队列正在从另一个“客户端”...
进行我们曾经使用过程间通信，我们使用了MSMQ，我们尝试过服务代理......从长远来看它只是不起作用，因为你将应用程序的控制权交给微软。只要您的需求得到满足，它就会很好用。当你需要一些不受支持的东西时，它会变成地狱。
我们的最佳解决方案是：使用SQL数据库表作为队列。不要在那里重新发明轮子，因为你会犯错误（锁）。有关于如何操作的信息，它非常简单，我们每24小时处理超过200K消息（60x10 = 600并发读取和写入队列）。除了处理其余应用程序内容的同一SQL服务器之外......
MSMQ不起作用的一些原因：
当您需要将队列的逻辑更改为非FIFO时，但是“最旧的RED消息”或“最早的BLUE消息”之类的内容时，您无法执行此操作。 （我知道人们会说什么，你可以通过红色队列和蓝色队列来实现..但是，如果队列的数量/类型是基于动态的，那该怎么办？在管理应用程序和每天更改的方式？）
它增加了一个故障点和部署噩梦（队列是一个失败的点，你需要处理在所有盒子上设置正确的权限来读取/写入消息等）你在血液中支付的企业软件对于这些类型的东西）。 SQL服务器...所有客户端都已经从DB中写入/读取，它只是一个表...
答案 1 :(得分：10)
我无法开始对Tibco EMS说出足够好的东西 - 这是Java JMS消息传递规范的一个实现。 Tibco EMS对.NET客户端提供了极好的支持 - 包括WinCE上的Compact Framework .NET。 （他们也有C客户端库。）
因此，如果您正在构建涉及在Windows，Unix（AIX / Solaris），Linux或Mac OS X上运行的消息传递代码的异构分布式应用程序，则可以使用Tibco EMS。
点击此处查看我的文章：
Using JMS For Distributed Software Development
我曾经在微软工作，并在那里与MSMQ做了一些实现。但是你知道，微软只关注Windows。他们依靠第三方为其他平台提供MSMQ客户端。我与Tibco EMS的相遇是一次更好的体验。很明显，Tibco比微软更了解消息。 Tibco致力于支持各种客户端绑定。这就是为什么他们最终将产品名称从Tibco JMS更改为Tibco EMS（企业消息服务）。
我确实围绕Tibco EMS构建了异构软件系统。滚动C＃.NET Winform客户端通过Tibco EMS消息传递与Java / JBoss中间层交互。 （还有使用Compact Framework .NET Tibco客户端的WinCE工业嵌入式计算机。）
答案 2 :(得分：9)
The RabbitMQ framework似乎在这里被忽视了。如果人们仍然关心，它确实有一个.NET 2.0代码库，它带有类似于netMsmqBinding的WCF绑定。绑定自然至少需要.NET 3.0，它具有比内置netMsmqBinding更多的功能。最重要的是，它是Mono友好的。值得一看。
答案 3 :(得分：7)
SQL 2005的service broker怎么样？
答案 4 :(得分：3)
如果费用不是问题（还有Express SKU ），那么看看800,000磅的大猩猩。 WebSphere MQ（MQ系列）。它几乎可以在任何平台上运行，并支持许多不同的队列管理器和消息传递模式，因此在这里列出它们是不合适的。
答案 5 :(得分：3)
为什么不使用ActiveMQ？ ：）
答案 6 :(得分：1)
如果高可用性很重要，亚马逊SQS值得关注。如果消息来自不同的物理位置，则没有太多额外的开销。便宜又可扩展！
答案 7 :(得分：1)
Redis是这个平台上的另一个热门品种。检查基于Set的排队实现以及Pub / Sub模式。看起来很有希望