基于消息队列的数据同步
业务场景
每天130万左右的交易数据通过接口的方式同步给第三方，由于不能影响我们的主流程交易，所以采用消息队列异步的方式调用第三方接口，顺便要说一下，调用第三方接口的目的是为了第三方服务入账操作，并且当前平台的交易笔数只是我们的五分之一，后续仍有很多不确定。
技术选型
RocketMQ实现异步调用第三方接口。
技术调研
消息队列 MQ 是基于发布/订阅模型的消息系统。消费者，即消息的订阅方订阅关注的 Topic，以获取并消费消息。由于消费者应用一般是分布式系统，以集群方式部署，因此消息队列 MQ 约定以下概念：
- 集群：使用相同 Group ID 的消费者属于同一个集群。同一个集群下的消费者消费逻辑必须完全一致（包括 Tag
的使用）。详见订阅关系一致。 - 集群消费：当使用集群消费模式时，消息队列 MQ 认为任意一条消息只需要被集群内的任意一个消费者处理即可。
- 广播消费：当使用广播消费模式时，消息队列 MQ 会将每条消息推送给集群内所有注册过的消费者，保证消息至少被每个消费者消费一次。
根据我们的业务场景我们选择了集群消费模式，因为我们这里是入账操作，所以只需调用一次即可，同时对于调用失败的场景采用消息队列的重试机制。
业务场景图
技术方案设计
同步给第三方的订单只需支付成功和退款成功的，所以根据原有逻辑筛选出此类订单，并放入消息队列。第三方系统做幂等性校验，即一个流水号只能同步成功一次。
我们的系统是分布式服务，目前单日130万笔的交易6台服务器，消息队列的消费端也是部署在这6台服务器上，方便后续扩展。
风险监控
对此消息的Topic进行了监控，阀值3000开始短信报警。
踩过的坑
原因
第三方接口返回的业务码不明确
结果
我们系统当作调用失败，消息未提交，消息持续堆积，并且消费速度下降，高峰时堆积了近10万消息。
解决方案
解决方案之前在公众号里写过了，这里放个链接吧解决方案
总结
本文是一个业务解决方案，从业务场景到技术选型，最后到业务设计和踩过的一些坑。