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

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

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

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

在传统的同步模式下，客户端发送请求后必须等待服务器响应才能继续执行后续操作；
而在异步模式下，客户端发送请求后无需等待，可以立即返回并执行其他任务，服务器处理完请求后再通知客户端结果。

MQ如何实现异步处理：

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

MQ如何实现解耦：

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

MQ如何实现削峰填谷：

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

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

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），并且超过了这个时间限制，消息就会变为死信。
队列达到最大长度：如果消息队列达到了最大长度限制，新的消息将无法加入队列，这时这些新消息也会变成死信。

消息丢失场景：

生产端消息可靠性保证：

消息持久化：
当生产者发布消息时,可以选择将其标记为持久化到磁盘上。
确认（Confirm）机制：
开启confirm回调模式后，RabbitMQ会在消息成功写入到磁盘并至少被一个交换器接受后，向生产者发送一个确认（acknowledgement）。

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

消费端消息可靠性保证：

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

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

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

单个队列与单一消费者:

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