解决支付订单，重复提交问题！-CSDN博客 (这是原文章地址)
这篇文章其实写得挺好,近期我因工作需要,去修改了别人设计的订单系列接口,和文章中的结构类似,当然没有文章中设计得那么全面(实际工作中的代码都这样,特别是中小公司)
那这篇文章已经写很好了,我写啥?
两点: 1,宏观分析 2,给你一条行为线,让你能重现整个场景.
1,宏观分析.我们可以很多老程序员经常说的一个观点入手,业务为王,技术其次.
什么叫业务,上文整个对订单这个事情的各种安排,合在一起,就是业务.说到这里我相信各位是不理解的,我们继续拆分,这个订单支付问题牵扯几个主体: 客户,我们的系统,微信支付系统.
主体有三方,而我们平时学习和测试项目,都是两方,而多一方主体,就多一种可能性,而解决多方协作有可能产生的问题的过程,就是所谓的业务.也就是逻辑.
(大家先不用去想这里我对逻辑的解释,大家只需要把这个过程简单理解为,解决复杂问题.)
解决复杂问题的第一步,先简化问题.要理解这个观点,我们就引入了两个关键词了,这也是各大面试题中经常出现的两个词: 幂等性和最终一致性.
这两次我以前听着真的很恶心,但理解之后,这两词的确是在试图简化复杂问题.
幂等性: 有些动作只能做一次(例如付款)[这就解决了重复付款,带来各种退款,商议等等各种奇怪事情]
最终一致性: 有些动作是几个动作合在一起的,所以要么一起成功,要么一起失败.[这样就直接避免了去判断n个动作中到底哪个动作出了问题,或者视图修复某一个细微的动作,而是直接将整个链条当做一个动作处理,对复杂问题进行了简化]
额,好像解释和原文章类似. 补充一点吧,就是上诉关联的三方,只有微信支付是我们不可控的,所以很多节点都是围绕请求微信支付这个外部接口后,才来操作的.
再说三个总结话术:
1,调用微信接口之前和之中,出现任何问题,说明支付行为这个关键行为没发生,所以,一切服务这个行为的辅助行为应当全部失效. (技术实现主要就是事务)
2,只要调取微信支付这个接口,顺利执行了,就说明关键行为已经发生,那么这个时候就必须利用一切手段,多个方面,让系统知晓这个事,多个点互相应证,自然就能够减少问题出现的可能.(技术实现就是,,主动查询,被动验证[表设计,字段设计,缓存])
好了,理论到此为止了.下面的内容就是从建立一个项目,给大家复现一下上述问题.只有上手,才能学会(当然,得后面空了继续写,目前文章就到此结束,工作繁忙啊...)
标签：这个,动作,订单,微信,问题,程序员,初级,支付,解析 From： https://blog.csdn.net/javacynchronized/article/details/142072706