我花了一周的时间评估比较了一下各种消息队列产品，非常的有趣。我做这个事的动机是因为一个客户有一个很高性能需求。他们的消息信息突破了1百万个并发。目前他们使用的是SQL server，并不理想，我建议他们使用消息队列服务器。

    为了对一些相似的候选产品获得一个全面的但是粗浅的性能上的了解，我们它们放在一起做了个测试。我让每个消息产品各发送和接受1百万千条1K的消息。测试准备的有些仓促，我并没有修改任何的配置，只是快速的看了一下它们的安装文档，安装好每种软件，然后就让它们做这些最简单的收发信息的操作。所以这是一次真正的“开箱即装即用”的性能表现。我完全理解，这对那些初始配置十分保守的消息队列产品将会是个惩罚。

    候选产品有：

    把这四个MQ产品装上、跑起来是一个很有趣的工作。当你需要安装一个非Windows平台的产品时，下一定的功夫那是必须的。ActiveMQ需要在目标机器上安装Java，RabbitMQ需要Erlang环境。安装这两个产品都没有遇到麻烦，但我想这是否给系统的维护增加了一层任务。如果这个中的一个被选中，我需要让系统维护的人去理解和维护他们以前不熟悉的运行库。ActiveMQ，

     RabbitMQ 和 MSMQ 都需要启动服务进程，这些都可以监控和配置，另外一个就有问题了。

    ZeroMQ，它没有中间件架构，不需要任何服务进程和运行时。事实上，你的应用程序端点扮演了这个服务角色。这让部署起来非常简单，但担心的是，你没有地方可以观察它是否有问题出现。就目前我知道的，ZeroMQ仅提供非持久性的队列。你可以在需要的地方实现自己的审计和数据恢复功能。老实说，我甚至不确信是否该把它列在此次测试中，它的运行原理和其它几种差别太大了。

    我就不瞎扯了，下面是测试结果。显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。

    就像你看到的，ZeroMQ和其它的不是一个级别。它的性能惊人的高。公平的说，ZeroMQ跟其它几个比起来像头巨兽，尽管这样，结论很清楚：如果你希望一个应用程序发送消息越快越好，你选择ZeroMQ。当你不太在意偶然会丢失某些消息的情况下更有价值。

    老实讲，我更希望使用Rabbit。但这种事情是应该做更多的测试，你最终会有一个最爱，我所听到的、读到的各种关于Rabbit的事情让我觉得它应该是最佳选择。但使用这个测试结果，我很难说服他们不去使用MSMQ。

    如果你想自己跑一下这些测试，我的测试代码都放在了GitHub上。我很感兴趣(但不是非常非常感兴趣)想知道如何优化这些测试，所以，如果你能做到一个更好的测试结果，请告诉我。谢谢。

建议继续学习：

1. 无锁消息队列    (阅读：12780)
2. Redis消息队列的若干实现方式    (阅读：10686)
3. 多线程队列的算法优化    (阅读：6497)
4. TSQ 的原理    (阅读：5931)
5. 使用django+celery+RabbitMQ实现异步执行    (阅读：5005)
6. Gearman Server 使用 MySQL UDFs 来管理和保持队列    (阅读：4856)
7. 终于把搜索更新改成基于MQ(Message Queue, 消息队列)的方式了    (阅读：3407)
8. 一些队列理论 吞吐量、延迟和带宽    (阅读：3253)
9. 无锁消息队列    (阅读：3196)
10. 浅析手机消息推送设计    (阅读：3218)