rabbitmq集群功能和原理：
设计集群目的：
允许消费者和生产者在RabbitMQ节点崩溃的情况下继续运行
通过增加更多的节点来扩展消息通信的吞吐量
rabbitmq可以通过三种方式来部署分布式集群系统，分别是：cluster、federation、shovel
cluster:
不支持夸网段，用于同一个网段内的局域网
可以随意动态的增加和减少
节点之间需要运行相同版本的rabbitmq和erlang
federation:应用于广域网，允许单台服务器上的交换机或队列接收发布到另一台服务器交换机或队列的消息，可以是单独机器或集群。federation队列类似于单向点对点连接，消息会在联盟队列之间转发任意次，直到被消费者接受。通常使用federation来连接internet上的中间服务器，用作订阅分发消息或工作队列
shovel:连接方式与federation的连接方式类似，但它工作在更低层次，可以应用于广域网
节点类型
RAM node：内存节点将所有队列、交换机、绑定、用户、权限、和vhost的元数据定义存储在内存中，好处是可以使得交换机和队列声明等操作更加快捷
Disk node：将元数据存储在磁盘中，单节点系统只允许磁盘类型的节点，防止重启rabbitmq的时候，丢失系统的配置信息
说明：rabbitmq要求集群中至少有一个磁盘节点，所有其他节点可以是内存节点，当节点加入或者离开时，必须要将该变更通知一个磁盘节点。如果集群中唯一的磁盘节点崩溃，集群扔可保持运行，但是无法进行其他操作(增删改查)，直到节点恢复
解决方法：设置两个磁盘节点，至少一个是可用的，可以保存元数据的更改
Erlang Cookie
Erlang Cookie是保证不同节点可以相互通信的密钥，要保证集群中的不同节点相互通信必须共享相同的Erlang Cookie。
说明：这就要从rabbitmqctl命令的原理说起，rabbitmq底层是通过erlang架构来实现的，所以rabbitmqctl会启动erlang节点，并基于erlang节点来使用erlang系统连接rabbitmq节点。在连接过程中需要正确的Erlang Cookie和节点名称，Erlang节点通过交换Erlang Cookie以获得认证
镜像队列
RabbitMQ的Cluster集群模式一般分为两种，普通模式和镜像模式
普通模式：默认的集群模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象
镜像模式：将需要消费的队列变为镜像队列，存在于多个节点，这样就可以实现RabbitMQ的HA高可用性。作用就是消息实体会主动在镜像节点之间实现同步，而不是像普通模式那样，在consumer消费数据时临时读取。缺点就是，集群内部的同步通讯会占用大量的网络带宽
实现机制
镜像队列实现了RabbitMQ的高可用性（HA），具体的实现策略如下所示：
| ha-mode | ha-params | 功能 |
|---|---|---|
| all | 空 | 镜像队列将会在整个集群中复制。当一个新的节点加入后，也会在这 个节点上复制一份。 |
| exactly | count | 镜像队列将会在集群上复制count份。如果集群数量少于count时候，队列会复制到所有节点上。如果大于Count集群，有一个节点crash后，新进入节点也不会做新的镜像。 |
| nodes | node name | 镜像队列会在node name中复制。如果这个名称不是集群中的一个，这不会触发错误。如果在这个node list中没有一个节点在线，那么这个queue会被声明在client连接的节点。 |
rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]
-p Vhost： 可选参数，针对指定vhost下的queue进行设置
Name: policy的名称
Pattern: queue的匹配模式(正则表达式)
Definition：镜像定义，包括三个部分ha-mode, ha-params, ha-sync-mode
ha-mode:指明镜像队列的模式，有效值为 all/exactly/nodes
all：表示在集群中所有的节点上进行镜像
exactly：表示在指定个数的节点上进行镜像，节点的个数由ha-params指定
nodes：表示在指定的节点上进行镜像，节点名称通过ha-params指定
ha-params：ha-mode模式需要用到的参数
ha-sync-mode：进行队列中消息的同步方式，有效值为automatic和manual priority：可选参数，policy的优先级下面的命令来查看那些slaves已经完成同步
rabbitmqctl list_queues name slave_pids synchronised_slave_pids可以通过手动的方式同步一个queue：
rabbitmqctl sync_queue name同样也可以取消某个queue的同步功能：
rabbitmqctl cancel_sync_queue name通常队列由两部分组成：一部分是AMQQueue，负责AMQP协议相关的消息处理，即接收生产者发布的消息、向消费者投递消息、处理消息confirm、acknowledge等等；另一部分是BackingQueue，它提供了相关的接口供AMQQueue调用，完成消息的存储以及可能的持久化工作等
在RabbitMQ中BackingQueue又由5个子队列组成：Q1, Q2, Delta, Q3和Q4。RabbitMQ中的消息一旦进入队列，不是固定不变的，它会随着系统的负载在队列中不断流动，消息的不断发生变化。与这5个子队列对于，在BackingQueue中消息的生命周期分为4个状态：
- Alpha：消息的内容和消息索引都在RAM中。Q1和Q4的状态。
- Beta：消息的内容保存在DISK上，消息索引保存在RAM中。Q2和Q3的状态。
- Gamma：消息内容保存在DISK上，消息索引在DISK和RAM都有。Q2和Q3的状态。
- Delta：消息内容和索引都在DISK上。Delta的状态
注意：对于持久化的消息，消息内容和消息所有都必须先保存在DISK上，才会处于上述状态中的一种，而Gamma状态的消息是只有持久化的消息才会有的状态
上述就是RabbitMQ的多层队列结构的设计，我们可以看出从Q1到Q4，基本经历RAM->DISK->RAM这样的过程。这样设计的好处是：当队列负载很高的情况下，能够通过将一部分消息由磁盘保存来节省内存空间，当负载降低的时候，这部分消息又渐渐回到内存，被消费者获取，使得整个队列具有很好的弹性