（一）普通集群模式:


即在多个服务器上部署多个MQ实例, 每台机器一个实例. 创建的每一个queue,只会存在一个MQ实例上. 但是每一个实例都会同步queue的元数据(即queue的标识信息). 当在进行消费的时候, 就算 连接到了其他的MQ实例上, 其也会根据内部的queue的元数据,从该queue所在实例上拉取数据过来.
集群 - 图1
这种方式只是一个简单的集群,并没有考虑高可用. 并且性能开销巨大.容易造成单实例的性能瓶颈. 并且如果真正有数据的那个queue的实例宕机了. 那么其他的实例就无法进行数据的拉取.
这种方式只是通过集群部署的方式提高了消息的吞吐量(多个消费者可以连接到任意一个集群去消费队列里面的消息),但是并没有考虑到高可用.

工作流程是
假如说A机器是主机器,所有的消息都在A机器上,B和C机器是没有消息的,此时如果消费者连到B和C机器的话, B和C机器都得从A机器上拉取消息才行,如果A机器挂了,那么这个项目就崩溃.

缺点
1. 可能会在RabbitMQ集群内部产生大量的数据传输
2. 可用性几乎没有任何保障,只要携带消息源的机器挂掉,整个集群崩溃.



（二）镜像集群模式:

这种模式才是高可用模式. 与普通集群模式的主要区别在于. 无论queue的元数据还是queue中的消息都会同时存在与多个实例上.消费者从任何一台机器上消费消息都没问题
集群 - 图2
要开启镜像集群模式,需要在后台新增镜像集群模式策略. 即要求数据同步到所有的节点.也可以指定同步到指定数量的节点.

这种方式的好处就在于, 任何一个服务宕机了,都不会影响整个集群数据的完整性, 因为其他服务中都有queue的完整数据, 当进行消息消费的时候,连接其他的服务器节点一样也能获取到数据.

缺点:

1: 性能开销大: 因为需要进行整个集群内部所有实例的数据同步

2:无法线性扩容: 因为每一个服务器中都包含整个集群服务节点中的所有数据, 这样如果一旦单个服务器节点的容量无法容纳了怎么办?.