rabbitmq集群部署高可用配置

集群部署完成后需要添加Policies才能实现高可用，HA策略是通过磁盘节点元数据进行同步

生产一般建议2磁盘+1内存节点，也可以3磁盘

 

 

 

Policies添加流程，配置完成后需要重启生效：

1.  ha-promote-on-shutdown 未配置，需要配置为always

2.  ha-sync-mode 未配置，需要配置为automatic（自动）

3.  ha-mode 未配置，需要配置为all（自动）

 

1.镜像队列不能作为负载均衡使用，因为每个操作在所有节点都要做一遍。
2.ha-mode参数和durable declare对exclusive队列都不生效，因为exclusive队列是连接独占的，当连接断开，队列自动删除。所以实际上这两个参数对exclusive队列没有意义。
3.将新节点加入已存在的镜像队列时，默认情况下ha-sync-mode=manual，镜像队列中的消息不会主动同步到新节点，除非显式调用同步命令。当 调用同步命令（via rabbitmqctl or web-based ui）后，队列开始阻塞，无法对其进行操作，直到同步完毕。当ha-sync-mode=automatic时，新加入节点时会默认同步已知的镜像队列。 由于同步过程的限制，所以不建议在生产环境的active队列（有生产消费消息）中操作。
4.每当一个节点加入或者重新加入（例如从网络分区中恢复回来）镜像队列，之前保存的队列内容会被清空。
5.镜像队列有主从之分，一个主节点（master），0个或多个从节点（slave）。当master宕掉后，会在slave中选举新的master。选举算法为最早启动的节点。
6.当所有slave都处在（与master）未同步状态时，并且ha-promote-on-shutdown policy设置为when-syned（默认）时，如果master因为主动的原因停掉，比如是通过rabbitmqctl stop命令停止或者优雅关闭OS，那么slave不会接管master，也就是说此时镜像队列不可用；但是如果master因为被动原因停掉，比如VM 或者OS crash了，那么slave会接管master。这个配置项隐含的价值取向是优先保证消息可靠不丢失，放弃可用性。如果ha-promote-on- shutdown policy设置为alway，那么不论master因为何种原因停止，slave都会接管master，优先保证可用性。
7.镜像队列中最后一个停止的节点会是master，启动顺序必须是master先起，如果slave先起，它会有30秒的等待时间，等待master启动， 然后加入cluster。当所有节点因故（断电等）同时离线时，每个节点都认为自己不是最后一个停止的节点。要恢复镜像队列，可以尝试在30秒之内同时启 动所有节点。
8.对于镜像队列，客户端basic.publish操作会同步到所有节点；而其他操作则是通过master中转，再由master将操作作用于salve。 比如一个basic.get操作，假如客户端与slave建立了TCP连接，首先是slave将basic.get请求发送至master，由 master备好数据，返回至slave，投递给消费者。
由8可知，当slave宕掉时，除了与slave相连的客户端连接全部断开之外，没有其他影响。当master宕掉时，会有以下连锁反应：
1)与 master相连的客户端连接全部断开。
2)选举最老的slave为master。若此时所有slave处于未同步状态，则未同步部分消息丢失。
3)新的 master节点requeue所有unack消息，因为这个新节点无法区分这些unack消息是否已经到达客户端，亦或是ack消息丢失在到老 master的通路上，亦或是丢在老master组播ack消息到所有slave的通路上。所以处于消息可靠性的考虑，requeue所有unack的消 息。此时客户端可能受到重复消息。
4)如果客户端连着slave，并且basic.consume消息时指定了x-cancel-on-ha- failover参数，那么客户端会收到一个Consumer Cancellation Notification通知，Java SDK中会回调Consumer接口的handleCancel()方法，故需覆盖此方法。如果不指定x-cancel-on-ha-failover参 数，那么消费者就无法感知master宕机，会一直等待下去。