版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/j16421881/article/details/78703792
用户下单后调用第三方支付付款,然后接收第三方支付的异步通知,以便确认支付是否成功。
如下图
但异步通知可能由于网络原因,或者应用服务崩溃没有接收到。为了应对这种情况需要后台创建一个定时任务去调用第三方接口,主动查询支付结果。这种情形下就涉及并发的问题,可能后台定时任务跟异步通知同时收到了支付成功结果,同时对响应数据进行处理。通常通过加锁来避免这种问题。
到了这里一切看起来很美好。代码提交后在测试环境顺利通过。由于测试环境情形单一,测试用例不够,异步通知总是成功的,做为备用手段的后台定时任务没有被测试覆盖到就进入了生产环境。后台定时任务的逻辑有可能是错的,而由于生产环境配置了负载平衡,保证了高可用,直到很久都不会发现定时任务的错误。笔者就遇到过在长达一年的时间里定时任务从来就不起作用。
所以开发要在qa阶段跟测试人员紧密配合,保证每个测试用例都覆盖到,比如关掉异步通知服务,看定时任务是否能正确处理。直到有一天我发现其他部门一位同事采用了一个很有创意的做法,既然异步通知不靠谱,干脆就不要,完全靠后台定时任务主动查询第三方支付结果,然后进一步处理。