前面解决了消息的可靠性、消息的延迟问题，消息的堆积的问题，下面研究mq可用性、并发能力问题，这就需要mq集群来实现了

一：集群分类

（1）普通集群 

 

 

创建一个节点： 

8082、8083也可以看到这个队列：因为对列的元信息是可以共享的。

在8081里的队列中发送一个消息：

8083也有 ，可以取到

为什么另外的节点也可以取到？因为这是个引用，当来取消息的时候 ，可以总另外一个节点把消息传过来给你，所以在任意一个节点都可以看到这个数据

如果声明那个队列的节点挂了，就不能引用了

可以说明队列消息是没有实现数据共享的，要想数据恢复需要mq1重新启动

刷新页面数据就恢复过来了：

（2）镜像集群

比如我发送q1队列的镜像节点上节点2，节点2会把请求转发给节点1上，让他去做，节点1做完之后，再把数据同步给节点2，完成数据同步

消费也是一样，在节点上完成一个消费不管是在哪一个节点上，一定会去通知主节点，主节点回去通知当前节点的所有镜像，这些镜像会把消息跟着一起删除，一定确保一致性，消息消费完之后，一定会删除，防止重复消费

在任意的节点执行都行：exactly模式： 

创建一个新的队列：

镜像节点2 

mq2：

在mq1节点上发送消息：8081

mq2节点上就有消息了：

mq3也可以看到：节点3不是节点1的镜像，只是有引用可以看到 

让主节点宕机mq1

原来的镜像节点就变成主节点：产生新的镜像节点mq3

恢复后节点就没有关系了 

 

exactly模式的健壮性比以前好多了

（3）仲裁队列

镜像对类虽然能够做主从，但是会有数据丢失的风险，不是强一致的，仲裁队列可以解决这个问题

仲裁队列默认会去形成镜像模式，镜像默认是5

创建完之后，显示+2表示两个镜像，fllowers代表从：

发送一个消息：

节点2 

节点3：

（4）java代码创建仲裁队列集群

消费者修改配置：