概述

大多数应用中，可通过消息服务中间件来提升系统异步通信、扩展解耦的能力。

消息服务中两个重要概念：消息代理（message broker）和目的地（destination）。当消息发送者发送消息后，将由消息代理接管，消息代理保证消息传递到指定目的地。

消息队列主要有两种形式的目的地：

• 队列（queue）：点对点消息通信（point-to-point）。
• 主题（topic）：发布（publish）/订阅（subscribe）消息通信。

点对点：

• 消息发送者发送消息，消息代理将其放入一个队列中，消息接收者从队列中获取消息内容，消息读取后被移出队列。
• 消息只有唯一的发送者和接收者，但并不是只能有一个接收者。

发布/订阅：

发送者（发布者）发送消息到主题，多个接收者（订阅者）监听（订阅）这个主题，那么就会在消息到达时同时接收到消息。

两种规范

JMS（Java Message Service）：

• Java 消息服务，基于 JVM 消息代理的规范。ActiveMQ、HornetMQ 是 JMS 的实现。

AMQP（Advanced Message Queuing Protocol）：

• 高级消息队列协议，也是一个消息代理的规范，兼容 JMS。

• RabbitMQ 是 AMQP 的实现。

	JMS	AMQP
定义	Java API	网络级协议
跨语言	否	是
跨平台	否	是
Model	提供 2 种消息模型： Peer-2-Peer Pub/Sub	提供了 5 种消息模型： direct exchange fanout exchange topic exchange headers exchange system exchange 本质来讲，后四种和 JMS 的 Pub/Sub 模型没有太大区别，仅是在路由机制上做了更详细的区分。
支持消息类型	多种消息类型： TextMessage MapMessage BytesMessage StreamMessage ObjectMessage Message（只有消息头和属性）	因其要支持跨语言跨平台，所以仅支持 byte[],当实际应用中有复杂的消息时，可以将消息序列化后发送。
综合	HMS 定义了 Java API 层面的标准，在 Java 体系中，多个 client 均可通过 JMS 进行交互，不需要修改应用代码，但是其对跨平台支持较差。	AMQP 定义了 wire-level 层的协议标准，天然具有跨平台、跨语言特性。

spring-jms 提供了对 JMS 的支持。

• spring-rabbit 提供了对 AMQP 的支持。
• 需使用 ConnectionFactory 的实现来连接消息代理。
• 提供 JmsTemplate、RabbitTemplate 来操作消息。
• @JmsListener（JMS）和 @RabbitListener（AMQP）注解标注在方法上可监听消息代理发布的消息。
• @EnableJms、@EnableRabbit 开启支持。

SpringBoot 自动配置类：

• JMS 的自动配置类为 JmsAutoConfiguration。
• AMQP 的自动配置类为 RabbitAutoConfiguration。

几种使用场景

异步处理

场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种：串行方式、并行方式。

1、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。

2、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。

假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是 150 毫秒，并行的时间可能是 100 毫秒。

因为 CPU 在单位时间内处理的请求数是一定的，假设 CPU1 秒内吞吐量是 100 次。则串行方式 1 秒内 CPU 可处理的请求量是 7 次（1000/150）。并行方式处理的请求量是 10 次（1000/100）。

如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）很容易达到瓶颈。

3、引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：

按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒 20 QPS。比串行提高了 3 倍，比并行提高了 2 倍。

应用解耦

场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。

传统模式：

传统模式的缺点：

• 假如库存系统无法访问，则订单减库存将失败，从而导致订单失败。

• 订单系统与库存系统耦合。

引入消息队列：

• 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。
• 库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
• 假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

流量削锋

场景说明：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

• 可以控制活动的人数。
• 可以缓解短时间内高流量压垮应用。
• 用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
• 秒杀业务根据消息队列中的请求信息，再做后续处理。