高并发场景订单问题解决思路(取消付款-重复下单-多平台付款)

目录

场景一

情况一

情况二

数据库层面

业务小优化

Redis 分布式锁实现

场景二

场景三

支付回调的幂等性处理

场景一

一笔订单，在取消的那一刻用户刚好付款了，怎么办?

这种情况在正常的业务场景中是有可能出现的，因为订单都会有定时取消的逻辑，比如 10 分钟或者15分钟，而用户刚好卡在这个时间点进行付款，此时就会出现两种情况

情况一

用户支付成功，支付回调的那一刻支付单刚好还没取消，而等回调结束，取消支付单的事务提交，支付单取消。此时用户扣款了，但是对应的权益或资产没了。

情况二

用户支付成功，支付回调的那一刻支付单已经被取消。但此时用户已经扣款，东西却没了

这个问题涉及到并发处理和事务一致性的问题。在高并发系统中，这种情况是可能出现的，并需要通过合理的架构设计来解决。下面是一种可能的解决方案:

数据库层面

这种场景无非就是支付单支付成功和取消两种状态的“争夺”，正常情况下，订单或者支付单都会有状态机的存在，在当前场景简单来说有以下两条路径:

1. 待支付->支付中->支付成功 ：当用户完成支付后，系统尝试将订单状态从“支付中”改为“支付成功”。

2. 待支付->支付中->已取消 ：如果系统决定取消订单，会尝试将订单状态从“支付中”改为“已取消”。

针对情况1，如果是支付回调取胜，此时的状态应该已从 支付中->支付成功

针对情况 2，如果是取消支付单取胜，此时的状态应该已从 支付中->已取消

所以我们在修改支付单状态的时候，基于原始状态的判断，就可以做正常的处理，来看下 SQL 应该就很清晰

# 支付成功调用语句
update pay_info set status = 'paySuccess' where orderNo = '1' and status = 'paying';  

# 取消操作 调用语句
update pay_info set status = 'cancel' where orderNo = '1' and status = 'paying';
# 如果支付成功的