RabbitMQ

1. RabbitMQ 基础

简介

RabbitMQ 使用场景：先执行紧要的操作，之后将消息发送到队列，由其他相关服务读取并慢慢执行。

优势：

减少用户等待时间：先执行紧要的操作
流量削峰：支付消息再多也会放到队列中，逐步地被读取
功能解耦，可拓展性强：需要添加功能时，监听队列即可

缺点：

时效性差，不能立即得到调用结果
不确定下游业务执行是否成功
业务安全依赖于消息代理（Broker）的可靠性

RabbitMQ 的整体架构及核心概念：

virtual-host：虚拟主机，作用是数据隔离。不同项目使用同一套 RabbitMQ 服务时不会冲突，因为不同 virtual-host 有各自的 exchange 和 queue
publisher：消息发送者
consumer：消息的消费者
queue：队列，存储消息
exchange：交换机，负责路由消息

在 RabbitMQ 控制台配置用户和对应的 exchange、queue：

SpringAMQP 如何收发消息?

引入spring-boot-starter-amqp 依赖
配置 rabbitmq 服务端信息
利用 RabbitTemplate 发送消息
利用 @RabbitListener 注解声明要监听的队列，监听消息

Work 模型

让多个消费者绑定到一个队列，共同消费队列中的消息，加快消息处理速度。同一条消息只会被一个消费者处理。

默认情况下，RabbitMQ 会依次轮询，将消息投递给绑定在队列上的每个消费者。但这并没有考虑到消费者是否已经处理完消息，可能出现消息堆积。解决方案是：修改 application.yml，设置 preFetch 值为 1。

真正生产环境都会经过exchange来发送消息，而不是直接发送到队列，交换机的类型有三种：Fanout（广播）、Direct（定向）、Topic（话题）

Fanout 交换机

Fanout Exchange 会将接收到的消息广播到每一个跟其绑定的 queue，所以也叫广播模式。

Direct 交换机

Direct Exchange 会将接收到的消息根据规则路由到指定的Queue，因此称为定向路由。

每一个 Queue 都与 Exchange 设置一个 BindingKey，发布者发送消息时，指定消息的 RoutingKey。

Exchange 将消息路由到 BindingKey 与消息 RoutingKey 一致的队列。

Topic 交换机

TopicExchange 与 DirectExchange 类似，区别在于 routingKey 可以是多个单词的列表，并且以.分割。BindingKey 可以使用通配符：# 表示 0 个或多个单词；* 表示 1 个单词

在代码中声明队列和交换机

声明队列和交换机------方式 1

SpringAMQP 提供了几个类，用来声明队列、交换机及其绑定关系：

Queue：用于声明队列，也可以用工厂类 QueueBuilder 构建队列
Exchange：用于声明交换机，也可以用工厂类 ExchangeBuilder 构建交换机
Binding：用于声明队列和交换机的绑定关系，也可以用工厂类 BindingBuilder 构建绑定关系

例如，声明一个 Fanout 类型的交换机，并且创建队列与其绑定：

这种声明和绑定方式有缺点，如 direct 类型的队列指定 routingkey 很繁琐：

声明队列和交换机------方式 2

SpringAMQP 还提供了基于 @RabbitListener 注解来声明队列和交换机的方式：

消息转换器

Spring 的对消息对象的处理是由 org.springframework.amgp.support.converter.MessageConverter 来处理的。而默认实现是 SimpleMessageConverter，基于 JDK 的 ObjectOutputStream 完成序列化。

存在下列问题：JDK 的序列化有安全风险，转换后的消息太长且可读性差。

建议采用 JSON 序列化代替默认的 JDK 序列化，要做两件事情：在 publisher 和 consumer 中都要引入 jackson 依赖：

在 publisher 和 consumer 中（可以在启动类中）都要配置 Messageconverter：

配置好之后，发的什么类型的消息就用什么类型接收：

在项目中使用 RabbitMQ

在 pom 文件中引入 amqp 依赖
在 ymal 文件中配置 mq 地址
SpringMVC 自带 jackson 依赖，所以无需引入，直接配置消息转换器
编写监听器（消费者）
编写消息发送方（生产者），也要引入 amqp 依赖并配置 mq 地址

2. RabbitMQ 高级

2.1 消息的可靠性

消息丢失的几种情况：向消息队列中发送消息时出现网络故障、消息队列本身出现故障、交易服务抛出异常

为了保证消息可靠性，就要保证发送者的可靠性、MQ 的可靠性、消费者的可靠性，并用延迟消息作为兜底。

2.1.1 生产者重连

有时，由于网络波动，可能会出现客户端连接 MQ 失败的情况。可以开启连接失败后的重连机制：

