电商项目优化订单支付流程
结合电商的业务场景，自然能够想到这样的支付宝接入流程：下单时增加一个定时任务，在五分钟后对订单进行超时判断。超时判断时，可以先去支付宝上查询订单支付状态。如果已支付，则判断订单是否正常结束，这是因为在用户完成扫码支付后，支付宝正常会往电商平台发送支付成功的通知。但是这个通知是没有事务保证的，所以是非常有可能失败的，这时就需要在订单超时判断时对状态进行对齐。如果未支付，则需要释放库存，取消本地订单，
·
目录
1 梳理支付宝当面付的预下单流程
结合电商的业务场景，自然能够想到这样的支付宝接入流程：
下单时增加一个定时任务，在五分钟后对订单进行超时判断。 超时判断时，可以先去支付宝上查询订单支付状态。 如果已支付，则判断订单是否正常结束，这是因为在用户完成扫码支付后，支付宝正常会往电商平台发送支付成功的通知。但是这个通知是没有事务保证的，所以是非常有可能失败的，这时就需要在订单超时判断时对状态进行对齐。
如果未支付，则需要释放库存，取消本地订单，然后通知支付宝取消支付订单。 这种设计方式很自然。但是会有一个小问题，就是对订单状态的判断会不及时。订单支付状态只有在五分钟后的超时判断时才能最终确定，这就不太及时。
那要如何优化呢？通常企业中的做法并不会等到订单超时时才去查询订单状态，而是在后台会多次频繁查询支付宝支付状态，这样可以更及时的获得支付结果。例如五分钟超时时间，至少需要半分钟或者一分钟去查一次支付宝订单状态，如果支付成功了，就及时结束后续等待处理过程。如果没有完成支付，就再开启下一个定时任务，等待下次检查。这样一分析，你会不会觉得这个定时任务光是流程控制就有点麻烦了？再跟业务逻辑绑定在一起，这个任务的逻辑会变得非常复杂。有没有现成的框架可以帮我们来优化这个复杂的定时任务逻辑，让我们只要专心关注业务逻辑呢？有，RocketMQ 的事务消息就是一个比较好的工具。
2 用RocketMQ事务消息改造支付超时判断流程
RocketMQ 事务消息机制的核心是对消息状态进行不断的确认。循环确认的过程就正好可以用来改造，解决上面说的频繁任务调度的问题。这样就可以专注于开发业务逻辑，而不用关注频繁复杂的任务调度逻辑。
在事务状态回查时，会自行记录回查次数，超过最大次数就直接取消订单。如果没有超过最大次数，就可以去支付宝中查询订单支付状态。如果已经支付完成，则返回ROLLBACK 状态，消息取消，后续就不会再进行本地订单取消了。 如果未支付，则记录回查次数后，返回UNKNOWN 状态，等待下次回查。如果事务消息最终发送出去，也就是订单已经超时，就会将消息发送到RocketMQ 。下游的消费者 就会完成取消本地订单，释放库存等操作。
在这个流程中，表面上利用 RocketMQ 的事务消息机制将频繁的定时任务拆解成事务回查的过程，实际上是通过不断的事务回查来确保分布式事务的最终一致性。
电商企业物流数字化转型必备！快递鸟 API 接口，72 小时快速完成物流系统集成。全流程实战1V1指导，营造开放的API技术生态圈。
更多推荐
19
0- 0
已为社区贡献1条内容
所有评论(0)