消息中间件的介绍和对比

1. 参考原文链接：版权声明：本文为CSDN博主「Mr_baci」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。 https://blog.csdn.net/java_zyq/article/details/80022391

2. 参考原文链接： 流雨飞雪   消息中间件选型 - 流雨飞雪 - 博客园

3. 本文是好几篇博文的综合梳理，转载请说明出处&附带原文连接。

一、概述   

       (开源消息中间件介绍)目前业界上关于消息中间件的实现多达好几十种，可谓百花齐放，所用的实现语言同样也五花八门。下面挑选了一部分，在网上开源社区相对容易搜索出来的十多种MQ来作简单介绍。

开源MQ	概述
1.Qpid	Apach的一个开源AMQP实现，broker架构，有C++和Java两个版本
2.RabbitMQ	LShift 用Erlang实现，支持多协议，broker架构，重量级
3.ZeroMQ	AMQP最初设计者iMatix公司实现，轻量消息内核，无broker设计。C++实现
4.Jafka/Kafka	LinkedIn用Scala语言实现，支持hadoop数据并行加载
5.ActiveMQ	Apach的一种JMS具体实现，支持代理和p2p部署。支持多协议。Java实现
6.Apollo	ActiveMQ的下一代产品，支持多协议，Scala实现
7.Redis	Key-value  NoSQL数据库，有MQ的功能
8.MemcacheQ	国人利用memcache缓冲队列协议开发的消息队列,C/C++实现
9.Open-MQ	C++和QT实现，支持JMS
10.ActiveMQ-CPP	ActiveMQ的C++纯客户端库，用于跟ActiveMQ通信
11.MQ4CPP	一个C++实现的MQ，信息甚少
12.MetaQ	Alibaba对Kafka的改造，增加事务支持等新特性，用纯Java实现
13.Beanstalkd	一个类memcached协议设计的消息队列,C/C++实现
14.OpenAMQ	iMatix公司AMQP1.0的实现，类似rabbitMQ。C++实现。2010年项目放弃
15.Spread Toolkit	高性能的分布式分组消息系统，C++实现
16.SAFMQ	C++实现的储存转发消息队列中间件
17. Mosquitto	一个轻量级的IBM物联网连接协议的消息中间件实现，C/C++实现
18.MUSCLE	提供一个多路消息服务器和消息对象传递功能，支持C/C++
19.JORAM	一个类似OpenJMS(Sun OpenMQ)的JMS消息中间件，JAVA实现

       什么是消息中间件？

消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。个人感觉比价场景应用核心的有三个：解耦、异步、削峰。

二、消息队列的使用场景  

       为什么使用消息队列？

其实这个话题也是面试官经常问询的问题，问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么

期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ之后带给了你很多的好处

现在你可以下想想你如何回答上述问题，想不起来？  好吧我这里先介绍几个常见使用场景，提醒下。。。

解耦：现场画个图来说明一下，

A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。

这是你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里（做过微服务项目的同学这里是不是考虑下  消息总线 搭配Rabbitmq 做解耦 用于广播配置文件的更改或者服务间的通讯？），是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ作解耦。

异步：现场画个图来说明一下，

A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。

更改为 异步后当消息发送到消息队列  自行让对应系统进行消费即可  所以给用户的体验为20 + 5 = 25ms  ,快 好快！

削峰：每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。

 消息队列有什么优缺点？

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰？

选择消息系统根据业务需要需要考虑以下几个方面：

l  是否持久化

l  吞吐能力

l  高可用，避免单点故障

l  分布式扩展能力

l  兼容现有协议

l  易于维护

l  其他，如消息丢失和重复的处理

l  负载均衡

缺点呢？显而易见的

系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已

一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。。。

目前流行的消息队列都有什么优点和缺点呢？

kafka

