rabbitMQ高可用

镜像模式 
镜像模式和普通模式的区别就是，队列的数据都镜像了一份到所有的节点上。这样任何一个节点失效，不会影响整个集群的使用。 
在实现上，mirror queue内部有一套选举算法，会选出一个master，和若干个slaver。master和slaver 通过相互间不断发送心跳来检查是否连接断开。可以通过指定net_ticktime来控制心跳检查频率。注意一个单位时间net_ticktime实际上做了4次交互，故当超过net_ticktime (± 25%) 秒没有响应的话则认为节点挂掉。另外注意修改net_ticktime时需要所有节点都一致。 
配置举例： 
[ 
        {rabbit, [{tcp_listeners, [5672]}]}, 
        {kernel, [{net_ticktime,  120}]} 
]. 
consumer，任意连接一个节点，若连上的不是master，请求会转发给master，为了保证消息的可靠性，consumer回复ack给master后，master删除消息并广播所有的slaver去删除。 
publisher ，任意连接一个节点，若连上的不是master，则转发给master，由master存储并转发给其他的slaver存储。 
如果master挂掉，则从slaver中选择消息队列最长的为master，在这种情况下可以存在消息未同步给ack消息未同步的情况，会造成消息重发（默认是异步同步的）。总共有以下几件事情发生：

1）1个最老的（队列最长的）的slaver提升为master，如果没有一个slaver是和master同步的则会造成消息丢失。 
2) 要提升为master的slaver会认为以前所有连接挂掉的master的消费者都断开了连接。那么存在clinet发送了ack的消息单还在路上是master挂掉的情况，或者master收到了ack但是在广播给slaver的时候master挂掉的情况，所以新的master别无选择，只能认为消息没有被确认。他会requeue他认为没有ack的消息。那么client可能就收到了重复的消息，并要再次发送ack。

3)从镜像队列中消费的client支持了consumer Cancellation通知的，将收到通知并订阅的mirrored-queue被取消了，这是因为该mirrored-queue 升级成了master，这是client需要重现去找mirrored-queue上消费，这样就避免了client继续发送ack到老的挂掉的master上。避免收到新的master发送的相同的消息。 
4)如果noAck=true，且在mirrored-queue上消费，那么在切换时由于服务器是先ack然后发送到noAck=true的消费者，这时连接断开可能导致该数据丢失

如果slaver挂掉，则集群的节点状态没有任何变化。只要client没有连到这个节点上，也不会给client发送失败的通知。在检测到slaver挂掉的期间publish消息会有延迟。如果配置了高可用策略是自动同步，当slaver起来后，队列中有大量的消息需要同步，将会整个集群阻塞长时间的不能读写直到同步结束。 
这两个挂掉的情况都需要客户端镜像容错，比如在连接断开的时候进行重连（官方的Java和.net 客户端提供了callback方法在监听到链接失败的时候调用。Java在Connection和channel类中提供了ShutdownListener 的callback方法，.net client在IConnecton中提供了ConnectionShuedown在Imodel中提供了ImodelShutdown事件供调用） 。也可以在client和server之间加入LoadBalancer.比如haproxy做负载均衡。

指定mirror策略： 
有三种策略： 
all:队列将mirrored到所有集群中的节点中，当新节点添加进来时也会mirrored到新的节点 
exactly（需指定count）:如果节点数小于count数，则队列将mirrored到所有的节点。如果节点数大于count，新的节点将不再创建队列的mirror（即使原来已创建mirror的节点挂掉也不会创建） 
nodes:对指定的节点进行mirror。如果没有一个指定的节点在运行中，那么只有client连接的那个节点才会声明queue(这里有个迁移策略：假如queue是在[A,B]上且A为master，若给定的新的策略为nodes[C,D]，那么为了防止数据丢失，在迁移中会同时存在[A,C,D]直到C,D已经同步好以后，A才会关闭) 
配置举例： 
设置queue的名称为ha.的为高可用： 
linux:rabbitmqctl set_policy ha-all "^ha\." '{"ha-mode":"all"}' 
win:rabbitmqctl set_policy ha-all "^ha\." "{""ha-mode"":""all""}" 
http api:PUT /api/policies/%2f/ha-all {"pattern":"^ha\.", "definition":{"ha-mode":"all"}} 
web ui: 
1:Navigate to Admin > Policies > Add / update a policy. 
2:Enter "ha-all" next to Name, "^ha\." next to Pattern, and "ha-mode" = "all" in the first line next to Policy. 
3:Click Add policy. 
举例2： 
rabbitmqctl set_policy ha-two "^two\." \ 
   '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'

自动或手动同步： 
你可以查看哪些slave已经同步好了： 
rabbitmqctl list_queues name slave_pids synchronised_slave_pids 
你可以手动同步(默认手动同步)： 
rabbitmqctl sync_queue name 
你可以取消自动同步： 
rabbitmqctl cancel_sync_queue name 
一个没有同步的mirror，它仍然会同步后续插入队列的数据，但是队列前面的数据却没有。但是随着队列的不断消费，导致空缺的部分的消息被消费掉了，此时mirror也可以是同步了的。

主备集群 
主备方式(active,passive)只有一个节点处于服务状态，可以结合pacemaker和ARBD， 
shovel简单从一个broker的一个队列中消费消息，且转发该消息到另一个broker的交换机。 
这种方式用的比较少，这里就不做介绍了。详见http://www.rabbitmq.com/pacemaker.html