这两天在针对项目过程使用的RabbitMQ得学习文档整理的过程中，发现还遗漏了RabbitMQ的就集群原理的系统的分析的文档，这个就比较尴尬了，正好最近在整理RabbitMQ的集群的搭建，那我们今天就聊聊RabbitMQ的集群的相关原理

RabbitMQ的优缺点

在正式的聊聊集群的原理之前，我们先简单了解下RabbitMQ的优缺点，然后为什么要使用RabbitMQ的集群模式，他能为我们解决那些问题，各种不同的集群模式有什么区别，又有什么优缺点；

RabbitMQ的优缺点

RabbitMQ的优点，我在Centos7下RabbitMQ的搭建其实已经介绍过了，无外乎三大点：解耦、削峰、异步通讯等，我们这里简单提下，但是相对于优点来说，RabbitMQ同样也有缺点：

1. 增加了系统应用的复杂性
2. RabbitMQ服务如果出现问题，则整个服务将会瘫痪
3. 新增了很多异常情况的处理， 比如消息丢失、消息消费失败， 消息重复消费等
4. RabbitMQ服务在高并发情况下很容易出现性能瓶颈，进而影响整个系统的运行

其中1和3的问题都可以通过代码和配置来解决，但是问题2和4就不好解决了，为了解决上面的问题，就出现了RabbitMQ服务的集群

RabbitMQ两种集群

普通集群

什么是普通集群呢？ 就是在多个联通的服务器上安装不同的RabbitMQ的服务，这些服务器上的RabbitMQ服务组成一个个节点，通过RabbitMQ内部提供的命令或者配置来构建集群，形成了RabbitMQ的普通集群模式

image

• 当用户向服务注册一个队列，该队列会随机保存到某一个服务节点上，然后将对应的元数据同步到各个不同的服务节点上
• RabbitMQ的普通集群模式中，每个RabbitMQ都保存有相同的元数据
• 用户只需要链接到任一一个服务节点中，就可以监听消费到对应队列上的消息数据
• 但是RabbitMQ的实际数据却不是保存在每个RabbitMQ的服务节点中，这就意味着用户可能联系的是RabbitMQ服务节点C，但是C上并没有对应的实际数据，也就是说RabbitMQ服务节点C，并不能提供消息供用户来消费，那么RabbitMQ的普通集群模式如何解决这个问题呢？
• RabbitMQ服务节点C发现自己本服务节点并没有对应的实际数据后，因为每个服务节点上都会保存相同的元数据，所以服务节点C会根据元数据，向服务节点B（该服务节点上有实际数据可供消费）请求实际数据，然后提供给用户进行消费
• 这样给用户的感觉就是，在RabbitMQ的普通集群模式中，用户连接任一服务节点都可以消费到消息
  -普通集群模式的优点：提高消费的吞吐量

普通集群模式的原理比较简单，但是并不能真正意义上的实现高可用，他也存在以下的以下缺点：

1. 为了请求RabbitMQ的实际数据以提供给用户，可能会在RabbitMQ内部服务节点之间进行频繁的进行数据交互，这样的交互比较耗费资源
2. 当其中一个RabbitMQ的服务节点宕机了，那么该节点上的实际数据就会丢失，用户再次请求时，就会请求不到数据，系统的功能就会出现异常

那么该怎么解决上述的问题呢？

镜像集群模式

为了解决上面普通模式的两个显著的缺点，RabbitMQ官方提供另外一种集群模式：镜像集群模式

image

镜像集群模式和普通集群模式大体是一样的，不一样的是：

• 生产者向任一服务节点注册队列，该队列相关信息会同步到其他节点上
• 任一消费者向任一节点请求消费，可以直接获取到消费的消息，因为每个节点上都有相同的实际数据
• 任一节点宕机，不影响消息在其他节点上进行消费

镜像集群模式是怎么开启的呢？这里简单说下，在普通集群模式的基础上，我们可以通过web控制端来配置数据的同步策略，可以配置同步所有的节点，也可以配置同步到指定数量的服务节点

虽然镜像集群模式能够解决普通集群模式的缺点，当任一节点宕机了，不能正常提供服务了，也不影响该消息的正常消费，但是其本身也有相应的缺点：

1. 性能开销非常大，因为要同步消息到对应的节点，这个会造成网络之间的数据量的频繁交互，对于网络带宽的消耗和压力都是比较重的
2. 没有扩展可言，rabbitMQ是集群，不是分布式的，所以当某个Queue负载过重，我们并不能通过新增节点来缓解压力，因为所以节点上的数据都是相同的，这样就没办法进行扩展了

对于镜像集群而言，当某个queue负载过重，可能会导致集群雪崩，那么如何来减少集群雪崩呢？我们可以通过HA的同步策略来实现

HA的同步策略如下：