LinkedIn开源的分布式发布-订阅消息系统，目前属于Apache。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务，Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

        在架构模型方面 kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。

        在吞吐量kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。

       在集群负载均衡方面，采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。
       在可用性方面，kafka的broker支持主备模式。

       机制上来讲，kafka中，只有topic，但是每个topic可以有很多partition分区。若是kafka集群由两台机器组成。topic被分成四个分区，server1维护p0,p3。 在kafka中，每个消费者都要指出自己属于哪个consumerGroup，每个consumer可以读取多个partition。但是一个partition在同一个consumerGroup中，只会被一个consumer消费。以此保证不会重复消费。而且在一个partition中，消息被消费的顺序是可保障的。上图中，consumer group A 由两个consumer组成，因此一个consumer可以消费两个partition。如果要保证严格的顺序性，那么就要像consumer group B一样，每个consumer只消费一个partition。kafka和rabbitmq及activemq机制上略有区别。rabbitmq和activemq都是消费后就删除消息，没有重复消费的功能，而kafka 队列中的内容按策略存储一定时间，消费者通过指定偏移量来读取数据。如果使用基础api可以从任意位置读取。kafka同时提供高级api，即kafka来维护每个消费者当前读到什么位置了，下次再来，可以接着读。

    kafka中partition是冗余存储的。如果一个partition不幸挂了，通过选主，马上可以切换到另外一台机器上继续使用。这一点上，是当之无愧的分布式队列。相比之下，rabbitmq需要配置镜像队列，操作太麻烦。kafka搭建集群也是非常简单。

    kafka的优势在于: 传统的消息队列只有两种模式，要么是queue，要么是publish-subscribe发布订阅。在queue模式中，一组消费者消费一个队列，每条消息被发给其中一个消费者。在publish-subscribe模式中，消费被广播给所有消费者。queue模式的好处在于，他可以把消费分发给一组消费者，从而实现消费者的规模化（scale）；问题在于，这样一个消息只能被一组消费者消费，一旦消费，消息就没有了。publish-subscribe的好处在于，一个消息可以被多组消费者消费；问题在于，你的消费者没法规模化，即不可能出现多个消费者订阅同一个topic，但每个消费者只处理一部分消息（虽然这个可以通过设计topic来解决）。

    kafka的设计意义在于，大家都publish-subscribe，因为我的队列数据是不删除的，多个subscriber可以订阅同一个topic，但是各自想从哪读，从哪读，互不干扰。同时提出了consumer group的概念。每个subscriber可以是多个consumer组成的，在consumer group内部，你们自己分配，不要两个人消费同一条数据。为了达到这种目的，一个topic里的消息，被分成多个partition，既实现了上面的想法，同时又冗余（一个partition可以冗余存储在多台机器上），达到分布式系统的高可用效果。

    kafka也支持mqtt，需要写一个connecter。kafka还提供流式计算的功能，做数据的初步清理还是很方便的。

    总体而言。我感觉kafka安装使用最简单，同时，如果有集群要求，那么kafka是当仁不让的首选。尤其在海量数据，以及数据有倾斜问题的场景里，因为partition的缘故，数据倾斜问题自动解决。比如个别Topic的消息量非常大，在kafka里，调整partition数就好了。反而在rabbitmq或者activemq里，这个不好解决。

    rabbitmq是功能最丰富，最完善的企业级队列。基本没有做不了的，就算是做类似kafka的高可用集群，也是没问题的，不过安装部署麻烦了点。

      在kafka中，创建一个topic是一个比较重的操作，因为是分布式的，topic要同步到其他的broker，中间还要经过zookeeper。所以kafka仅仅做mqtt的输入是ok的，但是你需要给每个硬件推送消息，实际上不太好。这方面反倒是rabbitmq比较好，因为在rabbitmq中创建几万的topic是很容易的，所以是可以做到每个硬件订阅不同的topic。

RabbitMQ
使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
        在架构模型方面RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。
        在吞吐量rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。

        在集群负载均衡方面，rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

        在可用性方面，rabbitMQ支持miror的queue，主queue失效，miror queue接管。

        机制上来讲，rabbitmq也有queue和topic的概念，发消息的时候还要指定消息的key，这个key之后会做路由键用。但是，多了一个概念叫做交换器exchange。exchange有四种，direct、fanout、topic、header。也就是说，发消息给rabbitmq时，消息要有一个key，并告诉他发给哪个exchange。exchange收到之后，根据key分发或者广播给queue。消费者是从queue里拿消息的，并接触不到交换机。

    在rabbitmq里，有各种默认行为，如果我们不指定exchange，会有个默认的direct类型的exchange，如果不指定队列和交换器的绑定关系，默认就按消息的key绑定对应的queue。此时发一个消息，消息的key是什么，就会被默认交换器送给对应的queue。

此时，其实等同于activemq的queue模式。

在rabbitmq里，一个queue可以有多个消费者

通过设置prefetch的值为1，可以让多个消费者每次都取到一条记录，消费完再取下一条。这两种都是使用direct交换器，即消息的key是多少，就把消息放到key对应的queue中。

    fanout交换器。实际上就是广播，发送到fanout交换器的消息，会被转发给所有和这个交换器绑定的队列。通常我们把队列搞成临时的，这样就解耦了。例如用户登录，发送一个登陆消息到fanout交换器，同时有一个smsQueue和交换器绑定，一个消费者从这个smsQueue里取出谁登陆了，并发送一条短信。过了几天，我们希望用户登陆可以获得积分。那么我再声明一个scoreQueue绑定到这个fanout交换器，实现积分更改逻辑。下图是fanout（X为交换器）

    总体说来fanout其实就是direct交换器实现的。把两个队列都绑定到direct，绑定的时候指定同一个key，就变成fanout交换器了，如下图

    queue和exchange绑定的时候，也可以指定多个绑定key，这时候就实现了简单版的订阅。如下图

