消息中间件（RocketMQ、RabbitMQ、ActiveMQ、Redis、kafka、ZeroMQ）以及之间的区别

一、什么是消息中间件

面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能；成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，比如老牌的ActiveMQ、RabbitMQ，炙手可热的kafka，阿里巴巴自主开发的RocketMQ等。

二、消息中间件的组成

1、Broker

消息服务器，作为server提供消息核心服务。

2、Producer

生产者，消息的产生者，是消息的入口。业务的发起方，负责生产消息传输给Broker。

3、Consumer

消息消费者，即消息的消费方，是消息的出口，负责从broker获取消息并进行业务逻辑处理。

4、Topic

消息的主题，可以理解为消息的分类，在每个broker上都可以创建多个topic。发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器发布到不同的订阅者，实现消息的广播。

5、Queue

队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定的消息的接收。

6、Message

消息体，每一条发送的消息主体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。

三、消息中间件通信模式

点对点、发布订阅

1、点对点（kafka不支持这种模式）

PTP点对点：使用queue作为通信载体。

消息生产者先生产消息发送到queue中，然后消费者从queue中读取出消息并且消费这个消息。属于一对一模式，不能够进行重复消费。消费完了之后，数据就会被删除了。

生产者生成数据之后能被一个消费者消费；多个生产者生产的数据能被多个消费者消费。

2、发布/订阅

Pub/Sub发布订阅（广播）：使用topic作为通信载体。针对topic来说。只要连接上消息中间件、消费者都可以进行消费，只要有权限获取到topic，消费者之间的消费互不影响。

消息生产者（producer）将消息发布到topic中，同时会有很多个消息消费者（订阅）消费该消息。和点对点方式不同的是，发布到topic的消息会被所有的订阅者消费。

queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。

topic实现了发布和订阅，但发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的备份。

生产者1，创建的topic为sc。消费完了，数据不会被删除。偏移量会有记录。

四、消息中间件的作用

1、系统解耦

交互系统之间没有直接的调用关系，只是通过消息传输，所以系统的侵入性不强，耦合度低。

2、提高系统响应时间

比如就像购物一样，完成支付可能会涉及到先修改订单状态、计算会员积分、通知物流配送几个流程才能完成；通过MQ架构设计，就可以将紧急通知（需要立刻响应处理的）的业务放到这个调用方法中，响应要求不高的可以使用消息队列，放到MQ队列中，供消费者处理。

3、为大数据处理架构提供服务

通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。

五、消息中间件应用场景

1、异步通信

有些业务不想也不需要立即去处理消息。消息队列就提供了异步处理机制，允许用户把一个消息放入队列，但是并不是立即处理它。想要向队列中放入多少消息就放入多少，然后在需要的时候再去处理她们。

2、解耦

降低工程之间的强依赖程序，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是及其困难的。通常消息系统在处理过程中会插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一个接口，当应用发生变化的时候，可以独立的扩展或修改两边的处理过程，只要确保它们遵同样的接口约束。

3、冗余

在有些情况下，处理数据的过程会失败。除非数据被持久化，否则会造成数据的丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

4、扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理的过程就可以了。不需要改变代码、不需要调节参数。便于分布式扩展。

5、过载保护

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

6、可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

7、顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

8、缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

9、数据流处理

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

五、常见的消息中间件MQ（message queue）

1、RocketMQ

阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用Java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只要维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化、在这个基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要是多用于订单交易系统。

具有的特点：

• 能够保证严格的消息顺序
• 提供针对消息的过滤功能
• 提供丰富的消息拉取模式
• 高效的订阅者水平扩展能力
• 实时的消息订阅机制
• 亿级消息堆积能力

2、RabbitMQ

使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP、XMPP、SMTP、STOMP，也是因为这个，使得它变成非常轻量级，更适合企业级的开发。同时实现了broker的架构，核心思想就是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由（Routing），负载均衡、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

3、ActiveMQ

Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

4、Redis

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

5、kafka

Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等。

主要应用场景是：日志收集系统和消息系统。

Kafka主要设计目标如下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
• 同时支持离线数据处理和实时数据处理。
• Scale out:支持在线水平扩展

6、ZeroMQ

属于最快的消息队列系统，专门为高吞吐量/低延迟的常见开发，在金融界的应用中经常使用，偏重于实时数据通信场景。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切换开销。

六、主要消息中间件之间的比较

以上内容部分自我学习理解，部分借鉴于：https://blog.csdn.net/wqc19920906/article/details/82193316