消息队列中间件的技术选型分析

【http://cloudate.net/?p=1165】2015/04/25  |  消息队列 |  罗伯特

消息队列中间件是互联网行业不可或缺的一项基本技术，在高并发消峰，非关键业务异步化，通知系统，监控数据推送等场景下是必不可少的，下文为转载文章，具体出处不详。

我的很喜欢ZeroMQ，非企业级的消息中间件，具备及低延迟-微秒级，使用简单灵活可嵌入等特性，性能报告请参考官网：
http://zeromq.org/results:more-precise-0mq-tests

消息中间件是一种由消息传送机制或消息队列模式组成的中间件技术，利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通讯来进行分布式系统的集成。目前业界有不少的MQ产品，像RabbitMQ、ActiveMQ、ZeroMQ等都是极好的消息中间件，可是咱们在项目中该选择哪一个更适合呢？本文针对如下几种消息队列产品做了评估比较：RabbitMQ、ZeroMQ、ActiveMQ、MSMQ、Redis、memcacheQ

题外话：这里咱们能够先思考个小问题“Web应用中为何会须要消息队列服务？”
在高并发环境下，因为来不及同步处理，请求每每会发生堵塞(主要缘由)，好比说，大量的insert，update之类的请求同时到达mysql，直接致使无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。经过使用消息队列，咱们能够异步处理请求，从而缓解系统的压力。

RabbitMQ
是使用Erlang编写的一个开源的消息队列，自己支持不少的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的很是重量级，更适合于企业级的开发。是AMQP协议领先的一个实现，它实现了代理(Broker)架构，意味着消息在发送到客户端以前能够在中央节点上排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。此特性使得RabbitMQ易于使用和部署，适宜于不少场景如路由、负载均衡或消息持久化等，用消息队列只需几行代码便可搞定。可是，这使得它的可扩展性差，速度较慢，由于中央节点增长了延迟，消息封装后也比较大。如需配置RabbitMQ则须要在目标机器上安装Erlang环境。

ØMQ(ZeroMQ)
号称最快的消息队列系统，尤为针对大吞吐量的需求场景。是一个很是轻量级的消息系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中常常能够发现它。与RabbitMQ相比，ZeroMQ支持许多高级消息场景，可是你必须实现ZeroMQ框架中的各个块（好比Socket或Device等）。

ØMQ(ZeroMQ)可以实现RabbitMQ不擅长的高级/复杂的队列，可是开发人员须要本身组合多种技术框架，技术上的复杂度是对这MQ可以应用成功的挑战。ZeroMQ具备一个独特的非中间件的模式，你不须要安装和运行一个消息服务器或中间件，由于你的应用程序将扮演了这个服务角色。你只须要简单的引用ZeroMQ程序库，可使用NuGet安装，而后你就能够愉快的在应用程序之间发送消息了。可是ZeroMQ仅提供非持久性的队列，也就是说若是down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ做为数据流的传输。ZeroMQ很是灵活，可是你必须学习它的80页的手册（若是你要写一个分布式系统，必定要阅读它）。

ZeroMQ没有中间件架构，不须要任何服务进程和运行。事实上，你的应用程序端点扮演了这个服务角色。这让部署起来很是简单，但担忧的是，你没有地方能够观察它是否有问题出现。就目前了解到的，ZeroMQ仅提供非持久性的队列。你能够在须要的地方实现本身的审计和数据恢复功能。MSMQ
这是微软的产品里惟一被认为有价值的东西。若是MSMQ能证实能够应对这种任务，他们将选择使用它。关键是这个东西并不复杂，除了接收和发送，没有别的；它有一些硬性限制，好比最大消息体积是4MB。然而，经过和一些像MassTransit 或 NServiceBus这样的软件的链接，它彻底能够解决这些问题。

Jafka/Kafka
kafka（能将消息分散到不一样的节点上）是LinkedIn于2010年12月开发并开源的一个分布式MQ系统，如今是Apache的一个孵化项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具备如下特性：快速持久化，能够在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既能够达到10W/s的吞吐速率；彻底的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的同样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka经过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个很是轻量级的消息系统，除了性能很是好以外，仍是一个工做良好的分布式系统。

Apache ActiveMQ
ActiveMQ居于二者(RabbitMQ & ZeroMQ)之间，相似于ZemoMQ，它能够部署于代理模式和P2P模式。相似于RabbitMQ，它易于实现高级场景，并且只需付出低消耗。
ActiveMQ被誉为Java世界的中坚力量。它有很长的历史，并且被普遍的使用。它仍是跨平台的，给那些非微软平台的产品提供了一个自然的集成接入点。然而，它只有跑过了MSMQ才有可能被考虑。如需配置ActiveMQ则须要在目标机器上安装Java环境。

 

须要注意一点的是ActiveMQ的下一代产品为Apollo，Apollo以ActiveMQ原型为基础，是一个更快、更可靠、更易于维护的消息代理工具。Apache称Apollo为最快、最强健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息协议）服务器。
Apollo的特性以下：
支持Stomp 1.0和Stomp 1.1协议
主题和队列
队列浏览器
主题持久订阅
镜像队列
可靠的消息传递
消息过时和交换
消息选择器
JAAS验证
基于ACL的受权
支持SSL/TLS，证书验证
REST Management API

 

Redis
是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它自己支持MQ功能，因此彻底能够当作一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操做，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不一样大小的数据。实验代表：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而若是数据大小超过了10K，Redis则慢的没法忍受；出队时，不管数据大小，Redis都表现出很是好的性能，而RabbitMQ的出队性能则远低于Redis。

MemcacheQ
持久化消息队列memcacheq(简称mcq)是一个轻量级的消息队列，MemcacheQ的特性：
1 简单易用
2 处理速度快
3 多条队列
4 并发性能好
5 与memcache的协议兼容。这就意味着只要装了memcache的extension就能够了，不须要额外的插件。
6 在zend framework中使用也很方便。

---

最终，这几个产品：
1. 都有各自客户端API或支持多种编程语言；
2. 都有大量的文档；
3. 都提供了积极的支持。
4. ActiveMQ、RabbitMQ、MSMQ、Redis都须要启动服务进程，这些均可以监控和配置，其余几个就有问题了
5. 都相对提供了良好的可靠性(一致性)、扩展性和负载均衡，固然还有性能

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

就像你看到的，ZeroMQ和其它的不是一个级别。它的性能惊人的高。尽管这样，但这个产品不提供消息持久化、没法方便存储及监控中间过程，须要本身实现审计和数据恢复，所以在易用性和HA上不是使人满意。结论很清楚：若是你但愿一个应用程序发送消息越快越好，你选择ZeroMQ。当你不太在乎偶然会丢失某些消息的状况下更有价值。

本文博主将来往事更但愿(也不是很但愿很但愿)选择使用的是Rabbit，Rabbitmq内置了ha，若是组建cluster，负载均衡之类的问题就无需担心了同时能够设置队列镜像。但这种事情是应该作更多的测试，你最终会有一个最爱，我所听到的、读到的各类关于Rabbit的事情让我以为它应该是最佳选择。

其余一些队列列表，这里就再也不一一分析，若是须要了解更多可自行google。