当网络不稳定的时候，利用重试机制可以有效提高消息发送的成功率。不过 SpringAMQP 提供的重试机制是阻塞式的重试，也就是说多次重试等待的过程中，当前线程是被阻塞的，会影响业务性能。

如果对于业务性能有要求，建议禁用重试机制。如果一定要使用，请合理配置等待时长和重试次数，当然也可以考虑使用异步线程来执行发送消息的代码。

2.1.2 生产者确认

RabbitMQ 有 Publisher Confirm 和 Publisher Return 两种确认机制。开启确机制认后，在 MQ 成功收到消息后会返回确认消息给生产者。返回的结果有以下几种情况：

消息投递到了 MQ，但是路由失败。此时会通过 PublisherReturn 返回路由异常原因，然后返回ACK，告知投递成功
临时消息投递到了 MQ，并且入队成功，返回 ACK，告知投递成功
持久消息投递到了 MQ，并且入队完成持久化，返回 ACK，告知投递成功
其它情况都会返回 NACK，告知投递失败

SpringAMQP 实现生产者确认

（1）在生产者的微服务 application.yml 中添加配置：

这里 publisher-confirm-type 有三种模式可选：

none：关闭 confirm 机制
simple：同步阻塞等待 MQ 的回执消息
correlated：异步等待 MQ 的回执消息

（2）编写回调函数：每个 RabbitTemplate 只能配置一个 ReturnCallback，因此需要在项目启动过程中配置

（3）发送消息，指定消息ID、消息 ConfirmCallback（每个消息发送时都单独指定）

如何处理生产者的确认消息?

生产者确认需要额外的网络和系统资源开销，尽量不要使用
如果一定要使用，无需开启 Publisher-Return 机制，因为一般路由失败是自己业务问题
对于 nack 消息可以有限次数重试，依然失败则记录异常消息

如何保证生产者发送消息的可靠性？

首先可以通过配置实现生产者的重连机制，当出现网络波动时尝试重新连接 MQ。

如果其他原因导致失败，可以开启生产者确认机制，当发送消息到 MQ 时，MQ 就会给出回执。若回执是 ACK 则发送成功；若回执是 NACK 则发送失败，此时可以重发消息。通过以上手段，就能基本保证生产者消息的可靠性，但是会增加系统开销。因此，除非对消息可靠性有较高要求，否则基本不采用。

2.2 MQ 的可靠性

在默认情况下，RabbitMQ 会将接收到的信息保存在内存（内存快，降低消息收发的延迟）。这样会导致两个问题：

一旦 MQ 宕机，内存中的消息会丢失
内存空间有限，当消费者故障或处理过慢时，会导致 MQ 中消息积压

保证 MQ 的可靠性有两种方式：数据持久化 和 Lazy Queue，MQ 3.6 之前采用前者，之后有了后者。

2.2.1 数据持久化

RabbitMQ 实现数据持久化包括 3 个方面：

（1）交换机持久化

（2）队列持久化

在 Spring 中创建交换机和队列时会默认创建持久化的交换机和队列。

（3）消息的持久化

如果没有消息持久化，当 MQ 中消息过多时还是会将消息放入磁盘，此时 MQ 是阻塞的，无法处理消息。

2.2.2 Lazy Queue

从 RabbitMQ 的 3.6.0 版本开始，就增加了 Lazy Queue 的概念，也就是惰性队列。惰性队列的特征如下：

接收到消息后直接存入磁盘（内存中只保留最近的消息，默认 2048 条）
消费者要消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储

在 3.12 版本后，所有队列都是 Lazy Queue 模式，无法更改。

要设置一个队列为惰性队列，只需要在声明队列时，指定 x-queue-mode 属性为 lazy 即可：

RabbitMQ 如何保证消息的可靠性？

首先通过配置可以让交换机、队列、以及发送的消息都持久化。这样队列中的消息会持久化到磁盘，MQ重启消息依然存在；
RabbitMQ 在 3.6 版本引入了 LazyQueue，并且在 3.12 版本后成为队列的默认模式。LazyQueue 会将所有消息都持久化；
开启持久化和生产者确认时，RabbitMQ 只有在消息持久化完成后才会给生产者返回 ACK 回执。

2.3 消费者的可靠性

2.3.1 消费者确认机制

为了确认消费者是否成功处理消息，RabbitMQ 提供了消费者确认机制。当消费者处理消息结束后，应该向 RabbitMQ 发送一个回执，告知 RabbitMQ 自己的消息处理状态。回执有三种可选值：

ack：成功处理消息，RabbitMQ 从队列中删除该消息
nack：消息处理失败，RabbitMQ 需要再次投递消息
reject：消息处理失败并拒绝该消息（如：消息格式错误），RabbitMQ 从队列中删除该消息

SpringAMQP 已经实现了消息确认功能。并允许我们通过配置文件选择 ACK 处理方式，有三种方式：

