立刻走下单流程整理

立刻走用户创建的旅游攻略是可以设置付费拷贝的，其他用户想使用必须付费，属于知识付费的一种。我这边整理一下我们的下单付费逻辑，主要涉及支付结果。流程只记录一些不涉及细节的要点，大家看看就好，如果有需要的话可以私信我。

下单支付结果的获取主要分两部分

• 1.被动支付回调更新结果
• 2.主动查询结果

一般来说 由于支付数据的安全和及时性相当重要，我们需要把这两个分别放置到不同业务服务器进行互相支撑
流程要点如下：

• 1. 下单的时候先生成自己系统的订单+微信订单，两个一起存入我们的数据库中，这时候如果有失败就直接返回失败即可，redis数据都存放临时数据，比如我方订单查询凭证（用于外部轮询），如果没失败，返回收银台信息以及我方订单查询凭证
• 2.前端进行轮训查询结果---只查redis
• 3.主动查询和被动回调要加同一把锁，避免状态覆盖或者支付通知重复问题等等
• 4.支付结果一律需要进行缜密的回调，验签、解密流程，防止被薅羊毛

1.主动查询流程

下单以及支付回调流程

2.被动查询流程
被动查询即用脚本进行轮训处理，大部分情况下只是对极端情况的补充，但是处理不好也容易影响正常业务。比如说主动查询和被动通知用的是同一把锁，那么如果我们刚刚支付就开始轮训，有可能造成频繁锁竞争造成一半的查询是浪费性能，那么这里我们用的是初始化订单的时候设定5秒后查询结果的初始设置，大部分情况下这时候我们支付+回调已经结束了。

第二个是如果我们回调过于频繁或者如果我们用的同一个队列。这个时候如果我们有某一小部分订单确实出现的极端的情况，一直没有结果那么很容易造成这一小部分订单不断重新进入审查流程影响正常订单，那么这里我们做了几个操作
1.主动查询订单用单独表记录 检查计数等流程不与其他业务进行耦合。
2.增加检查队列个数先进行一次分流，至于队列具体个数需要看我们服务的流量了
3.采用当前时间具体现在的下单时间差作为下一次查询的时间，这样每次我们查询的时间