概述
大多数应用中,可通过消息服务中间件来提升系统异步通信、扩展解耦的能力。
消息服务中两个重要概念:消息代理(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 种消息模型:
| 提供了 5 种消息模型:
|
支持消息类型 | 多种消息类型:
| 因其要支持跨语言跨平台,所以仅支持 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 倍。
应用解耦
场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。
传统模式:
传统模式的缺点:
-
假如库存系统无法访问,则订单减库存将失败,从而导致订单失败。
-
订单系统与库存系统耦合。
引入消息队列:
- 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。
- 库存系统:订阅下单的消息,采用拉/推的方式,获取下单信息,库存系统根据下单信息,进行库存操作。
- 假如:在下单时库存系统不能正常使用。也不影响正常下单,因为下单后,订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。
流量削锋
场景说明:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要在应用前端加入消息队列。
- 可以控制活动的人数。
- 可以缓解短时间内高流量压垮应用。
- 用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面。
- 秒杀业务根据消息队列中的请求信息,再做后续处理。
评论区