专栏首页Java全栈事故分享之接口请求顺序错乱

事故分享之接口请求顺序错乱

1 开篇

之前分享过一篇文章《资深码农经验分享系列之项目开发》,里面提到了一个事故,多个请求顺序错乱,本期就展开说说这个事故,希望各位小伙伴能有所收获。

这是好几年前的事故了,当然现在也会出现请求错乱,只是由于当年采取的解决方案延续至今,所以没再造成事故

小伙伴们应该都在超市买过东西,刷过POS机,POS机可以做支付,也可以做退货等。本期事故主要出现在支付这个功能。

2 正常逻辑

介绍下POS机支付的两个基本流程:

支付:刷卡或扫码交易,POS机发请求到支付公司,支付公司再发到银联扣你(客户)的钱,之后再给商户的虚拟余额加钱。(后面有结算流程,支付公司会统一结算,按虚拟余额的钱,从公司的银行卡里转钱到商户银行卡里,并将虚拟余额清0,完成一轮支付到结算的流程)

冲正:取消上一次交易,当在支付时,扣你(客户)的钱出现异常了(支付接口异常失败或假设30秒超时),POS机要调用一次冲正接口,取消交易,如果银行已经把钱扣了,那么会原路退回你卡里。

这里有个注意点,冲正是一定成功的,只要机具发起冲正,就认为这笔交易不算数了,否则容易引起客户和商户纠纷,客户说钱扣了,商户说钱没到账,这商品是给还是不给?

3 事故现象

按上面的逻辑,对于同一个订单号,支付系统应该先收到支付请求,(如果有冲正,)后面再收到冲正请求,并且间隔按上面说的是30秒间隔。

但是生产上却偶尔出现一种现象,同一个订单号,冲正先到,支付后到,从系统日志上可以看出来。

后发的请求先到,先发的请求后到,绝望……

4 导致后果

虽然是偶发的,但后果很严重。

冲正先到后,找不到原始交易,正常返回机具,商户认为这笔交易不算数,要求客户再支付一笔。

交易后到,按正常逻辑把客户的钱给扣了,给扣了,扣了,了……

由于机具已经认为失败了,没有发起签名,所以扣下的钱,不能转给商户,这笔钱实际在支付公司手里。

如果这个场景只是发生在超市里,问题不大,客户再支付一笔。隔天对账后,上一笔钱是可以退回给客户的。

但是如果是大额交易场景,比如买房买车买墓地,就容易引起纠纷。特别是发生在医院,事情就大条了,手术就要开始了,没钱再支付第二次了……

5 事故原因

网络不靠谱,比如防火墙抖下,所有的请求全卡住了,过一段时间,网络通了,所有请求不分先后过来了,就可能造成后发先到,先发后到的现象

网络中的每个环节都可能出现问题,网络运营商也有可能,毕竟阿里网线被挖断也是有过的事。

6 解决方案

解决方案很简单,就是占个坑,这是一种常见的,利用数据库防重的做法

当冲正发现没有原始交易时,就补落一条同订单号的交易,占个坑。

后面收到交易请求后,发现这个订单号已经有记录了,那就不做任何处理。

对商户和客户来说就是重新再做一笔交易的事。

7 案例扩展

这种情况不仅存在于先后两个接口,还可能出现在同一个接口。

比如常见的提交订单,为了防止重付提交,前端一般在点击按钮后,有个Loading效果,Loading结束后才能再次点击提交。

但是我们从日志上发现,同一个人提交的两笔订单差1ms,原因是一样的,两次请求在客户端可能隔了10秒,由于网络卡了,同时到达后端,就变成差了1ms

后端接口设计原则:不要相信前端,所有前端的设计都是不靠谱的,Loading也没用

比如参数校验,所有前端的参数校验都是可以被绕过的,知名网站“知乎”也有这种BUG,以后再出一篇以“知乎”为例,教大家绕过别人网站上的校验,感兴趣的记得关注公众号:甲蛙全栈

本期事故就给大家分享到这里,各位小伙伴有什么想法,欢迎留言讨论!

—————— THE END ——————

