Java后端面试题(mq相关)(day9)

[为什么用MQ？异步、削峰、解耦](#为什么用MQ？异步、削峰、解耦)
- [1. 异步处理](#1. 异步处理)
- [2. 解耦](#2. 解耦)
- [3. 削峰填谷](#3. 削峰填谷)
Exchange类型
什么是死信队列？
如何保证消息的可靠性？
RabbitMQ中如何解决消息堆积问题?
RabbitMQ中如何保证消息有序性?
如何防止消息重复消费？(如何保证消息幂等性)

为什么用MQ？异步、削峰、解耦

MQ（Message Queue，消息队列）是一种在分布式系统中进行消息传递的技术，它主要用于实现服务间的解耦、异步处理 、削峰填谷等功能。下面我将分别解释这几个概念，并说明它们是如何通过MQ实现的。

1. 异步处理

异步处理是指一个操作不需要等待另一个操作完成就可以继续执行的过程。

在传统的同步模式下，客户端发送请求后必须等待服务器响应才能继续执行后续操作；

而在异步模式下，客户端发送请求后无需等待，可以立即返回并执行其他任务，服务器处理完请求后再通知客户端结果。

MQ如何实现异步处理：

当客户端向服务端发送请求时，该请求不是直接被服务端处理，而是先存入MQ中。
服务端从MQ中获取请求消息后进行处理，客户端无需等待服务端处理完成即可继续执行其他任务。
这种方式提高了系统的响应速度和吞吐量，使得系统能够处理更多的并发请求。

2. 解耦

解耦是指降低系统各组件之间的依赖性，使得每个组件都可以独立地开发、部署和扩展。这有助于提高系统的灵活性和可维护性。

MQ如何实现解耦：

发送方将消息发送到MQ中，而接收方从MQ中读取消息。这样发送方和接收方之间就不存在直接的调用关系。
即使接收方暂时不可用，发送方也可以继续发送消息，因为消息会被暂存在MQ中，直到接收方恢复可用。
发送方和接收方可以独立扩展，而不影响彼此的工作。

3. 削峰填谷

削峰填谷是指通过缓存、异步处理等手段来平衡系统的负载，避免高峰期系统过载或低谷期资源浪费的情况。

MQ如何实现削峰填谷：

在高流量期间，系统产生的大量消息会被存入MQ中，而不是直接由后端服务处理。这可以防止后端服务因短时间内处理大量请求而过载。
当流量高峰过去后，后端服务可以从MQ中慢慢消费这些消息，从而平衡处理过程，确保服务质量。
通过这种方式，系统能够在高峰期吸收额外的请求，在低谷期释放资源，从而达到资源的有效利用。

综上所述，MQ作为一种重要的中间件技术，对于提升系统的性能、稳定性和可扩展性具有重要作用。

Exchange类型

常用的交换机有以下三种，因为消费者是从队列获取信息的，队列是绑定交换机的，所以对应的消息推送/接收模式也会有以下几种：

Direct Exchange
直连型交换机 ，根据RoutingKey（路由键）路由到不同的队列
Fanout Exchange
扇型（广播）交换机 ，这个交换机没有路由键概念，就算你绑了路由键也是无视的。这个交换机在接收到消息后，会直接转发到绑定到它上面的所有队列。
Topic Exchange
主题交换机 ，这个交换机其实跟直连交换机流程差不多，但是它的特点就是在它的路由键和绑定键之间是有规则的。
简单地介绍下规则：

* (星号) 用来表示一个或多个字符

# (井号) 用来表示任意数量的字符

什么是死信队列？

死信（Dead Letter）:是指在消息队列系统中那些无法被正常消费的消息。
死信队列（Dead Letter Queue, DLQ）：当消息无法被正常处理时，也就是死信，可以将这些死信发送到一个专门的队列中，以便于后续检查和处理

以下是一些可能导致消息成为死信的情况：

消息被拒绝访问：消费者显式地拒绝了消息（使用 channel.BasicNack 或 channel.BasicReject 方法），并且设置了 requeue 参数为 false，这意味着消息不应该被重新放回原队列。
消费者发生异常，超过重试次数。（其实spring框架调用的就是 basicNack）
消息过期：如果消息设置了生存时间（Time To Live, TTL），并且超过了这个时间限制，消息就会变为死信。
队列达到最大长度：如果消息队列达到了最大长度限制，新的消息将无法加入队列，这时这些新消息也会变成死信。

如何保证消息的可靠性？

消息丢失场景：

消息到 MQ 的过程中搞丢
MQ 自己搞丢
MQ 到消费过程中搞丢。

生产端消息可靠性保证：

消息持久化：

当生产者发布消息时,可以选择将其标记为持久化到磁盘上。
确认（Confirm）机制：

开启confirm回调模式后，RabbitMQ会在消息成功写入到磁盘并至少被一个交换器接受后，向生产者发送一个确认（acknowledgement）。

若消息丢失或无法投递给任何队列，RabbitMQ将会发送一个否定确认（nack). 生产者可以根据这些确认信号判断消息是否成功送达并采取相应的重试策略。

消费端消息可靠性保证：

消息确认（Acknowledgements）：
1. 手动应答：代码冗余多，容易出现死循环。
2. 自动应答：开启重试功能，发生错误时重新发送，可配置死信队列，重试一定次数后放入死信队列。
死信队列（Dead Letter Queue）：

RabbitMQ中如何解决消息堆积问题?

解决消息堆积有三种种思路:

扩大队列容积，提高堆积上限，采用惰性队列
1. 在声明队列的时候可以设置属性x-queue-mode为lazy，即为惰性队列
2. 基于磁盘存储，消息上限高
3. 性能比较稳定，但基于磁盘存储，受限于磁盘I0，时效性会降低
增加更多消费者，提高消费速度**（不能保证有序性）**
在消费者内开启线程池加快消息处理速度**（不能保证有序性）**

RabbitMQ中如何保证消息有序性?

单个队列与单一消费者:

单个队列：将所有需要保持有序的消息发送到同一个队列中。RabbitMQ的队列是先进先出（FIFO）的数据结构，消息在被发送到队列之后，会按照发送的顺序被排列在队列中。
单一消费者：确保该队列只被一个消费者（单线程）处理。这样，消费者会按照队列中的顺序接收到消息，并依次处理，从而保证了消息的顺序性。

如何防止消息重复消费？(如何保证消息幂等性)

幂等性指的是一个操作无论执行多少次，其结果都是相同的。

在分布式系统和消息队列中，幂等性特别重要，因为它可以确保即使在消息重复发送或处理过程中出现故障的情况下，系统状态的一致性和数据的完整性。

生产端保证消息的幂等性：

状态检查：
在消息发送前，先查询数据库，确认此消息是否已被处理过（一般通过单据状态）。如果是，则直接忽略；否则，继续处理，并在处理完成后更新消息状态为已处理。

消费端保证消息的幂等性：

唯一标识：每个消息都携带一个业务ID（BizId），如订单号、交易流水号等，以便在消费端能够识别重复的消息。