文章大纲

一、什么是消息中间件
二、消息中间件组成
三、消息队列的的传输模式
四、消息中间件的优势
五、消息中间件应用场景
六、消息中间件常用协议
七、常见消息中间件介绍与比较
八、参考文章

 

一、什么是消息中间件

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

二、消息中间件组成

1. Broker

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

2. Producer

消息生产者，业务的发起方，负责生产消息传输给broker

3. Consumer

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

4. Topic

主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播

5. Queue

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

6. Message

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

三、消息队列的的传输模式

1. 点对点

点对点模型 用于 消息生产者 和 消息消费者 之间 点到点 的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个 队列（Queue），在消息传递给消费者之前它被 存储 在这个队列中。队列消息 可以放在 内存 中也可以 持久化，以保证在消息服务出现故障时仍然能够传递消息。

传统的点对点消息中间件通常由 消息队列服务、消息传递服务、消息队列 和 消息应用程序接口 API 组成，其典型的结构如下图所示。

 

特点
每个消息只用一个消费者；
发送者和接受者没有时间依赖；
接受者确认消息接受和处理成功。

示意图如下所示

 

2. 发布/订阅模型（Pub/Sub）

发布者/订阅者 模型支持向一个特定的 消息主题 生产消息。0 或 多个订阅者 可能对接收来自 特定消息主题 的消息感兴趣。

在这种模型下，发布者和订阅者彼此不知道对方，就好比是匿名公告板。这种模式被概况为：多个消费者可以获得消息，在 发布者 和 订阅者 之间存在 时间依赖性。发布者需要建立一个 订阅（subscription），以便能够消费者订阅。订阅者 必须保持 持续的活动状态 并 接收消息。

在这种情况下，在订阅者 未连接时，发布的消息将在订阅者 重新连接 时 重新发布，如下图所示：

 

特性
每个消息可以有多个订阅者；
客户端只有订阅后才能接收到消息；
持久订阅和非持久订阅。

注意
发布者和订阅者有时间依赖：接受者和发布者只有建立订阅关系才能收到消息；
持久订阅：订阅关系建立后，消息就不会消失，不管订阅者是否都在线；
非持久订阅：订阅者为了接受消息，必须一直在线。当只有一个订阅者时约等于点对点模式

四、消息中间件的优势

1. 系统解耦

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

2. 提高系统响应时间

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

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

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

4. Java消息服务——JMS

Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
JMS中的P2P和Pub/Sub消息模式：点对点（point to point， queue）与发布订阅（publish/subscribe，topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。

五、消息中间件应用场景

当你需要使用 消息队列 时，首先需要考虑它的必要性。可以使用消息队列的场景有很多，最常用的几种，是做 应用程序松耦合、异步处理模式、发布与订阅、最终一致性、错峰流控 和 日志缓冲 等。反之，如果需要 强一致性，关注业务逻辑的处理结果，则使用 RPC 显得更为合适。

1. 异步处理

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

1.2 具体场景
用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。
（1）串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信；

 

在这种方式下，需要最终发送验证短信后再返回给客户端。

（2）并行处理：新注册信息写入后，由发短信和发邮件并行处理；

 

在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。

假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：

串行：50+50+50=150ms 并行：50+50 = 100ms

若使用消息队列：

 

并在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍；

2. 应用耦合

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

2.2 具体场景
用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示：

 

该方法有如下缺点：
（1）人脸识别系统被调失败，导致图片上传失败；
（2）延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
（3）图片上传系统与人脸识别系统之间互相调用，需要做耦合；

若使用消息队列：

 

客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。

此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。

3. 流量削峰和流控

3.1 介绍
当上下游系统 处理能力存在差距的时候，利用 消息队列 做一个通用的 “漏斗”，进行 限流控制。在下游有能力处理的时候，再进行分发。

3.2 具体场景
用户在支付系统成功结账后，订单系统会通过短信系统向用