前言
RabbitMQ 是一款开源的消息代理服务器，用来进行信息路由。
MQ可以使架构变得松耦合，从而更有弹性，更灵活，是SOA架构不可或缺的组成部分，担当服务总线或信息总线的角色。
可用性在生产系统中是非常重要的指标， RabbitMQ 对集群进行了很好的支持
下面分享一下 RabbitMQ 的集群操作，详细可以参阅 官方文档
Tip: 当前版本 RabbitMQ 3.5.6 release
概要
升级集群
升级Erlang或RabbitMQ版本，必须停止集群，因为集群中不能容忍不同版本协同工作
在集群升级之前最好确认哪一个Node是第一个升级的，这个node必须是最后一个关闭，然后第一个启动。否则在这个node和实际最后一个关闭的node之前的配置变更都会丢失
在集群中，要使用DISC node来主导升级，而不能使用RAM node，会报错，从安全层面也可以理解这样做的用意
When upgrading from one major or minor version of RabbitMQ to another (i.e. from 3.0.x to 3.1.x, or from 2.x.x to 3.x.x), or when upgrading Erlang, the whole cluster must be taken down for the upgrade (since clusters cannot run mixed versions like this). This will not be the case when upgrading from one patch version to another (i.e. from 3.0.x to 3.0.y); these versions can be mixed in a cluster (with the exception that 3.0.0 cannot be mixed with later versions from the 3.0.x series). RabbitMQ will automatically update its persistent data structures if necessary when upgrading between major / minor versions. In a cluster, this task is performed by the first disc node to be started (the “upgrader” node). Therefore when upgrading a RabbitMQ cluster, you should not attempt to start any RAM nodes first; any RAM nodes started will emit an error message and fail to start up. While not strictly necessary, it is a good idea to decide ahead of time which disc node will be the upgrader, stop that node last, and start it first. Otherwise changes to the cluster configuration that were made between the upgrader node stopping and the last node stopping will be lost. Automatic upgrades are only possible from RabbitMQ versions 2.1.1 and later. If you have an earlier cluster, you will need to rebuild it to upgrade.
