常见消息中间件大PK

　　1。几种协议1。1JMS1。2AMQP1。3MQTT1。4XMPP1。5JMSVsAMQP2。重要产品2。1ActiveMQ2。2RabbitMQ2。3RocketMQ2。4Kafka2。5ZeroMQ2。6其他3。比较
　　说到消息中间件，估计大伙多多少少都能讲出来一些，ActiveMQ、RabbitMQ、RocketMQ、Kafka等等各种以及JMS、AMQP等各种协议，然而这些消息中间件各自都有什么特点，我们在开发中又该选择哪种呢？今天松哥就来和小伙伴们梳理一下。1。几种协议
　　先来说说消息中间件中常见的几个协议。1。1JMS1。1。1JMS介绍
　　先来说说JMS。
　　JMS全称JavaMessageService，类似于JDBC，不同于JDBC，JMS是JavaEE的消息服务接口，JMS主要有两个版本：1。12。0。
　　两者相比，后者主要是简化了收发消息的代码。
　　考虑到消息中间件是一个非常常用的工具，所以JavaEE为此制定了专门的规范JMS。
　　不过和JDBC一样，JMS作为规范，他只是一套接口，并不包含具体的实现，如果我们要使用JMS，那么一般还需要对应的实现，这就像使用JDBC需要对应的驱动一样。1。1。2JMS模型
　　JMS消息服务支持两种消息模型：点对点或队列模型发布订阅模型
　　在点对点或队列模型下，一个生产者向一个特定的队列发布消息，一个消费者从该队列中读取消息。这里，生产者知道消费者的队列，并直接将消息发送到对应的队列。这是一种点对点的消息模型，这种模式被概括为：只有一个消费者将获得消息。生产者不需要在消费者消费该消息期间处于运行状态，消费者也同样不需要在消息发送时处于运行状态，即消息的生产者和消费者是完全解耦的。每一个成功处理的消息都由消息消费者签收。
　　发布者订阅者模型支持向一个特定的消息主题发布消息，消费者则可以定义自己感兴趣的主题，这是一种点对面的消息模型，这种模式可以被概括为：多个消费者可以消费消息。在发布者和订阅者之间存在时间依赖性，发布者需要创建一个订阅（subscription），以便客户能够订阅；订阅者必须保持在线状态以接收消息；当然，如果订阅者创建了持久的订阅，那么在订阅者未连接时，消息生产者发布的消息将会在订阅者重新连接时重新发布。1。1。3JMS实现
　　开源的支持JMS的消息中间件有：KafkaApacheActiveMQJBoss社区的HornetQJoramCoridan的MantaRayOpenJMS
　　一些商用的支持JMS的消息中间件有：WebLogicServerJMSEMSGigaSpacesiBusIONAJMSIQManager（2005年8月被SunMicrosystems并购）JMSNirvanaSonicMQWebSphereMQ
　　这里有不少是松哥考古挖掘出来的，其实对于我们日常开发接触较多的，可能就是Kafka和ActiveMQ。1。2AMQP1。2。1AMQP简介
　　另一个和消息中间件有关的协议就是AMQP了。
　　MessageQueue的需求由来已久，80年代最早在金融交易中，高盛等公司采用Teknekron公司的产品，当时的MessageQueue软件叫做：theinformationbus（TIB）。TIB被电信和通讯公司采用，路透社收购了Teknekron公司。之后，IBM开发了MQSeries，微软开发了MicrosoftMessageQueue（MSMQ）。这些商业MQ供应商的问题是厂商锁定，价格高昂。2001年，JavaMessageService试图解决锁定和交互性的问题，但对应用来说反而更加麻烦了。
　　于是2004年，摩根大通和iMatrix开始着手AdvancedMessageQueuingProtocol（AMQP）开放标准的开发。2006年，AMQP规范发布。2007年，Rabbit技术公司基于AMQP标准开发的RabbitMQ1。0发布。
　　目前RabbitMQ的最新版本为3。5。7，基于AMQP091。
　　在AMQP协议中，消息收发涉及到如下一些概念：Broker：接收和分发消息的应用，我们日常所用的RabbitMQ就是一个MessageBroker。Virtualhost：出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ提供的服务时，可以划分出多个vhost，每个用户在自己的vhost中创建exchangequeue等，这个松哥之前写过专门的文章，传送门：RabbitMQ中的VirtualHost该如何理解。Connection：publisherconsumer和broker之间的TCP连接，断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。Channel：如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCPConnection的开销将是巨大的，效率也较低。Channel是在Connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个Thread创建单独的Channel进行通讯，AMQPmethod包含了Channelid帮助客户端和MessageBroker识别Channel，所以Channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCPConnection的开销，关于Channel，松哥在RabbitMQ管理页面该如何使用一文中也做过详细介绍。Exchange：Message到达Broker的第一站，根据分发规则，匹配查询表中的routingkey，分发消息到queue中去。常用的类型有：direct（点对点），topic（发布订阅）以及fanout（广播）。Queue：消息最终被送到这里等待Consumer取走，一个Message可以被同时拷贝到多个queue中。Binding：Exchange和Queue之间的虚拟连接，binding中可以包含routingkey，Binding信息被保存到Exchange中的查询表中，作为Message的分发依据。1。2。2AMQP实现
　　来看看实现了AMQP协议的一些具体的消息中间件产品都有哪些。ApacheQpidApacheActiveMQRabbitMQ
　　可能有小伙伴奇怪咋还有ActiveMQ？其实ActiveMQ不仅支持JMS，也支持AMQP，这个松哥后面细说。
　　另外还有大家熟知的阿里出品的RocketMQ，这个是自定义了一套协议，社区也提供了JMS，但是不太成熟，后面松哥细说。1。3MQTT
　　做物联网开发的小伙伴应该会经常接触这个协议，MQTT（MessageQueuingTelemetryTransport，消息队列遥测传输）是IBM开发的一个即时通讯协议，目前看来算是物联网开发中比较重要的协议之一了，该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和Actuator（比如通过Twitter让房屋联网）的通信协议，它的优点是格式简洁、占用带宽小、支持移动端通信、支持PUSH、适用于嵌入式系统。1。4XMPP
　　XMPP（可扩展消息处理现场协议，ExtensibleMessagingandPresenceProtocol）是一个基于XML的协议，多用于即时消息（IM）以及在线现场探测，适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。它的优点是通用公开、兼容性强、可扩展、安全性高，缺点是XML编码格式占用带宽大。1。5JMSVsAMQP
　　对于我们Java工程师而言，大家日常接触较多的应该是JMS和AMQP协议，既然JMS和AMQP都是协议，那么两者有什么区别呢？来看下面一张图：
　　这张图说的很清楚了，我就不啰嗦了。2。重要产品2。1ActiveMQ
　　ActiveMQ是Apache下的一个子项目，使用完全支持JMS1。1和J2EE1。4规范的JMSProvider实现，少量代码就可以高效地实现高级应用场景，并且支持可插拔的传输协议，如：inVM，TCP，SSL，NIO，UDP，multicast，JGroupsandJXTAtransports。
　　ActiveMQ支持常用的多种语言客户端如C、Java、。Net，、Python、Php、Ruby等。
　　现在的ActiveMQ分为两个版本：ActiveMQClassicActiveMQArtemis
　　这里的ActiveMQClassic就是原来的ActiveMQ，而ActiveMQArtemis是在RedHat捐赠的HornetQ服务器代码的基础上开发的，两者代码完全不同，后者支持JMS2。0，使用基于Netty的异步IO，大大提升了性能，更为神奇的是，后者不仅支持JMS协议，还支持AMQP协议、STOMP以及MQTT，可以说后者的玩法相当丰富。
　　因此大家在使用时，建议直接选择ActiveMQArtemis。2。2RabbitMQ
　　RabbitMQ算是AMQP体系下最为重要的产品了，它基于Erlang语言开发实现，估计很多人被RabbitMQ的安装折磨过，松哥建议安装RabbitMQ直接用Docker，省心省力（公号后台回复docker有教程）。
　　RabbitMQ支持AMQP、XMPP、SMTP、STOMP等多种协议，功能强大，适用于企业级开发。
　　来看一张RabbitMQ的结构图：
　　关于RabbitMQ，松哥最近发了十来篇教程了，这里就不再啰嗦了。2。3RocketMQ
　　RocketMQ是阿里开源的一款分布式消息中间件，原名Metaq，从3。0版本开始改名为RocketMQ，是阿里参照Kafka设计思想使用Java语言实现的一套MQ。RocketMQ将阿里内部多款MQ产品（Notify、Metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下MQ的架构，目前主要用于订单交易系统。
　　RocketMQ具有以下特点：保证严格的消息顺序。提供针对消息的过滤功能。提供丰富的消息拉取模式。高效的订阅者水平扩展能力。实时的消息订阅机制。亿级消息堆积能力
　　对于Java工程师而言，这也是一种经常会用到的MQ。2。4Kafka
　　Kafka是Apache下的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作（网页浏览，搜索和其他用户的行动）流数据。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。
　　Kafka具有以下特性：快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O（1）的系统开销下进行消息持久化。高吞吐：在一台普通的服务器上既可以达到10Ws的吞吐速率。高堆积：支持topic下消费者较长时间离线，消息堆积量大。完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，通过Zookeeper可以自动实现更加复杂的负载均衡。支持Hadoop数据并行加载。
　　大数据开发中大家可能会经常接触Kafka，Java开发中也会接触，但是相对来说可能接触的少一些。2。5ZeroMQ
　　ZeroMQ号称最快的消息队列系统，它专门为高吞吐量低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZeroMQ不是单独的服务，而是一个嵌入式库，它封装了网络通信、消息队列、线程调度等功能，向上层提供简洁的API，应用程序通过加载库文件，调用API函数来实现高性能网络通信。
　　ZeroMQ的特性：无锁的队列模型：对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS，在pipe的两端注册有异步事件，在读或者写消息到pipe时，会自动触发读写事件。批量处理的算法：对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。多核下的线程绑定，无须CPU切换：区别于传统的多线程并发模式，信号量或者临界区，ZeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。2。6其他
　　另外还有如Redis也能做消息队列，松哥之前也发过文章和大家介绍用Redis做普通消息队列和延迟消息队列，这里也就不啰嗦了。3。比较
　　最后，我们再来通过一张图来比较下各个消息中间件。
　　小伙伴们在公众号后台回复mqpkmq，可以获取这个Excel表格链接。
　　好啦，就扯这么多。