RabbitMQ使用场景：
- 异步发送（验证码、短信、邮件…）
- MYSQL和Redis, ES之间的数据同步
- 分布式事务
- 削峰填谷
1. 消息可靠性（不丢失）
消息丢失场景：
RabbitMQ-如何保证消息不丟失？
- 开启生产者确认机制，确保生产者的消息能到达队列
- 开启持久化功能，确保消息未消费前在队列中不会丢失
- 开启消费者确认机制为auto，由spring确认消息处理成功后完成ack
- 开启消费者失败重试机制，多次重试失败后将消息投递到异常交换机，交由人工处理
1.1 生产者确认
防止在传输过程中消息丢失（生产者导致消息丢失）
1.2 消息持久化
保证MQ宕机后消息不丢失
1.3 消费者确认
防止消费者宕机后未处理导致消息丢失（消费者导致消息丢失）
2. 解决消息重复消费
消息重复消费场景：
- 网络抖动
- 消费者挂了
解决方案（适用于任何消息中间件）： - 每条消息设置一个唯一的标识id
- 幂等方案：【分布式锁、数据库锁（悲观锁、乐观锁）】
在处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果己经存在这个数据了，就说明消息重复消费了，就不需要再消费了。
3. 死信交换机（延迟队列）
延迟队列=死信交换机＋TTL（生存时间）
使用场景：
- 延迟队列：进入队列的消息会被延迟消费的队列
- 场景：超时订单（购票、下单）、限时优惠、定时发布
3.1 死信交换机
当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：
- 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
- 消息是一个过期消息，超时无人消费
- 要投递的队列消息堆积满了，最早的消息可能成为死信
如果该队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）。
3.2 TTL
TTL，也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，ttl超时分为两种情况：
- 消息所在的队列设置了存活时间
- 消息本身设置了存活时间（以最短延迟时间为准）
3.3 延迟队列插件
DelayExchange插件，需要安装在尽abbitMQ中
RabbitMQ有一个官方的插件社区，地址为:https://www.rabbitmq.com/community-plugins.html
4. 解决消息堆积
当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题
解决消息堆积有三种种思路：
- 增加更多消费者，提高消费速度
- 在消费者内开启线程池加快消息处理速度（因为是利用cpu，所以考虑硬件）
- 扩大队列容积，提高堆积上限
4.1 惰性队列
特征：
- 接收到消息后直接存入磁盘而非内存
- 消费者要消费消息时才会从磁盘中读取并加载到内存
- 支持数百万条的消息存储
实现： - 在声明队列的时候可以设置属性x-queue-mode为lazy，即为惰性队列
- 基于磁盘存储，消息上限高
- 性能比较稳定，但基于磁盘存储，受限于磁盘I0，时效性会降低
5. 高可用机制（集群）
在生产环境下，使用集群来保证高可用性：
- 普通集群
- 镜像集群
- 仲裁队列
5.1 普通集群
节点宕机导致消息丢失，无法保证高可用
5.2 镜像集群
解决普通集群节点宕机导致消息丢失的问题，从而保证高可用
局限性：镜像节点未来得及从主节点同步数据，主节点就挂掉
5.3 仲裁队列
主从同步基于Raft协议保证强 一致性，代替镜像集群
