1. 引言
MQ的本质是异步调用，用于应用系统间解藕交互；不同于DUBBO、ESB、SpringCloud等同步调用，它具有一对多，无需响应结果，失败重投等特征。
MQ用到的主要是：RocketMQ、ISC，部分应用系统用到了Kafka。本文就来聊一聊MQ在同城双活中，它的方案，问题，挑战。
2. 方案一：IDC内部自产自消
说明：
1. 依据“应用调用尽量不跨IDC"的原则，理想情况是：IDC内部生产内部消费。但它要求是生产者和所有消费者都完成了双活，这也是MQ双活的最终状态。
显然， 短期这是不现实的，必然存在部分应用系统暂时没有完成双活环境建设。
2. 应用系统做双活时，需要收集所有Topic，并统计整理Topic的生产者、消费者的双活环境完成情况。如果消费者、生产者都完成了双活环境的构建，则采用“IDC内部自产自消”的方案。
否则，要根据消息是否允许丢失，来选择方案（参考后续章节）。
3. 站在应用系统视角，MQ Topic分为：自产自消，自产它消，自消它产。自产自消（应用系统内部使用的Topic），即可采用本方案。
4. 在双活环环境，MQ是完全独立一套，独立的Topic注册中心（NameServer），独立的Broker节点集群，所以在双活环境Topic都需要重新去申请的（同名Topic）。
优点：
1. RocketMQ、ISC、Kafka都适用，且无需代码改造。
2. 符合“同IDC优先调用“的原则，也是MQ双活的最终状态，最终所有MQ Topic都需要切换到此方案上来。
3. 容灾切换时，无需切换。消息是否丢失，与双活无关。
局限性：
1. MQ Topic的生产者、所有消费者都完成了双活环境的构建。短期明显这个条件不具备。
3. 方案二：跨IDC生产
如果MQ Topic的部分消费者或全部消费者没有完成双活环境构建，则双活环境跨IDC生产，回默认环境，默认环境单边消费。
3.1 常规情况
说明：
1. 该方案跨IDC单边生产，单边消费（默认环境消费，双活环境不消费）；双活环境的生产者跨IDC连接默认环境的MQ实例
2. 消费者连各自环境的Topic实例，所有消息在默认环境单边消费；双活环境因为没有消息生产，即不会有任何消息消费。
3. 未来，当“消费者2”完成了双活环境建设，即可切换到方案一：IDC内部自产自消。
3.2 容灾切换
当默认环境故障，切换到双活环境，需要修改应用配置，将双活环境生产者的消息投递到双活MQ Topic，这种情况下：
1. 消费者2，因为没做双活，消息会在MQ积压，消息过期后会丢失。消费者1做了双活，会即时消费消息，不会积压。
2. 此方案会导致没有做双活的消费者，在故障期间生产的消息丢失。且当默认环境恢复后，要尽快切换回默认环境的Topic进行投递。
3. 适用于ISC、Kafka、RocketMQ
上述方案，会在存在消息丢失，如果不允许消息丢失，则可以选择如下方案：
说明：
1. 此方案有前提：即生产者支持本地失败重投：即投递消息失败则存本地Log文件，然后不断偿试重投。
即默认环境不可用时，消息投递失败，存到生产者本地的Log文件，消息会积压。
2. ISC支持本地失败重投。RocketMQ支持失败重投，但需要升级新版本SDK。
3. 此方案优点是：消息不会丢。故障期间，消息会在生产者本地积压。默认环境恢复后，消息会补偿投递，生产者也无须改配置重启。
局限性：
1. 默认环境不恢复，消息会一直积压，已完成双活的消费者也会积压。但消息不会丢。默认环境恢复，本地重试会把消息投递上去，完成消费。
2. 需要开启本地失败重试；RocketMQ需要升级SDK，可能需要小改代码，本地要验证清楚。
3. 默认环境不恢复，双活环境的生产者会报错，并把投递失败的消息存到本地Log文件。
4. 方案三：消息转发
4.1 常规情况
说明：
1. 消费者2因为没有做双活，双活环境生产的消息，需要跨IDC转发到默认环境。此方式只适用于ISC
2. 消费者2的子Topic转发，消费者1的子Topic不转发，在双活环境消费，不会产生重复消费。
局限性：
1. 只适用于ISC。此方案的本质，同方案二（跨IDC生产）
2. 需要消费者提申请单，在ISC上进行策略配置。也就是需要所有消费者配合和协同，协同成本高。
以核心的动账通知消息为例，它的消费者20+，大部分渠道系统，且双活建设计划靠后。
3. 生产者需梳理出所有的单活消费者，所有单活消费者提前配置好路由转发，生产者双活方可上线；
4.2 容灾切换
说明：
1. 容灾切换期间（默认环境故障期间），消费者2 的消息会转发失败，积压在MQ-B中；默认环境恢复后，再进行转发，消息不会丢失。
2. 此方案的优点，是消息不会丢失。
5. 特殊情况
5.1 交叉消费(不推荐)
常规情况
容灾切换
说明：
1. 消费者2不可用，消费者2的消息会在MQ积压。
2. 适用中间件：RocketMQ、ISC、Kafka
局限性：
1. 需推动所有消费者进行代码改造，支持双MQ实例来双边消费，推动和改造难度较大，协同成本高；
以核心的动账通知消息为例，它的消费者20+，这里的推动协同成本和难度，可想而知。
2. 双边随机消费，违反“同IDC优先原则"。如果消费者2完成双活，需要切换到方案一：IDC内部自产自产，又需要推动所有消费者进行二次代码改造。
这时，各关联方的意愿，谁来负责推动，都成问题。
3. 消费者需要同时连接二个注册中心（NameServer），连接二个MQ集群，架构上也比较复杂。
4. 交叉随机，一半（50%）的消息消费会跨IDC。
综上所述，此方案不推荐。
优点：
1：消息不丢
5.2 生产者单活
假如，应用自身是消费者，Topic的生产者作为关联方，暂未完成双活环境构建，则：
常规情况
生产者未做双活，双活环境不会产生消息。只会在默认环境生产和消费。
容灾切换
容灾切换时，默认IDC已不可用，没有消费产生也就没有消息消费了；
6. 问题和挑战
6.1 关联方未完成双活
MQ本质是异步调用，以Topic为维度，如果有关联方未做双活，消息也不能丢失，意味着只能回默认环境（IDC-A）。
方案选择上，推荐使用方案二：跨IDC生产。
6.2 跨IDC生产和消费
跨IDC有带宽和时延问题，尽量避免跨IDC消息生产和消费，能使用方案一：IDC内部自产自消，则优先使用。
同时，短期是尽量减少导入双活环境的流量，长期是所有应用系统都完成双活环境，切换到方案一。
6.3 消息丢失问题
当容灾切换后，默认环境故障期间，没有完成双活的关联方（消费者），消息会积压或丢失。
需要根据业务场景是否允许消息丢失，来选择方案。
如果不允许丢失，则选择积压，等默认环境恢复后，再消费掉。
当所有关联方（所有消费者）都完成了双活，切换到方案一：IDC内部自产自消，这个问题就没有了。
6.4 方案如何选择
以Topic为维度，依据关联方判断，所有关联方（生产者+所有消费者）都做了双活，则选择方案一：IDC内部自产自消。
否则选择方案二：跨IDC生产
所以，研发团队需要收集应用系统涉及Topic清单，并收集确认关联方双活完成情况，以及业务场景是否允许故障期间消息丢失，来决定方案。
如果应用自身是Topic生产者，则你的关联方是所有消费者。
如果应用自身是Topic消费者，则你的关联方是生产者和其它消费者。
当有关联方（消费者）未完成双活，故障期间要么消息丢失，要么消息积压。
选择方案时，除了方案技术可行性外，还需要考虑方案协同推动成本、代码改造成本，这些也是影响双活可落地执行的关键因素。
这些方案中，交叉消息和消息转发，方案技术上可行，但如果关联方很多，这协同和改造成本是很高的。
比如：核心的动账通知，消费者20+，这里协同沟通成本就难以想象。
6.5 双注册中心（NameServer）问题
应用系统会涉及多个Topic，每个Topic关联方情况不一样，选择方案也可能不一样。那么，有可能应用需要同时连接二个注册中心（NameServer）。
这里可能涉及代码改造。
6.6 顺序消费问题
MQ双边集群同时消费情况下，则MQ顺序消费能力受到影响，请注意做好评估。
6.7 不支持流量分流
MQ是异步调用，是应用间交互方式之一，也属于请求流量，但它不支持按“IDC权重分流“，但支持“同IDC优先原则“。
6.8 Topic谁负责
双活环境的Topic 归属哪个应用系统问题，由谁来申请，谁来协同推动？一对一的情况，谁先做双活谁负责。一对多情况，由生产者负责。
比如：核心的动账通知，由核心负责。会员的登陆通知，由会员负责。
7. 总结
简单总结一下，MQ双活方案最终目标是：IDC内部自产自消，符合“同IDC优先“原则。
短期，如果有关联方没有完成双活，则选择”跨IDC生产“的方案，单边消费。
如果，消息允许故障期间丢失，尽量选择简单方案。如果不允许故障期间消息丢失，则选择消息积压方案。
作者：陈强 （CHENQIANG747 ），网金研发团队架构师
修订：李兴楠（LIXINGNAN945），网金研发团队架构师
本文系个人观点，描述不当或不正确，欢迎指正。
