RabbitMQ 3.6.1 升级至 3.7.9 版本(Windows 升级至Centos)

随着公司业务量的增加，原本部署在Windows服务器的RabbitMQ集群(3.6.1)总是出现莫名其妙的问题,经查询官方Issue，确认是RabbitMQ 3.6.1 版本的bug。查看从3.6.1 版本至 3.7.9 版本的变更日志，可以发现RabbitMQ官方修复了不少bug，本着版本越新 bug相对越少且 新版本修复了当前我们经常遇到的版本bug，因此我们决定将其中一个MQ集群(Windows)升级至3.7.9(Centos),毕竟开源软件对于Linux的支持是更好的。

公司的业务不可能会因为要升级MQ集群而暂停，因此采取哪种形式进行迁移是我们要重点考虑的，

1. Full Stop升级
   需要将整个MQ集群停止，然后整体升级，PASS。
2. 滚动升级
   滚动升级对MQ的版本有要求，从3.6.1 升级至 3.7.9 不满足官方介绍的版本要求，PASS。
3. blue-green升级
   blue-green升级也成为蓝绿升级，升级过程不需要停止原有MQ集群，升级过程安全可控，但需要额外搭建一个新的集群。鉴于我们要将Windows部署的3.6.1 版本的MQ集群升级至Centos部署的3.7.9 版本，必须新搭建集群，因此采用该方案。

Blue-Green蓝绿部署是一个升级策略，它是基于在当前集群(blue)旁边创建第二个集群（green）的想法。当迁移结束后，应用程序会切换到”green”集群，”blue”集群会关闭，为了简化切换，可以使用 federated queues把已排队的消息从“blue”传递高”green”集群。

具体的搭建步骤：

1.准备Green集群(3.7.9)

1.1  搭建3.7.9 版本的MQ集群  。具体可参考centos安装RabbitMQ 3.7.9 (使用RPM)  及  Centos 7安装RabbitMQ 3.7.8版本(单机版)-不使用RPM。

1.2  Green 集群创建完毕后导入定义:exchange、queue、bindings。

从Blue 集群导出exchange、queue、bindings 的 元数据定义，导入到新搭建的Green集群

1.3 配置Federation Queue

Federation 作为RabbitMQ的一个插件而存在，本质上是连接green集群的消费者，会获取发布到blue集群的消息。   具体可参考官方文档：Upgrading RabbitMQ Using Blue-Green Deployment Strategy

将Blue 集群设置为上游，将Green设置为下游。实现发送至Blue集群的消息可以被Green集群的消费者消费。    用武林小说中的招式就是 乾坤大挪移。

2. 切换消费者连接到Green集群

2.1  修改客户端连接MQ集群地址，将消费者连接MQ集群地址从Blue切换至Green

    切换客户端MQ连接之后，消费者会连接至Green集群。但生产者仍旧会发送消息至Blue集群

3.耗尽积压的消息

3.1 在切换生产者连接至Green集群之前，先耗尽Blue集群中积压的消息。避免出现消息丢失，出现不可逆转的错误。

4.切换生产者连接到Green集群

4.1  修改生产者程序MQ连接，将消息发送至Green集群。

5.将Blue集群下线

遇到的挑战：

1.由于生产者未将连接从Blue切换至Green集群之前，我们希望耗尽积压的所有消息。但由于公司业务不会停止，因此发送端会持续的进行消息推送，就永远不会出现队列消息为空的情况。如果强行切换生产者，那么可能会造成消息丢失。

解决办法：Blue集群的消费者暂时保留，生产者从Blue切换至Green后，保留的消费者会继续消费Blue集群的消息，直至消费完毕。然后就可以下线Blue集群。

2.监控插件通过3.6.1 版本RabbitMQ  API进行数据读取及上报，在3.7.9 中，部分API进行了调整，因此对应的监控插件也需要对应调整。

3.此次操作是将部署在Windows的3.6.1 版本RabbitMQ  升级至  Centos 3.7.9 ，其中涉及的操作命令及部署方式均存在变化，需提前了解。

4.出现故障时，基本的Centos操作命令，需要了解。

附简单的升级思路：