http://techlog.cn/article/list/10182733
http://www.cnblogs.com/my_life/articles/5132429.html
MQ(Message Queue)，即消息队列，一般用于应用系统解耦、消息异步分发，能够提高系统吞吐量
MQ 的产品很多，ZeroMQ、RabbitMQ、ActiveMQ、Kafka/Jafka、Kestrel、Beanstalkd、HornetQ、Apache Qpid、Sparrow、Starling、Amazon SQS、MSMQ 等，甚至 Redis 也集成了一个小型消息队列
由于不同的业务需求，可以进行不同的选择
题外话：这里我们可以先思考个小问题“Web应用中为什么会需要消息队列服务？”
在高并发环境下，由于来不及同步处理，请求往往会发生堵塞(主要原因)，比如说，大量的insert，update之类的请求同时到达mysql，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。
RabbitMQ
RabbitMQ 是一个使用 Erlang 编写的开源消息队列，本身支持很多协议：AMQP，XMPP, SMTP, STOMP
是一个非常重量级的消息队列，是和用于企业级开发
同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队
对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持
同时集成了一个小型 webserver，可以在浏览器中监控和调整队列的运转状态
具有普通模式和镜像模式两种模式
普通模式
如图所示，普通模式中消息实体只存在于 A、B 两个服务器上的某一个节点上，但是对于队列结构来说，A、B 两节点具有相同元数据
当客户端向服务器 A 请求消息实体在 B 节点上的元数据时，通过网络通信，B 将该消息实体同步到 A 节点
这样的模式由于节点间通信，导致性能下降明显
如果未配置消息持久化，则如果某一台机器出现问题，后果将不堪设想，而如果配置了消息持久化，则当某一台机器出现问题，整个系统会等待直到其回复工作为之
这种模式对于工程化应用来说，显然是不可接受的
镜像模式
即 RabbitMQ 的 HA 方案，每一份数据存在于多个节点，镜像备份
这样做保证了数据的可持久化，实现了高可靠性
但是，其缺点也是显而易见的，当有大量消息进入队列时，集群内部会产生大量的网络通信用于备份，同时，也会占用大量的磁盘IO，从而使对外提供的 IO 性能下降
虽然实现了很高的可靠性，但是同时大量读写的场景下，性能下降非常明显
Redis
Redis 本身是一个 KV 的 NoSQL 数据库，但是他也集成了 MQ 的功能，所以可以被当做一个轻量级队列服务使用
实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受
出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis
所以 Redis 适合用于小数据的消息队列服务
ZeroMQ
ZeroMQ 号称最快的消息队列，是一个类似于 socket 的网络通讯队列，不具备数据持久化功能
但是他可以实现复杂的多对多通讯功能，是一个简单好用的传输层，可以被用于分布式通信，也可以被用于进程间通信库
但是它不提供消息持久化、无法方便存储及监控中间过程，需要自己实现审计和数据恢复，因此在易用性和HA上不是令人满意
twitter 的 Stom 中使用 ZeroMQ 作为数据流的传输
Gearman
Gearman 是一个专门用于任务分发的消息队列，任务可以分为前台同步任务和后台异步任务
提供了任务的持久化机制，使用简单方便
ActiveMQ
ActiveMQ 是 Apache 下的一个开源子项目
用于帮助实现高可用、高性能、可伸缩、易用和安全的企业级面向消息服务的系统
保证消息的可靠异步传输，常常作为消息中间件使用
但是只能用作点对点传输
MemcacheQ
持久化消息队列memcacheq(简称mcq)是一个轻量级的消息队列
Kafka/Jafka
Kafka 是 Apache 下的一个子项目，Jafka 是在 Kafka 之上孵化而来的
支持快速持久化，可在 O(1) 的系统开销下进行数据持久化工作
高吞吐，在一台普通服务器上即可达到 10W/s 的吞吐率
自动实现复杂的分布式负载均衡
作为一个非常轻量级的消息队列系统，不仅支持消息的持久化缓存，同时具有非常好的性能，还是一个良好的分布式系统
下面附上一组从网上截取的测试结果。显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista单机上进行的。
就像你看到的，ZeroMQ和其它的不是一个级别。它的性能惊人的高。尽管这样，但这个产品不提供消息持久化、无法方便存储及监控中间过程，需要自己实现审计和数据恢复，因此在易用性和HA上不是令人满意。
结论很清楚：如果你希望一个应用程序发送消息越快越好，你选择ZeroMQ。当你不太在意偶然会丢失某些消息的情况下更有价值。
本文博主更希望(也不是很希望很希望)选择使用的是Rabbit，Rabbitmq内置了ha，如果组建cluster，负载均衡之类的问题就无需担忧了同时可以设置队列镜像。但这种事情是应该做更多的测试，你最终会有一个最爱，我所听到的、读到的各种关于Rabbit的事情让我觉得它应该是最佳选择。
对于这些消息队列的产品，每一种都在某一领域占有一席，虽然ActiveMQ目前在社区已经不是很活跃，但是其下一代产品Apollo已经问世。ZeroMQ小而美，RabbitMQ大而稳，Kakfa和RocketMQ快而强劲。RocketMQ虽然目前还很多不完善，但是一旦在Apache孵化成为*项目，全球程序猿开始贡献，前途也是不可限量的。
===========
http://www.ihowandwhy.com/z/RabbitMQ,ZeroMQ,Kafka%E6%98%AF%E4%B8%80%E4%B8%AA%E5%B1%82%E7%BA%A7%E7%9A%84%E4%B8%9C%E8%A5%BF%E5%90%97%EF%BC%8C%E7%9B%B8%E4%BA%92%E4%B9%8B%E9%97%B4%E6%9C%89%E5%93%AA%E4%BA%9B%E4%BC%98%E7%BC%BA%E7%82%B9%EF%BC%9F