消息队列软件产品大比拼(转)

转自：外刊IT评论

我花了一周的时间评估比较了一下各类消息队列产品，很是的有趣。我作这个事的动机是由于一个客户有一个很高性能需求。他们的消息信息突破了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仅提供非持久性的队列。你能够在须要的地方实现本身的审计和数据恢复功能。老实说，我甚至不确信是否该把它列在这次测试中，它的运行原理和其它几种差异太大了。

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

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

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

若是你想本身跑一下这些测试，个人测试代码都放在了GitHub上。我很感兴趣(但不是很是很是感兴趣)想知道如何优化这些测试，因此，若是你能作到一个更好的测试结果，请告诉我。谢谢。