- RabbitMQ一共有3种模式，分别是：单机模式、普通集群模式和镜像集群模式。通过不同的集群模式，我们来了解一下对高可用支持的情况都是如何的？
【单机模式】
- 单机模式就比较简单了，就是我们当最初要接触RabbitMQ的时候，为了快速了解到它的使用方式和特性，可以从官网下载一个RabbitMQ包安装到本机，在线上环境中，是不会采用这种方式的。也根本不存在高可用性了。
【普通集群模式】
- 在普通模式中，会在N台机器上部署N个RabbitMQ，但是创建的Queue只会在其中的一台机器上，然后N个RabbitMQ直接同步Queue的元数据信息，通过这个元数据信息，就可以找到创建了Queue的那台机器的MQ实例，当有消费者要消费消息的时候，如果请求到了没有Queue的那个实例，那么它会通过Queue的元数据信息将请求转发到Queue所在的那个实例，并将数据拉取出来。
- 这种方式其实并不是真正的分布式，因为每次随机请求到N个RabbitMQ实例上，最终都 是需要从Queue所在的实例上获取数据，如果这个实例挂掉了，那么就出现了单点故障，使得整个普通集群模式无法对外提供服务。
- 那么这种方案并不会提升MQ的高可用性，但是可以比单机模式提高一定的吞吐量。不过Queue所在的MQ实例会是最终的性能瓶颈。
- 图例：
【镜像集群模式】
- 镜像集群模式跟普通集群模式相同的点就是N台机器上部署N个RabbitMQ实例，但是，与其不同的是，Queue和元数据信息都会存在于这N个RabbitMQ实例上，也就是说，每个RabbitMQ的节点上面都会存在全量的数据。当生产者每次发送消息到MQ集群的时候， 这个消息都会被同步到多个RabbitMQ实例上。
- 这种模式的好处可以提高集群的高可用性，并且即使有机器宕机了，那么由于其他RabbitMQ的实例依然都保存有全量的数据，所以，也不会有什么问题。
- 但是缺点是，由于MQ每次接收到消息后，都需要同步给其他实例节点，造成了很大的性能损耗，而且网络带宽的压力也会比较大。其次，由于每个节点都保存了全量的数据，所以，即使扩展机器，新加入的机器依然要保存全量数据，如果数据量很大的话，依然会存在超出机器所能承受的最大容量。
- 图例：
