消息中间件相关概念及使用场景

消息中间件相关概念及使用场景

微信搜索 zze_coding 或扫描 👉 二维码关注我的微信公众号获取更多资源推送:

概述

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

消息服务中两个重要概念:消息代理(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 的实现。

 JMSAMQP
定义Java API网络级协议
跨语言
跨平台
Model提供 2 种消息模型:
  1. Peer-2-Peer

  2. Pub/Sub

提供了 5 种消息模型:
  1. direct exchange

  2. fanout exchange

  3. topic exchange

  4. headers exchange

  5. system exchange

本质来讲,后四种和 JMS 的 Pub/Sub 模型没有太大区别,仅是在路由机制上做了更详细的区分。
支持消息类型多种消息类型:
  1. TextMessage

  2. MapMessage

  3. BytesMessage

  4. StreamMessage

  5. ObjectMessage

  6. Message(只有消息头和属性)

因其要支持跨语言跨平台,所以仅支持 byte[],当实际应用中有复杂的消息时,可以将消息序列化后发送。
综合HMS 定义了 Java API 层面的标准,在 Java 体系中,多个 client 均可通过 JMS 进行交互,不需要修改应用代码,但是其对跨平台支持较差。AMQP 定义了 wire-level 层的协议标准,天然具有跨平台、跨语言特性。

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

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

SpringBoot 自动配置类:

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

几种使用场景

异步处理

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

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

image.png

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

image.png

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

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

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

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

image.png

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

应用解耦

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

传统模式:

image.png

传统模式的缺点:

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

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

引入消息队列:

image.png

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

流量削锋

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

image.png

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

Copyright: 采用 知识共享署名4.0 国际许可协议进行许可

Links: https://www.zze.xyz/archives/mq-concept.html

Buy me a cup of coffee ☕.