使用RabbitMQ有什么好处？
异步处理
解耦
流量削峰
RabbitMQ 结构（如何发送消息？）
整体结构如下图所示：
结构介绍
Server：又称为broker，接受客户端连接，RabbitMQ 节点；
Connection：连接，应用程序与brokder建立网络连接;
channel：网络通道，几乎所有的操作都是在channel中进行的，是进行消息对象的通道，客户端可以建立 多个通道，每一个channel表示一个会话任务
Virtual Host：虚拟机，一个节点由若干个虚拟机组成；
Exchange：交换机，一个虚拟机由若干个交换机组成；
Queue：消息队列，和交换机通过routing key绑定
发送消息流程
生产者把生产的消息通过channel发送到Exchange上，Exchange通过绑定的router key来选择Queue，消费者监听到Queue上有新的消息，就消费调此消息；
如何保证消息不丢失？（可靠性）
首先搞清楚消息丢失会在哪些场景？其实在发送消息的每一个场景都会发生消息丢失情况：
- 生产者发送消息时，有可能没发送到MQ；
- 消息到达MQ了，但是MQ宕机，消息丢失；
- 消费者消费消息时，消费者宕机；
那么对应解决办法如下：
- 生产者发送消息确认机制，确认消息发送到MQ
- MQ开启持久化，确保消息未消费前在队列中不丢失（交换机持久化、队列持久化、消息持久化）
- 消费者确认机制
- 开启消费者失败重试机制，多次重试失败投递异常交换机
如何解决消息重复消费问题？（消息幂等性）
给每条消息设置一个唯一的标识id
其他解决方案
利用数据库唯一约束：消费数据写入数据库，可以先根据主键查询数据是否已经存在，如果已经存在了就没必要插入了。或者直接插入也没问题，因为可以利用主键的唯一性来保证数据不会重复插入，重复插入只会报错，但不会出现脏数据
还有其他解决方案，后续遇到会进行补充~~~
介绍 MQ 中延时队列？（死信交换机）
利用TTL结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。这种消息模式就称为延迟队列（Delay Queue）模式
延迟队列 = 死信交换机 + TTL(生存时间)
使用场景：
● 延迟发送短信
● 用户下单，如果用户在15 分钟内未支付，则自动取消
● 预约工作会议，20分钟后自动通知所有参会人员
● 定时发布抖音作品
死信交换机
满足下面条件之一就被称为死信：
- 消费者拒绝消费
- 超时未消费
- 消息堆积满了，最早的消息成为死信
图解：
代码实现：
TTL
看如下代码，就是消息设置了过期时间：
延迟队列插件
需要保证 RabbitMQ 已经安装了插件，这里不展开叙述。具体可以谷歌一下
如何解决消息堆积问题？
消息堆积发生原因是什么？是因为生产者发送消息过快，而消费者不能及时消费，导致消息堆积。那么解决办法如下：
- 增加消费者进行消费
- 消费者方可以添加线程池加快消息处理速度
- 使用惰性队列，可以在MQ中保存更多消息
惰性队列特征：
- 接收到消息后直接存入磁盘而不是内存
- 消费者消费消息时才会从磁盘中读取并加载到内存
- 支持数百万条的消息存储
惰性队列优点：
- 基于磁盘存储，消息上限高
- 没有间歇性page-out，性能稳定
惰性队列缺点：
- 由于存储在磁盘，消息时效性会降低
- 性能受限于磁盘的IO
惰性队列使用：
RabbitMQ 高可用机制？(集群模式)
普通集群（不采用）
镜像集群
仲裁队列
参考链接
https://blog.csdn.net/zw791029369/article/details/109561457
https://www.bilibili.com/video/BV1yT411H7YK?p=58
