消息队列MQ开源产品比较
我花了一周的时间评估比较了一下各种消息队列产品，非常的有趣。我做这个事的动机是因为一个客户有一个很高性能需求。他们的消息信息突破了1百万个并发。目前他们使用的是SQL server，并不理想，我建议他们使用消息队列服务器。
为了对一些相似的候选产品获得一个全面的但是粗浅的性能上的了解，我们它们放在一起做了个测试。我让每个消息产品各发送和接受1百万千条1K的消 息。测试准备的有些仓促，我并没有修改任何的配置，只是快速的看了一下它们的安装文档，安装好每种软件，然后就让它们做这些最简单的收发信息的操作。所以 这是一次真正的“开箱即装即用”的性能表现。我完全理解，这对那些初始配置十分保守的消息队列产品将会是个惩罚
候选产品有：
MSMQ.
这是微软的产品里唯一被认为有价值的东西。对我的客户来说，如果MSMQ能证明可以应对这种任务，他们将选择使用它。关键是这个东西并不复杂，除了接收和 发送，没有别的；它有一些硬性限制，比如最大消息体积是4MB。然而，通过和一些像MassTransit 或 NServiceBus这样的软件的连接，它完全可以解决这些问题。
ActiveMQ.
Java世界的中坚力量。它有很长的历史，而且被广泛的使用。它还是跨平台的，给那些非微软平台的产品提供了一个天然的集成接入点。然而，它只有跑过了MSMQ才有可能被考虑。
RabbitMQ.
我听说了很多关于这个用Erlang写成的消息中间件的优秀的特性。它支持开放的高级消息队列协议 (AMQP，Advanced Message Queuing Protocol)，从根本上避免了生产厂商的封闭，使用任何语言的各种客户都可以从中受益。这种协议提供了相当复杂的消息传输模式，所以基本上不需要 MassTransit 或 NServiceBus 的配合。它还具有“企业级”的适应性和稳定性。这些东西对我的客户来说十分的有吸引力。
ZeroMQ.
我在研究AMQP时从发现了这个产品。开发这个产品的公司是AMQP集团的一部分，并且还有一个叫做OpenAMQ的产品。然而，他们却戏剧性的从AMQP分离的出去，并抱怨说这这个产品迷失了方向、变的越来越复杂。你可以到这里阅 读Dear John的关于此事的文章。ZeroMQ具有一个独特的非中间件的模式，也就是说，跟其它几个接受测试的产品不同，你不需要安装和运行一个消息服务器，或 中间件。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。非常有趣的是，他们也同样使用这 方式在任何利用ZeroMQ进行强大的进程内通信的语言里创建Erlang风格的这种执行角色。
把这四个MQ产品装上、跑起来是一个很有趣的工作。当你需要安装一个非Windows平台的产品时，下一定的功夫那是必须的。ActiveMQ需要 在目标机器上安装Java，RabbitMQ需要Erlang环境。安装这两个产品都没有遇到麻烦，但我想这是否给系统的维护增加了一层任务。如果这个中 的一个被选中，我需要让系统维护的人去理解和维护他们以前不熟悉的运行库。ActiveMQ，
RabbitMQ 和 MSMQ 都需要启动服务进程，这些都可以监控和配置，另外一个就有问题了。
ZeroMQ，它没有中间件架构，不需要任何服务进程和运行时。事实上，你的应用程序端点扮演了这个服务角色。这让部署起来非常简单，但担心的是， 你没有地方可以观察它是否有问题出现。就目前我知道的，ZeroMQ仅提供非持久性的队列。你可以在需要的地方实现自己的审计和数据恢复功能。老实说，我 甚至不确信是否该把它列在此次测试中，它的运行原理和其它几种差别太大了。
Message Queue
就像你看到的，ZeroMQ和其它的不是一个级别。它的性能惊人的高。公平的说，ZeroMQ跟其它几个比起来像头巨兽，尽管这样，结论很清楚：如果你希望一个应用程序发送消息越快越好，你选择ZeroMQ。当你不太在意偶然会丢失某些消息的情况下更有价值。
老实讲，我更希望使用Rabbit。但这种事情是应该做更多的测试，你最终会有一个最爱，我所听到的、读到的各种关于Rabbit的事情让我觉得它应该是最佳选择。但使用这个测试结果，我很难说服他们不去使用MSMQ。