...
场景
最近在做一个陪玩的业务，我是服务端开发，里面牵扯到了订单以及支付，我们接入的非支付宝或微信，而是公司内部专门的经济系统（支付系统），经济系统的同事提供了以下
1.预扣款接口，这时候用户钱被暂时扣掉，此时还没有进入主播口袋
2.确认接口，主播接单后调用此接口会把预扣款接口扣除的钱打给主播
3.退还接口，调用此接口会把预扣款的钱给退回，一般订单超时或者主播拒绝接单以后会这么调用
业务开发过程中，发现请求经济系统接口有超时的情况，如下图，这时候我们处理方式让经济系统提供一个查询接口，根据uniqid_code去查看订单是否已经生成，如果生成则继续返回
上述环节我们是处理请求支付系统下单接口超时的时候的逻辑，我增加了轮询，可能我们请求支付系统，支付系统超时了，但是过一段时间支付系统请求完成以后我们通过轮询依然拿到了ts_id，可以保障我们业务继续处理下去
但是这种方法还是有漏洞，假如支付系统正好在我们轮询了几次以后停止轮询以后才创建好订单呢，这种情况如果不处理就会出现漏单的情况，所以我们继续补充流程，如下图
订单环节比较重要，牵扯到金钱交易，一定要谨慎再谨慎，切不可完全相信第三方服务，
一定要在我们自己的业务范围内，把各类异常处理好，但即便如此，我们依然无法从技术层面做到100%的保证订单成功（不要杠支付宝的支付，那不是一回事儿），一定是技术+客服+运营 协同处理
原先1W笔订单100笔异常，我们优化后1W笔只有1笔异常，我们就是减轻了运营和客服的100倍的压力，这就是我们所做的贡献