当然这样不够灵活，我想要靠通配符绑定如何呢，这时候就不用direct交换器了，用topic交换器

    “#”通配剩余字符，"*"通配部分字符。 如果绑定的时候key为“#”，那么其实就是fanout交换器。如果一个通配符都没有，其实就是direct交换器。

    head交换器貌似是通过消息附带的头信息来路由的，不过官方对这个介绍的少之又少，平时也应该没什么人用，死信队列貌似依赖于这个。

    通过交换器的概念，rabbitmq在机制上要比activemq灵活不少。对于activemq来说，你要么是个queue的消费者，要么是个topic的订阅者。你要同时订阅多个topic，要自己在消费者端写代码来实现。在rabbitmq中，你只是queue的消费者，至于你这个queue的消息是从哪个topic来，或者从哪里直接发过来，这个和消费者没有关系，而且queue里的消息从哪来可以在rabbitmq里动态配置。所以灵活度得到了提升。

    rabbitmq同样也支持主从复制和集群。但是rabbitmq的集群非常多样化，而且需要至少一台机器做为磁盘节点，可以持久化queue和exchange的信息，其他的可以为内存节点。普通集群中，只有exchange，queue这些定义是分布在所有机器上的，而queue中的数据不是冗余的，比如有三台rabbitmq组成了集群，他们共享同样的exchange,queue，但是一条消息数据落到了第一台机器上，另外两台实际上没有这条数据的。 对于整个集群的使用，这样其实没有任何问题。  但出于高可用的角度来想，还是需要完完全全的分布式集群的，万一中间有数据这台机器挂了？ rabbitmq对此也有支持，把队列数据也冗余存到三台机器上，称之为镜像队列，但性能要比普通集群低，毕竟一条消息被复制到其他机器上是耗时的事情。

    rabbitmq以plugin的形式支持mqtt，和spring整合也非常简单。

Redis
一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
 

RocketMQ
阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

ZeroMQ
号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

ActiveMQ
Apache ActiveMQ 是最受欢迎且功能最强大的开源消息传递和Integration Patterns服务器。
Apache ActiveMQ速度快，支持许多跨语言客户端和协议，带有易于使用的企业集成模式和许多高级功能，同时完全支持JMS 1.1和J2EE 1.4。Apache ActiveMQ是在Apache 2.0许可下发布
特征
支持Java消息服务(JMS) 1.1 版本
Spring Framework
集群 (Clustering)
支持的编程语言包括：C、C++、C#、Delphi、Erlang、Adobe Flash、Haskell、Java、JavaScript、Perl、PHP、Pike、Python和Ruby，同时对jms、spring之类的支持很友好。
协议支持包括：OpenWire、REST、STOMP、WS-Notification、MQTT、XMPP以及AMQP [1]

       而且因为是Java写的，所以可以作为一个jar包，放到java项目里，用代码启动和配置，这个对于java开发者而言是不是相当爽？毕竟还是有些场景，需要我们把队列放到自己项目内部，随项目启动而启动的。而且，还可以类似拓展tomcat一样，自己写java的plugin来拓展activemq。比如说，我有10万硬件连到mq上，这10万设备每个都有用户名密码，这个时候我们可以用java写个权限验证，从数据库里查这10万用户名密码。

    activemq支持主从复制、集群。但是集群功能看起来很弱，只有failover功能，即我连一个失败了，可以切换到其他的broker上。这一点貌似不太科学。假设有三个broker，其中一个上面没有consumer，但另外两个挂了，消息会转到这个上面来，堆积起来。看样子activemq还在升级中。

    activemq工作模型比较简单。只有两种模式 queue,topics 。

    queue就多对一，producer往queue里发送消息，消费者从queue里取，消费一条，就从queue里移除一条。如果一个消费者消费速度不够快怎么办呢？在activemq里，提供messageGroup的概念，一个queue可以有多个消费者，但是他们得标记自己是一个messageGroup里的。这样，消息会轮训发送给每个消费者，也就是说消费者不会重复消费同一条消息。但是每条消息只被消费一次。

    topics就是广播。producer往broker发消息，每个消息包含topic。消费者订阅感兴趣的topic，所有订阅了topic的消费者都会收到消息。当然订阅分持久不持久。持久订阅，当消费者断开一会，再连上来，仍然会把没收到的消费发过来。不持久的订阅，断开这段时间的消息就收不到了。

    activemq支持mqtt、ssl。

综上所述，各种对比之后，总结如下：

一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；

后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高；

不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择（我们项目也正在使用这个^_^）；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择

如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范