多云多活方案之RocketMQ

背景

方案

方案一

1. 每个region（云）独立部署一个集群，各自的服务都连自己本地的MQ集群；

2. 通过DTS做消息的双向同步

3. 修改Consumer的源码需要实现两个核心的功能：
   A、集群正常的情况下，需要过滤到DTS同步过来的消息
   B、当有一个集群故障的情况下，假如北京的集群故障了，那么保定Consumer需要同时也消费DTS从北京同步过来的消息，那么具体从那个位点消费呢？假设北京的集群是18:00故障的，为了不丢失北京这边的消息，修改保定Consumer的从17：55开始消费，重复消费5分钟，这里有个很重要的点就是业务方一定要做消费幂等不然就会有问题。

方案二

1. 北京和保定两个region组成一个集群，每个region的服务都同时连两个region的nameserver集群；

2. 每个region的broker都同时注册到两个region的nameserver；

3. 每组broker都成在两个region之间交叉部署；

4. 修改nameserver的源码，实现region内部优先本地读写。

方案三

1. 北京和保定两个region组成一个集群，每个region的服务都同时连两个region的nameserver集群；

2. 每个region的broker都同时注册到两个region的nameserver；

3. 每组broker都成在两个region之间交叉部署。

这个方案和方案二的区别就是不做任何源码的修改，直接部署，主要问题就是会有50%的业务请求是夸region的.

方案对比