消息队列总结
消息队列的优点：
- 实现系统解耦
- 实现异步调用
- 流量削峰
消息队列的缺点：
- 系统可用性降低
- 提升系统的复杂度
- 数据一致性问题
Kafka
Apache Kafka 是一个分布式消息发布订阅系统。它最初是由LinkedIn公司基于独特的设计实现为一个分布式的日志提交系统，之后成为Apache项目的一部分。Kafka性能高效、可扩展良好并且可持久化。他的分区特性，可复制和可容错都是其不错的特性
- 优点：
- 客户端语言丰富：支持Java、.Net、PHP、Ruby、Python、Go等多种语言
- 高性能：单机写入TPS在100W条每秒，消息大小十个字节；
- 提供完全分布式架构，具有replica机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积；
- 消费者采用pull方式获取消息。消息有序，通过控制能够保证所有消息被消费且仅被消费一次
- 在日志领域比较成熟，被多家公司和多个开源项目使用，有管理界面Kafka-Manager
- 缺点
- kafka单机超过64个队列/分区时，Load会发生明显的飙高现象。队列越多，负载越高，发送消息响应时间变长
- 使用短轮询方式，实时性取决于轮询间隔时间
- 消费失败不支持重试
- 社区更新较慢
RocketMQ
RocketMQ出自阿里的开源产品，用Java语言实现，在设计时参考了Kafka，并做出了自己的一些改进，消息可靠性上比Kafka更好。RocketMQ在阿里内部被广泛应用在订单，交易，流计算，消息推送，日志流式处理，binlog分发等场景。
- 优点
- 单机支持1W以上持久化队列
- RocketMQ的所有消息都是持久化的，先写入系统Page Cache，然后刷盘，可以保证内存和磁盘都有一些数据，而访问时，直接从内存获取
- 模型简单，接口易用(JMS的接口很多场合不太适用）
- 性能非常好，可以允许大量堆积消息在Broker中
- 支持多种消费模式，包括集群消费、广播消费等
- 各个环节分布式扩展设计，支持主从和高可用；开发度较活跃，版本更新很快
- 缺点
- 支持的客户端语言不多，目前是Java及C++，其中C++还不成熟
- RocketMQ社区关注度及成熟度也不及Kafka
- 没有Web管理界面，提供了一个CLI界面（命令行界面）管理工具带来查询、管理和诊断各种问题
- 没有在MQ核心中实现JMS接口
RabbitMQ
RabbitMQ与2007年发布，是一个在AMQP（高级消息队列协议）基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。它提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；灵活的路由。消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。
- 优点
- 由于Erlang语言的特性，消息队列性能很好，支持高并发；
- 健壮、稳定、易用、跨平台、支持多种语言、文档齐全
- 有消息确认机制和持久化机制，可靠性高；
- 高度可定制的路由
- 管理界面较丰富，在互联网公司也有较大规模的应用，社区活跃度高；
- 缺点
- 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；需要学习比较复杂的接口和协议，学习和维护成本较高；
- 尽管结合Erlang语言本身的并发优势 ，性能较好，但是不利于二次开发和维护；
ActiveMQ
ActiveMQ是由Apache出品，ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMS Provider实现。它非常快速，支持多种语言的客户端和协议，并且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。
- 优点
- 可以用JDBC，可以将数据持久化到数据库。虽然使用JDBC会降低Active MQ的性能，但是数据库一直都是开发人员最熟悉的存储介质；
- 支持JMS规范：支持JMS规范提供的统一接口；
- 支持自动重连和错误重试机制
- 有安全机制：支持基于shiro,jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权；
- 监控完善：拥有完善的监控，包括WebConsole，JMX，Shell命令行，Jolokia的Restful API;
- 界面完善：提供的WebConsole可以满足大部分情况，还有很多第三方的组件可以使用，比如hawtio
- 缺点
- 社区活跃度不及RabbitMQ高
- 根据其他用户反馈，会出莫名其妙的问题，会丢失消息
- 目前重心放在activeMQ6.0产品Apollo，对5.x维护较少
- 不适合用于上千个队列的应用场景
ZeroMQ
号称史上最快的消息队列，它实际类似于Socket的一系列接口，他跟Socket的区别是：普通的Socket是端到端的（1：1的关系），而ZMQ却是可以N:M的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式的建立连接、销毁连接、选择协议(TCP/UDP)和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node之间的通信。node可以是主机或者是进程。
引用官方的说法：“ZMQ是一个简单好用的传输层，像框架一样的一个socket libery，他使得Socket编程更加简单，简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是”成为标准网络协议栈的一部分，之后进入Linux内核“
和RabbitMQ相比，ZMQ并不像是一个传统意义上的消息队列服务器，事实上，他也根本不是一个服务器，更像一个底层的网络通讯库，在Socket API之上做了一层封装，将网络通讯、进程通讯和线程通讯抽象成一个统一的API接口。支持"Request-Reply"，”Publisher-Subscrber"，“Parallel Pipeline"三种基本模型和扩展模型。
MQ对比选型
消息队列的选型根据应用需求而定，ZeroMQ小而美，RabbitMQ大而稳，Kafka和RocketMQ快而强劲。
要想对MQ进行技术选型，主要从以下两个角度出发：
- 从公司基础建设力量角度出发
- 中小型软件公司，建议选RabbitMQ
首先，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。他的弊端也很明显，虽然RabbitMQ是开源的，但是用的是erlang语言开发。国内的erlang程序员太少。
其次：不考虑Kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应该首选功能比较完备的，所以Kafka排除。
最后：不考虑RocketMQ的原因是，RocketMQ是阿里出品，如果阿里放弃维护RocketMQ，中小型公司一般抽不出人来进行RocketMQ的定制化开发，因此不推荐。 - 大型软件公司
根据具体使用在RocketMQ和Kafka之间二选一。
一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对RocketMQ,大型软件公司也可以抽出人手对RocketMQ进行定制化开发，毕竟国内有能力改源码的人，还是相当多的。
至于Kafka，根据业务场景选择，如果有日志采集功能，肯定是首选Kafka了。
- 从业务场景角度出发
RocketMQ定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binlog分发等场景。
Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
结论
总结下来就一句话！
中小软件公司：RabbitMQ（稳定性高）
大型软件公司：RocketMQ和Kafka（具备足够大的资金搭建分布式环境，也具备足够大的数据量