前言
RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用的。
集群节点类型
节点的存储类型分为两种：
- 磁盘节点
- 内存节点
磁盘节点就是配置信息和元信息存储在磁盘上，内存节点把这些信息存储在内存中，当然内次节点的性能是大大超越磁盘节点的。
单节点系统必须是磁盘节点，否则每次你重启RabbitMQ之后所有的系统配置信息都会丢失。
RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点。
如果集群中的唯一一个磁盘节点，结果这个磁盘节点还崩溃了，那会发生什么情况？
如果唯一磁盘的磁盘节点崩溃了，不能进行如下操作：
- 不能创建队列
- 不能创建交换器
- 不能创建绑定
- 不能添加用户
- 不能更改权限
- 不能添加和删除集群几点
总结：如果唯一磁盘的磁盘节点崩溃，集群是可以保持运行的，但你不能更改任何东西。
解决方案： 在集群中设置两个磁盘节点，只要一个可以，你就能正常操作。
集群类型
RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。
单机模式
单机模式,生产几乎不用。
普通集群模式（无高可用性）
普通集群模式，有服务器ABC，在服务器ABC上分别启动RabbitMQ实例，生产者生产消息1，随机发给某一实例A，实例BC上记录消息1的原数据信息（比如消息1具体信息在示例A上）,消费者消费消息，随机连接某个示例B，消费消息1，实例B根据原数据发现消息1在实例A上，则实例B去实例A拉取消息返回给消费者。
优点：
提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。
缺点：
消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取。
如果你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。
镜像集群模式（高可用性）
这种模式，才是所谓的 RabbitMQ 的高可用模式。
跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，其元数据还是 queue 里的消息都会存在于一个或多个从队列拷贝，一旦主节点不可用，最老的从队列将被选举为新的主队列。
为什么不在所有节点都完整拷贝一套数据？
如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。
那么如何开启这个镜像集群模式呢？
其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。