与面试官怼项目过程中的思考

我写的一个项目用到了支付，然后面试官照着支付这块开始了一轮攻击。

大概支付流程流程：

这个系统没有往死了打，就问了几个小问题。

1.如果在异步回调判断结果落库过程中因为网络抖动落库失败怎么办？

我回答的是如果我落库失败的话，就把该订单放入本地缓存（可以用ConcurrentHashMap），然后通过定时任务把缓存的数据写回数据库。

2.如果在这时候用户重复提交咋办？

我第一反应居然是谁会这么傻。。。 言归正传，这个可以在用户提交订单的时候，先去本地缓存中去查找有没有该订单，如果有了就把用户返回去，如果就进行修改 （直接进行数据库修改，不进缓存，如果修改失败进缓存）

这个项目面试官还是手下留情了，事后我想这个问题想起来几个把自己打死的问题。

1.如果服务器宕机了怎么办？

死亡一问（我q我自己），先说一个比较有思路的，在回调给你以后，你没有办法去修改数据库 ，把订单存在了本地缓存，这时候服务器发生宕机，那么本地缓存的数据就丢失了。

这样我们可以通过把数据存到redis中，redis配主从加哨兵，这下数据丢不了吧。

那网络问题连不上redis怎么办（快把我打死）

 

其实说了这么多问题也没有完美的办法，如果保证数据完整性 ，那么就一定性能上牺牲。

后来通过通过仔细查看支付宝api还有琢磨，想出来一个还算可以解决问题的方式：

流程：

1.用户发起支付

2.将订单缓存到redis（代表这个订单已经发起支付，如果用户再次支付可以在redis中看有没有发起支付）

3.调用sdk进行扣款，等待回调。

4.判断回调结果，如果成功则更新数据库，然后删除redis中该订单的缓存。如果失败则直接删除redis缓存。

5.在更新数据的时候如果发生网络抖动，我们可以直接把redis修改掉，然后定时任务扫描redis中数据。

如果redis连接不上，存入订单的时候失败，我们可以直接返回给用户false。然后redis采用主从加哨兵。

这时候就还有一个服务器可能宕机的问题了，这个问题的主要难点就在于我们进行了扣款请求，然后回调没来呢，服务器宕机了。这个问题我们这里还真没办法解决，但是支付宝已经为你做好了。

所以我们可以对服务器进行心跳检测，然后发现宕机，及时发送报警邮件。这样我们还有补救的机会。

 

主要是自己项目比较小，面试官可能都觉得没啥可问的。哎。