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协议保证强 一致性，代替镜像集群