none：不处理。即消息投递给消费者后立刻 ack，消息会立刻从 MQ 删除。非常不安全，不建议使用
manual：手动模式。需要自己在业务代码中调用 api，发送 ack 或 reject，存在业务入侵，但更灵活
auto（常用） ：自动模式。SpringAMQP 利用 AOP 对我们的消息处理逻辑做了环绕增强，当业务正常执行时则自动返回 ack。当业务出现异常时，根据异常判断返回不同结果：
- 如果是业务异常，会自动返回 nack
- 如果是消息处理或校验异常（如：消息格式错误），自动返回 reject

2.3.2 消费失败处理

当消费者出现异常后，消息会不断 requeue（重新入队）到队列，再重新发送给消费者，然后再次异常，再次 requeue，无限循环，导致 mq 的消息处理飙升，带来不必要的压力。

可以利用 Spring 的 retry 机制，在消费者出现异常时利用本地重试，而不是无限制的 requeue 到 mq 队列：

失败消息处理策略：在开启重试模式后，重试次数耗尽时消息依然失败，则需要有MessageRecoverer 接口来处理，它包含三种不同的实现：

RejectAndDontRequeueRecoverer：重试耗尽后，直接 reject，丢弃消息。默认就是这种方式
ImmediateRequeueMessageRecoverer：重试耗尽后，返回 nack，消息重新入队
RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机（最优）

消费者如何保证消息一定被消费?

开启消费者确认机制为 auto，由 spring 确认消息处理成功后返回 ack，异常时返回 nack
开启消费者失败重试机制，并设置 MessageRecoverer 多次重试失败后将消息投递到异常交换机，交由人工处理

2.3.3 业务幂等性

如果一个消息被消费者消费之后，将要返回 ack 时发生了网络波动，那么就可能导致消息重发，消息被消费多次。这显然不合理。

幂等是一个数学概念，用函数表达式来描述是这样的：f(x) = f(f(x))。在程序开发中，则是指同一个业务，执行一次或多次对业务状态的影响是一致的。

方案一：唯一消息 id：给每个消息都设置一个唯一 id，利用 id 区分是否是重复消息：

每一条消息都生成一个唯一的 id，与消息一起投递给消费者。
消费者接收到消息后处理自己的业务，业务处理成功后将消息 ID 保存到数据库。
如果下次又收到相同消息，去数据库查询判断是否存在，存在则为重复消息放弃处理。

方案二：基于业务判断：结合业务逻辑，基于业务本身做判断。以支付业务为例：我们要在支付后修改订单状态为已支付，应该在修改订单状态前先查询订单状态，判断状态是否是未支付。只有未支付订单才需要修改，其它状态不做处理：

如何保证支付服务与交易服务之间的订单状态一致性?

首先，支付服务会正在用户支付成功以后利用 MQ 消息通知交易服务完成订单状态同步。
其次，为了保证 MQ 消息的可靠性，采用了生产者确认机制、消费者确认、消费者失败重试等策略，确保消息投递和处理的可靠性。同时也开启了 MQ 的持久化，避免因服务宕机导致消息丢失。
最后，还在交易服务更新订单状态时做了业务幂等判断，避免因消息重复消费导致订单状态异常。

如果交易服务消息处理失败，有没有什么兜底方案?

可以在交易服务中设置定时任务，定期查询订单支付状态。这样即便 MQ 通知失败，还可以利用定时任务作为兜底方案，确保订单支付状态的最终一致性。

2.4 延迟消息

延迟消息：生产者发送消息时指定一个时间，消费者不会立刻收到消息,而是在指定时间之后才收到消息。

延时消息有多种实现方案：死信交换机、延迟消息插件

2.4.1 死信交换机

当一个队列中的消息满足下列情况之一时，就会成为死信（dead letter)：

消费者使用 basic.reject 或 basic.nack 声明消费失败，并且消息的 requeue 参数设置为 false
消息是一个过期消息（达到了队列或消息本身设置的过期时间)，超时无人消费
要投递的队列消息堆积满了，最早的消息可能成为死信

如果队列通过 dead-letter-exchange 属性指定了一个交换机，那么该队列中的死信就会投递到这个交换机中。这个交换机称为死信交换机（Dead Letter Exchange，简称 DLX）。

死信交换机的方式实现起来比较繁琐。

2.4.2 延迟消息插件

RabbitMQ 的官方也推出了一个插件，支持延迟消息功能。该插件的原理是设计了一种支持延迟消息功能的交换机，当消息投递到交换机后可以暂存一定时间，到期后再投递到队列。

发送消息时需要通过消息头 x-delay 来设置延迟时间：

使用延迟消息插件会使服务有一定的性能损耗，因为设置了延迟时间，CPU 要不断计算。这种方案适用于延迟时间较短的情况。