一、ActiveMQ二、RabbitMQ三、RocketMQ四、Kafka五、ZeroMQ六、主要消息中间件的比较
有哪些主流的消息中间件？
当前业界比较流行的开源消息中间件包括：ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等。
其中应用最为广泛的要数RabbitMQ、RocketMQ、Kafka 这三款。
Redis在某种程度上也可以是实现类似 “Queue” 和“ Pub/Sub” 的机制，严格意义上不算消息中间件。
一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，不推荐用这个了。
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高。
不过现在确实越来越多的公司，会去用 RocketMQ，确实很不错（阿里出品），但社区可能有突然黄掉的风险，对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
一、ActiveMQApache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。
ActiveMQ、RabbitMQ、ZeroMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
ActiveMQ只需要操作系统支持Java虚拟机，便可执行。
ActiveMQ可以很容易内嵌到使用Spring的系统里面去通过了常见J2EE服务器的测试。
JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。其丰富的 API 、多种集群构建模式使得他成为业界老牌消息中间件，在中小型企业中应用广泛！
优点：
ActiveMQ采用消息推送方式，所以最适合的场景是默认消息都可在短时间内被消费。数据量越大，查找和消费消息就越慢，消息积压程度与消息速度成反比。
缺点：
吞吐量低。由于 ActiveMQ 需要建立索引，导致吞吐量下降。这是无法克服的缺点，只要使用完全符合 JMS 规范的消息中间件，就要接受这个级别的TPS。无分片功能。这是一个功能缺失，JMS 并没有规定消息中间件的集群、分片机制。而由于 ActiveMQ 是伟企业级开发设计的消息中间件，初衷并不是为了处理海量消息和高并发请求。如果一台服务器不能承受更多消息，则需要横向拆分。ActiveMQ 官方不提供分片机制，需要自己实现。 二、RabbitMQ
使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP，SMTP，STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。
RabbitMQ 开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。
优点：
- 轻量级，快速，部署使用方便支持灵活的路由配置。RabbitMQ中，在生产者和队列之间有一个交换器模块。根据配置的路由规则，生产者发送的消息可以发送到不同的队列中。路由规则很灵活，还可以自己实现。RabbitMQ的客户端支持大多数的编程语言。
缺点：
- 如果有大量消息堆积在队列中，性能会急剧下降RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒处理几万到几十万的消息。如果应用要求高的性能，不要选择RabbitMQ。RabbitMQ是Erlang开发的，功能扩展和二次开发代价很高。
阿里系下开源的一款分布式、队列模型的消息中间件，原名metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
具有以下特点：
能够保证严格的消息顺序提供针对消息的过滤功能提供丰富的消息拉取模式高效的订阅者水平扩展能力实时的消息订阅机制亿级消息堆积能力
官方提供了一些不同于kafka的对比差异：
https://rocketmq.apache.org/docs/motivation/
优点：
- RocketMQ 主要用于有序，事务，流计算，消息推送，日志流处理，binlog分发等场景。经过了历次的双11考验，性能，稳定性可可靠性没的说。RocketMQ 几乎具备了消息队列应该具备的所有特性和功能。java 开发，阅读源代码、扩展、二次开发很方便。对电商领域的响应延迟做了很多优化。在大多数情况下，响应在毫秒级。如果应用很关注响应时间，可以使用RocketMQ。性能比RabbitMQ高一个数量级，每秒处理几十万的消息。
缺点：
- 跟周边系统的整合和兼容不是很好。
Apache下的一个子项目，使用scala和java实现的一个高性能分布式Pub/Sub消息队列系统，具有以下特性：
快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；高堆积：支持topic下消费者较长时间离线，消息堆积量大；完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
Kafka的可靠性，稳定性和功能特性基本满足大多数的应用场景。跟周边系统的兼容性是数一数二的，尤其是大数据和流计算领域，几乎所有相关的开源软件都支持Kafka。Kafka是Scala和Java开发的，对批处理和异步处理做了大量的设计，因此Kafka可以得到非常高的性能。它的异步消息的发送和接收是最好的，但是跟RocketMQ拉不开数量级，每秒处理几十万的消息。如果是异步消息，并且开启了压缩，Kafka最终可以达到每秒处理2000w消息的级别。
优点：
- 支持多个生产者和消费者支持broker的横向拓展副本集机制，实现数据冗余，保证数据不丢失通过topic将数据进行分类通过分批发送压缩数据的方式，减少数据传输开销，提高吞高量支持多种模式的消息基于磁盘实现数据的持久化高性能的处理信息，在大数据的情况下，可以保证亚秒级的消息延迟一个消费者可以支持多种topic的消息对CPU和内存的消耗比较小对网络开销也比较小支持跨数据中心的数据复制支持镜像集群
缺点：
- 由于是批量发送，所以数据达不到真正的实时对于mqtt协议不支持不支持物联网传感数据直接接入只能支持统一分区内消息有序，无法实现全局消息有序监控不完善，需要安装插件需要配合zookeeper进行元数据管理会丢失数据，并且不支持事务可能会重复消费数据，消息会乱序，可用保证一个固定的partition内部的消息是有序的，但是一个topic有多个partition的话，就不能保证有序了，需要zookeeper的支持，topic一般需要人工创建，部署和维护一般都比mq高
号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使用ZeroMQ作为数据流的传输。
ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。
特性：
无锁的队列模型：对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe的两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。批量处理的算法：对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。多核下的线程绑定，无须CPU切换：区别于传统的多线程并发模式，信号量或者临界区，zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。 六、主要消息中间件的比较