感谢关注甲蛙全栈,好文不错过

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 突破Java面试(39)-分布式服务接口请求的顺序性

    服务 A 调用服务 B,先插入再删除。好,结果俩请求过去了,落在不同机器上,可能插入请求因为某些原因执行慢了一些,导致删除请求先执行了,此时因为没数据所以啥效果...

    JavaEdge
  • 【JavaP6大纲】Dubbo篇:分布式服务接口请求的顺序性如何保证?

    服务 A 调用服务 B,先插入再删除。好,结果俩请求过去了,落在不同机器上,可能插入请求因为某些原因执行慢了一些,导致删除请求先执行了,此时因为没数据所以啥效果...

    java_wxid
  • 13道Flink企业级高频面试题

    相信小伙伴们对于Flink一定不会感到陌生,作为连续三年蝉联第一,荣膺全球最活跃的 Apache 开源项目,Flink在中国的热度也一直是居高不下。近几年,在...

    大数据老哥
  • 超越大数据分析:流处理系统迎来黄金时期

    流处理作为一个一直很活跃的研究领域已有 20 多年的历史,但由于学术界和全球众多开源社区最近共同且成功的努力,它当前正处于黄金时期。本文的内容包含三个方面。首先...

    深度学习与Python
  • 微服务中台技术解析之分布式事务方案和实践

    随着软件系统从单体应用迈向微服务架构以及数据库选型去中心化、异构化的趋势,传统的 ACID 事务在分布式系统上能否延续,如何落地,有哪些注意事项?本文将围绕分布...

    深度学习与Python
  • 程序员没朋友?删注释,学甩锅,这么干就对了!

    昨天我分享了一篇关于收入的个人感悟,没想到如此受欢迎,得到了很多大佬以及读者的点赞。

    程序员小浩
  • 穿梭时空的实时计算框架——Flink对于时间的处理

    Flink对于流处理架构的意义十分重要,Kafka让消息具有了持久化的能力,而处理数据,甚至穿越时间的能力都要靠Flink来完成。

    大数据技术架构
  • 穿梭时空的实时计算框架——Flink对时间的处理

    Flink对于流处理架构的意义十分重要,Kafka让消息具有了持久化的能力,而处理数据,甚至穿越时间的能力都要靠Flink来完成。

    用户6070864
  • 可以穿梭时空的实时计算框架——Flink对时间的处理

    在Streaming-大数据的未来一文中我们知道,对于流式处理最重要的两件事,正确性,时间推理工具。而Flink对两者都有非常好的支持。

    实时计算
  • 接口测试用例设计

    随着测试分析和分层测试的深化,“接口测试”出现在我们视野的频次越来越高。那么接口测的用例设计常用哪些方法呢?本文将详细描述。

    腾讯移动品质中心TMQ
  • 分布式架构知识体系

    节点,时间,一致性,CAP,ACID,BASE,P2P,机器伸缩,网络变更,负载均衡,限流,鉴权,服务发现,服务编排,降级,熔断,幂等,分库分表,分片分区,自动...

    Java团长
  • 误删了公司数据库,但我还是活下来了

    小小科
  • 误删了公司数据库,但我还是活下来了!

    上周我与同事们进行了一次关于职业生涯中搞砸了一些事情的简短谈话。这确实会沦为他人笑柄,却更给我们带来了珍贵的教训。重要的是,我们应该分享那些曾经的错误,这样其他...

    马哥linux运维
  • 误删了公司数据库,但我还是活下来了!

    上周我与同事们进行了一次关于职业生涯中搞砸了一些事情的简短谈话。这确实会沦为他人笑柄,却更给我们带来了珍贵的教训。重要的是,我们应该分享那些曾经的错误,这样其他...

    马哥linux运维
  • 爱奇艺移动端网络优化实践分享:网络请求成功率优化篇

    由于移动网络的复杂性特点,编写高质量、体验好的具备网络通信能力的移动端应用(尤其是即时通讯这类网络质量高度敏感的应用)有很大的挑战性。

    JackJiang
  • 微信小程序之生成指定页面的太阳码

    最近的项目中也是需要生成小程序的邀请太阳码.一开始生成的是个二维码.但是小程序的客户扫了之后总不能让人家跳到H5页面.所以也是研究了一下.一路上也是坎坎坷坷.这...

    桑先生
  • 日志记录规范总结

    然而,日志记录的好坏直接关系到系统出现问题时定位的速度。同时,我们可以通过对日志的观察和分析,提前发现系统可能的风险,避免线上事故的发生。对于服务端开发人员来说...

    江不知
  • 分布式架构知识体系

    节点,时间,一致性,CAP,ACID,BASE,P2P,机器伸缩,网络变更,负载均衡,限流,鉴权,服务发现,服务编排,降级,熔断,幂等,分库分表,分片分区,自动...

    猿天地
  • 极速收藏!巨详细的分布式架构知识体系

    节点,时间,一致性,CAP,ACID,BASE,P2P,机器伸缩,网络变更,负载均衡,限流,鉴权,服务发现,服务编排,降级,熔断,幂等,分库分表,分片分区,自动...

    数据和云

扫码关注云+社区

领取腾讯云代金券