rabbitmq迁移至rocketmq

背景：

目前项目中使用的是rabbitmq做消息中间件。rabbitmq非常适合中小微企业，由于其语言特性(ErLang)，时效性高、处理速度特别快(ns级)，但其劣势也很明显：

1、吞吐量稍低
2、集群支持的不好、扩容困难（只支持普通模式与镜像模式）
3、消息不可堆积太多
4、不支持一些高级场景：如顺序消息、消息回溯、事务消息等

基于以上考虑，目前项目要整体替换成rocketmq，rocketmq具有以下优点：

1、吞吐量大
2、集群部署、高可用、扩展方便
3、可支持大量数据的堆积
4、支持顺序消息、事物消息、延时消息、消息回溯等特性
5、完善的后台管理界面
6、消费者客户端定时轮训去服务器拉去消息，比服务器基于长链接推送给客户端支持的并发更高

rabbitmq的集群是硬伤：目前只支持普通模式和镜像模式
普通模式：

默认模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

镜像模式:

把需要的队列做成镜像队列，存在与多个节点属于RabbitMQ的HA方案。该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。

mq迁移：

mq迁移的难点在于如何保证消息0丢失；首先要梳理出所有服务的mq依赖关系，如图所示A系统发送消息给B系统，同时B系统发送消息给C、D系统（假设每个系统有8个节点）：

切换时，要先从最下游的消费者开始切换，也就是图中的C、D系统(因为如果先发生产者此时还没rocketmq的消费者，消息会丢失)，第一轮C、D系统发7个节点切换至rocketmq，然后发B系统、A系统，同时每个系统留1个节点保持rabbitmq在线，此时只有1/8的流量会走之前的rabbitmq。第二轮要从最上游生产者开始切换，从源头堵住流量，先将A系统剩下的1个节点发版切换，然后观察B系统rabbitmq后台是否还有消息，若没有可以发版B系统剩下的1个节点切换了，然后C、D系统同理。

整理发版顺序如下：

第一轮：先发最下游的消费者C、D系统，然后B系统、A系统（注意每个系统都要留一个节点）
第二轮：从最上游生产者A系统开始，依次B、CD系统，将剩下的一个节点切换（注意发版时注意观察rabbitmq后台，确认无消息积压才可发版）