RabbitMQ中的消息堆积问题
当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。
解决消息堆积有三种种思路：
- 增加更多消费者，提高消费速度
- 在消费者内开启线程池加快消息处理速度
- 采用惰性队列，扩大队列容积，提高堆积上限
惰性队列
惰性队列的特征如下：
- 接收到消息后直接存入磁盘而非内存，所以可以支持数百万条的消息存储
- 消费者要消费消息时才会从磁盘中读取并加载到内存
- 性能较稳定，但是受限于磁盘IO，时效性会降低。
实现惰性队列只需要在声明队列的时候设置属性x-queue-mode为lazy。
面试不需要掌握，本人存档用的
声明队列时：
如果是用的注解的话，如下：
RabbitMQ高可用性和强一致性机制
RabbitMQ有三种集群模式：普通集群、镜像集群、仲裁队列
普通集群
普通集群，或者叫标准集群（classic cluster）
会在集群的各个节点间共享部分数据，包括：交换机、队列元信息（实际上就是队列的地址引用）。不包含队列中的消息。
所以队列所在节点宕机，队列中的消息就会丢失。为此出现了镜像集群。
镜像集群
镜像集群：本质是主从模式，具备下面的特征：
- 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
- 创建队列的节点被称为该队列的主节点，备份到的其它节点叫做该队列的镜像节点。
- 一个队列的主节点可能是另一个队列的镜像节点
- 所有操作都是主节点完成，然后同步给镜像节点
- 主节点宕机后，镜像节点会替代成新的主节点。
但是也可能出现主节点还未来得及同步数据给镜像节点就宕机，从而导致数据丢失的情况。虽然该情况概率比较小，但是某些情况我们需要保证数据的强一致性，为此出现了仲裁队列。
仲裁队列
仲裁队列是3.8版本以后才有的新功能，用来替代镜像队列，具备下列特征：
- 与镜像队列一样，都是主从模式，支持主从数据同步
- 使用非常简单，没有复杂的配置
- 主从同步基于Raft协议，强一致
其中的Raft协议就保证了数据的强一致性，不过与之相对的是性能会降低些。
目前使用最多的还是镜像集群。
问题及回答模板
如果有100万消息堆积在MQ , 如何解决 ?
回答：（背熟以下回答，大概用时1min）
我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解决方案也所有很多的。
第一，我们可以使用多线程消费任务。
第二，我们可以增加更多消费者，提高消费速度 。
第三，我们可以扩大队列容积，提高堆积上限 。譬如可以使用RabbitMQ惰性队列，惰性队列与普通队列不同的主要是：接收到消息后直接存入磁盘而非内存，只有消费者要消费消息时才会从磁盘中读取并加载到内存。基于这个性质，使得它可以支持数百万条的消息存储。
RabbitMQ的高可用机制有了解过嘛？、
回答：（背熟以下回答，大概用时1min）
候选人：
嗯，熟悉的~
我们当时项目在生产环境下，使用的集群，当时搭建是镜像模式集群，使用了3台机器。
镜像队列结构是一主多从，所有操作都是主节点完成，然后同步给镜像节点，如果主节点宕机后，镜像节点会替代成新的主节点，不过在主从同步完成前，主节点就已经宕机，可能出现数据丢失
面试官：那出现丢数据怎么解决呢？
候选人：
我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，保证了数据的强一致。并且使用起来也非常简单，不需要额外的配置，在声明队列的时候只要指定这个是仲裁队列即可。
