消息中间件之八股面试回答篇：三、RabbitMQ如何解决消息堆积问题（100万条消息堆积）+RabbitMQ高可用性和强一致性机制+回答模板

RabbitMQ中的消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

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

• 增加更多消费者，提高消费速度
• 在消费者内开启线程池加快消息处理速度
• 采用惰性队列，扩大队列容积，提高堆积上限

惰性队列

惰性队列的特征如下：

• 接收到消息后直接存入磁盘而非内存，所以可以支持数百万条的消息存储
• 消费者要消费消息时才会从磁盘中读取并加载到内存
• 性能较稳定，但是受限于磁盘IO，时效性会降低。

实现惰性队列只需要在声明队列的时候设置属性x-queue-mode为lazy。

面试不需要掌握，本人存档用的

声明队列时：

如果是用的注解的话，如下：

RabbitMQ高可用性和强一致性机制

RabbitMQ有三种集群模式：普通集群、镜像集群、仲裁队列

普通集群

普通集群，或者叫标准集群（classic cluster）
会在集群的各个节点间共享部分数据，包括：交换机、队列元信息（实际上就是队列的地址引用）。不包含队列中的消息。

所以队列所在节点宕机，队列中的消息就会丢失。为此出现了镜像集群。

镜像集群

镜像集群：本质是主从模式，具备下面的特征：

• 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
• 创建队列的节点被称为该队列的主节点，备份到的其它节点叫做该队列的镜像节点。
• 一个队列的主节点可能是另一个队列的镜像节点
• 所有操作都是主节点完成，然后同步给镜像节点
• 主节点宕机后，镜像节点会替代成新的主节点。
  

但是也可能出现主节点还未来得及同步数据给镜像节点就宕机，从而导致数据丢失的情况。虽然该情况概率比较小，但是某些情况我们需要保证数据的强一致性，为此出现了仲裁队列。

仲裁队列

仲裁队列是3.8版本以后才有的新功能，用来替代镜像队列，具备下列特征：

• 与镜像队列一样，都是主从模式，支持主从数据同步
• 使用非常简单，没有复杂的配置
• 主从同步基于Raft协议，强一致

其中的Raft协议就保证了数据的强一致性，不过与之相对的是性能会降低些。
目前使用最多的还是镜像集群。

问题及回答模板

如果有100万消息堆积在MQ , 如何解决 ?

回答：（背熟以下回答，大概用时1min）

我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解决方案也所有很多的。
第一，我们可以使用多线程消费任务。
第二，我们可以增加更多消费者，提高消费速度 。
第三，我们可以扩大队列容积，提高堆积上限 。譬如可以使用RabbitMQ惰性队列，惰性队列与普通队列不同的主要是：接收到消息后直接存入磁盘而非内存，只有消费者要消费消息时才会从磁盘中读取并加载到内存。基于这个性质，使得它可以支持数百万条的消息存储。

RabbitMQ的高可用机制有了解过嘛？、

回答：（背熟以下回答，大概用时1min）

候选人：

嗯，熟悉的~

我们当时项目在生产环境下，使用的集群，当时搭建是镜像模式集群，使用了3台机器。

镜像队列结构是一主多从，所有操作都是主节点完成，然后同步给镜像节点，如果主节点宕机后，镜像节点会替代成新的主节点，不过在主从同步完成前，主节点就已经宕机，可能出现数据丢失

面试官：那出现丢数据怎么解决呢？

候选人：

我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，保证了数据的强一致。并且使用起来也非常简单，不需要额外的配置，在声明队列的时候只要指定这个是仲裁队列即可。