后发的请求先到，先发的请求后到，还有这等事？一起看看占坑防重大法。
| 更多事故分享，请锁定：甲蛙全栈 |
1 开篇
之前分享过一篇文章《资深码农经验分享系列之项目开发》，里面提到了一个事故，多个请求顺序错乱，本期就展开说说这个事故，希望各位小伙伴能有所收获。
这是好几年前的事故了，当然现在也会出现请求错乱，只是由于当年采取的解决方案延续至今，所以没再造成事故。
小伙伴们应该都在超市买过东西，刷过POS机，POS机可以做支付，也可以做退货等。本期事故主要出现在支付这个功能。
2 正常逻辑
介绍下POS机支付的两个基本流程：
支付：刷卡或扫码交易，POS机发请求到支付公司，支付公司再发到银联扣你（客户）的钱，之后再给商户的虚拟余额加钱。（后面有结算流程，支付公司会统一结算，按虚拟余额的钱，从公司的银行卡里转钱到商户银行卡里，并将虚拟余额清0，完成一轮支付到结算的流程）
冲正：取消上一次交易，当在支付时，扣你（客户）的钱出现异常了（支付接口异常失败或假设30秒超时），POS机要调用一次冲正接口，取消交易，如果银行已经把钱扣了，那么会原路退回你卡里。
这里有个注意点，冲正是一定成功的，只要机具发起冲正，就认为这笔交易不算数了，否则容易引起客户和商户纠纷，客户说钱扣了，商户说钱没到账，这商品是给还是不给？
3 事故现象
按上面的逻辑，对于同一个订单号，支付系统应该先收到支付请求，（如果有冲正，）后面再收到冲正请求，并且间隔按上面说的是30秒间隔。
但是生产上却偶尔出现一种现象，同一个订单号，冲正先到，支付后到，从系统日志上可以看出来。
后发的请求先到，先发的请求后到，绝望……
4 导致后果
虽然是偶发的，但后果很严重。
冲正先到后，找不到原始交易，正常返回机具，商户认为这笔交易不算数，要求客户再支付一笔。
交易后到，按正常逻辑把客户的钱给扣了，给扣了，扣了，了……
由于机具已经认为失败了，没有发起签名，所以扣下的钱，不能转给商户，这笔钱实际在支付公司手里。
如果这个场景只是发生在超市里，问题不大，客户再支付一笔。隔天对账后，上一笔钱是可以退回给客户的。
但是如果是大额交易场景，比如买房买车买墓地，就容易引起纠纷。特别是发生在医院，事情就大条了，手术就要开始了，没钱再支付第二次了……
5 事故原因
网络不靠谱，比如防火墙抖下，所有的请求全卡住了，过一段时间，网络通了，所有请求不分先后过来了，就可能造成后发先到，先发后到的现象
网络中的每个环节都可能出现问题，网络运营商也有可能，毕竟阿里网线被挖断也是有过的事。
6 解决方案
解决方案很简单，就是占个坑，这是一种常见的，利用数据库防重的做法。
当冲正发现没有原始交易时，就补落一条同订单号的交易，占个坑。
后面收到交易请求后，发现这个订单号已经有记录了，那就不做任何处理。
对商户和客户来说就是重新再做一笔交易的事。
7 案例扩展
这种情况不仅存在于先后两个接口，还可能出现在同一个接口。
比如常见的提交订单，为了防止重付提交，前端一般在点击按钮后，有个Loading效果，Loading结束后才能再次点击提交。
但是我们从日志上发现，同一个人提交的两笔订单差1ms，原因是一样的，两次请求在客户端可能隔了10秒，由于网络卡了，同时到达后端，就变成差了1ms
后端接口设计原则：不要相信前端，所有前端的设计都是不靠谱的，Loading也没用
比如参数校验，所有前端的参数校验都是可以被绕过的，知名网站“知乎”也有这种BUG，以后再出一篇以“知乎”为例，教大家绕过别人网站上的校验
本期事故就给大家分享到这里，各位小伙伴有什么想法，欢迎留言讨论！
—————— THE END ——————
