前言：

在电商项目中的支付模块也是一个很重要的模块，其中下订操作以及退订操作就是主要的操作。其次的下单是同步下单，也就是第三方支付、数据库扣减、积分增加、等等其他业务操作，等待全部执行完毕后向用户返回成功响应请求。对于小体量系统那么是可以的，但是随着项目的扩大，后续下单中可能会添加新的业务，那么一整个下订的业务流程可能就会变得很长，增加了响应的时间，那么此时对于用户的体验来说肯定是不好的。所以就需要将同步下单改为异步下单来提高用户的体验。

首先就是同步下单改为异步下单流程：

起始同步下单也就是在下订方法中还需要涉及很多的业务操作，比如库存扣减、订单积分写入等等，那么当一个用户下单后就需要等待这些操作全部完成才会返回正常的结果，那么在系统繁忙的时候可能整个流程消耗的时间会比较长，对于用户来说那么体验肯定是不好的。

异步下单：

异步下单就是可以将上述的很多操作，比如积分写入等等操作通过MQ进行异步消费处理。那么就可以提高响应速度，来提升用户体验。

但整个下单的核心无论是同步还是异步，最为重要的步骤肯定是库存的扣减与检查。

那么整个下单流程应该就如下：

用户下单

检查对应商品库存（Redis）

库存充足则对Redis中的库存进行扣减（Lua）

然后数据库的扣减交由MQ进行异步消费扣减。

以及其他业务操作等设计各个表插入都可以交由MQ进行异步消费。

退订（退款）处理：

如果一个下订业务要包括这么多业务处理，当一个用户下单后执行了第三方支付扣减、缓存数据扣减、异步数据库扣减等等，那么假设用户下订完毕后，突然发现买错了，然后在短时间内立马又退订，而此时之前已经成功下订并将异步消息在MQ中进行处理，而此时消息已经在MQ中了，该如何解决与退订的各种数据退回操作。

情况一：

下订后的异步任务在MQ中还没有消费、退订的各种操作先执行。这种情况就是用户刚下订没多久后立即退订会产生，而正常的退订是说用户可能在到货后退货处理等几天后才进行退订，那么这种业务一般不会出现这种情况

思路：关键信息就是订单号 以及订单标识；

正常业务来讲应该订单表和退订表是两个表。

那么一个订单所有的步骤全部执行完毕后就会写入到订单表中，那么此时根据退订ID就可以先去订单表中查询这个订单是否已经完成或者查看订单标识（完成了就代表该下订的异步MQ任务全部执行完毕），此时可以执行退订的各种业务反向操作。退订同样可以交由MQ进行异步反向处理，提高用户体验。

如果发现订单表中该订单还未完成，那么就将退订流程通过RabbitMQ的延迟消息进行处理（比如等待30S等；具体时间可以根据业务以及系统进行分析判断），然后进行延迟判断，如果延迟消息处理时发现还未完成则重发消息直到等待订单完成后（此处操作有点类似订单超时取消），再进行退订处理。