订单重复提交掉单问题硬解析(初级程序员毕业门槛)

解决支付订单，重复提交问题！-CSDN博客   (这是原文章地址)

这篇文章其实写得挺好,近期我因工作需要,去修改了别人设计的订单系列接口,和文章中的结构类似,当然没有文章中设计得那么全面(实际工作中的代码都这样,特别是中小公司)

那这篇文章已经写很好了,我写啥?

两点: 1,宏观分析    2,给你一条行为线,让你能重现整个场景.

1,宏观分析.我们可以很多老程序员经常说的一个观点入手,业务为王,技术其次.

什么叫业务,上文整个对订单这个事情的各种安排,合在一起,就是业务.说到这里我相信各位是不理解的,我们继续拆分,这个订单支付问题牵扯几个主体:  客户,我们的系统,微信支付系统.  

主体有三方,而我们平时学习和测试项目,都是两方,而多一方主体,就多一种可能性,而解决多方协作有可能产生的问题的过程,就是所谓的业务.也就是逻辑.

(大家先不用去想这里我对逻辑的解释,大家只需要把这个过程简单理解为,解决复杂问题.)

解决复杂问题的第一步,先简化问题.要理解这个观点,我们就引入了两个关键词了,这也是各大面试题中经常出现的两个词:   幂等性和最终一致性.

这两次我以前听着真的很恶心,但理解之后,这两词的确是在试图简化复杂问题.

幂等性:               有些动作只能做一次(例如付款)[这就解决了重复付款,带来各种退款,商议等等各种奇怪事情]

最终一致性:        有些动作是几个动作合在一起的,所以要么一起成功,要么一起失败.[这样就直接避免了去判断n个动作中到底哪个动作出了问题,或者视图修复某一个细微的动作,而是直接将整个链条当做一个动作处理,对复杂问题进行了简化]

额,好像解释和原文章类似.   补充一点吧,就是上诉关联的三方,只有微信支付是我们不可控的,所以很多节点都是围绕请求微信支付这个外部接口后,才来操作的.

再说三个总结话术:

1,调用微信接口之前和之中,出现任何问题,说明支付行为这个关键行为没发生,所以,一切服务这个行为的辅助行为应当全部失效.  (技术实现主要就是事务)

2,只要调取微信支付这个接口,顺利执行了,就说明关键行为已经发生,那么这个时候就必须利用一切手段,多个方面,让系统知晓这个事,多个点互相应证,自然就能够减少问题出现的可能.(技术实现就是,,主动查询,被动验证[表设计,字段设计,缓存])

好了,理论到此为止了.下面的内容就是从建立一个项目,给大家复现一下上述问题.只有上手,才能学会(当然,得后面空了继续写,目前文章就到此结束,工作繁忙啊...)