前几天的新坑,还热乎着呢,赶紧拿来给大家分享一下.我相信不认真看我的文章,你如果做这个功能,会有99%的挖坑的可能,哈哈!
声明:我这里都是用一些简单流程,简单表等做一个设想,实际业务场景会比举例复杂很多!
先列几个名词:
表 t_order_pay 有个支付状态pay_state 有这么几个值
I:init 初始状态
U:unknown 未知(处理中)状态
S:success 成功状态
F: fail 失败状态
用户在购买商品的时候,支付结果显示未知,但是购买商品状态已经是发货中. 导致我们的结果,跟实际代付的结果不一致!
发生这个问题的原因是:
我先上图哈!
0.数据入库状态 为I
1.请求代扣(耗时比较长或者网络问题导致)
2. 在第1步还在等待的时候,回调请求进来了,把状态I -> S,通知商家发货
3.第1步在等了好长时间后超时了,处理处理把状态修改为 U (注意,这里跟本没有检查库里的原来状态,直接修改为了U)
最终成我们上在说的状态不一致的结果!!
上重点:正确的处理方式
1.不要幻想,回调一定发生在请求之后!!
2. 每次一定要带上原状态值的条件,第三部的处理应该是update t_order_pay set pay_state = U where pay_order=XXX and pay_state = I 并且在必要时(看业务)通过update后影响的行数做后续处理!
这里更多的是提醒大家,在设计程序的时候要多考虑异常情况,错误情况发生后程序怎么处理。
我看过太多人。处理问题,只有成功,失败!跟本没有异常,超时等处理逻辑,一上线就是各种问题!!