手记

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操作命令,需要了解。

附简单的升级思路:

 

原文出处:https://www.cnblogs.com/jiagoushi/p/10174296.html  

0人推荐
随时随地看视频
慕课网APP