目录
1、背景
系统需要对接微信PC扫码支付、订单的状态需要由系统来保证同步，不需要人工进行介入，所以，需要保证商户系统订单与微信订单最终一致性。
2、实现方案
3、方案详解
上图中，红色为实现订单状态最终一致性的三个方案，下面将进行详细描述：
异步通知：当用户支付成功时，由微信服务器向商户系统后台推送支付成功通知，商户系统后台进行进行回复。后台通知交互时，如果微信收到商户的应答不符合规范或超时，
微信会判定本次通知失败，重新发送通知，直到成功为止（在通知一直不成功的情况下，微信总共会发起多次通知，通知频率为15s/15s/30s/3m/10m/20m/30m/30m/30m/60m/3h/3h/3h/6h/6h - 总计 24h4m），
但微信不保证通知最终一定能成功。
订单查询延迟消息：如果商户系统宕机或者重启导致没有及时收到微信的异步通知，MQ的延迟消息会保证，商户系统在订单创建5分钟之后同步微信订单状态或者商户系统重启之后就会消费这条延迟消息，而触发订单状
态同步。这里也可以利用MQ的重试机制，当查询订单状态为“支付中”时，不要对消息进行ACK，等待MQ的再次投递，默认AciveMQ是投递6次，进入DLQ。
定时任务扫表： 定时扫描最近10分钟的，订单状态为“支付中”的订单，向微信服务器同步订单状态，请注意10分钟的订单可能会有很多，如果进行异步处理，保证线程不要阻塞。
4、注意事项
三个方案同步的订单状态，很有可能会有并发现象，特别是MQ的重试机制会有多次接口调用发生，所以这种接口必须是幂等的，这里可以比较方便地实现一个幂等，每次进行消费的时候，判断订单支付时间字段是否为空，如果不为空，则
消费不需要进行处理，如果为空，则可以进行本次消费处理。还需要注意一下，如果出现三种方案的并发对系统是否有影响，如果有影响，需要保证消费业务逻辑的原子性，可以使用分布式锁；如果消费业务逻辑比较简单，只需要修改订单状态，
就不需要用分布式锁，无须保证事务原子性。
这里我举一个比较极端的例子，订单支付成功，会很很多的RPC调用：调用库存服务减库存、积分服务增加积分、订单服务修改订单状态，总之业务逻辑比较复杂，那么这种场景下，一定要实现消费的原子性，否则会出现并发事务引起的几个
问题：读脏数据、不可重复读、虚读、幻读。