-
接口幂等性设计完全指南:从一次"用户被扣了两次款"看懂前端置灰按钮为什么挡不住重复请求
2023 年我做一个电商的下单接口用户在前端点提交订单后端创建一笔订单扣一次款这件事我没多想就有了方案接口收到请求插入一条订单记录调支付返回成功第一版我做得很顺手为了防止用户手抖点两下我还特意在前端做了处理点击之后按钮立刻置灰本地点几下订单一笔一笔干净利落我心里很笃定重复提交嘛前端把按钮一灰用户想点第二下也点不了可等真实用户用起来一串问题冒了出来第一种最先把我打懵还是有用户创建了两笔一模一样的订单…- 2
- 0
-
API 版本管理完全指南:从一次"改个字段名、第三方集成方全线崩溃"看懂契约思维与版本演进
2023 年我做一个后端服务对外提供 API。改接口这件事我压根没多想。第一版我做得很省事接口要改直接在原来的函数上改字段不好看就改个名字段没用就删掉反正都是我的代码我想怎么改怎么改。本地开发时真不错接口和调它的前端都是我自己写的我改完接口顺手把前端也改了两边一起更新从来没出过岔子。我心里很踏实接口嘛不就是一段返回 JSON 的代码想改就改。可等这个服务真正上线接口被一群我控制不了的客户端用起来一…- 2
- 0
-
接口幂等性完全指南:从一次"用户点了两下、扣了两次钱"看懂幂等设计
2023 年我做一个支付下单接口。逻辑很简单:用户点支付,前端把请求发到后端,后端扣款然后创建订单。第一版做得很直接本地测上线初期都挺好。可上线一段时间后客服转来一个投诉:有用户说自己只买了一件东西却被扣了两次钱后台还生成了两个一模一样的订单。我翻日志发现同一个用户同样的金额几乎同一时刻有两条一模一样的请求打进了后端。我第一反应是用户手抖点了两下让前端在点击后把按钮禁用掉结果还是有重复。我又翻了更…- 4
- 0
-
接口幂等设计完全指南:从一次"网络重试把用户扣款扣了两次"看懂幂等
2019 年我做一个电商的下单支付接口,逻辑很直白:用户点提交订单,后端创建一条订单记录,从余额里扣钱,返回订单号。本地测试一切正常,上线后也好好的。直到客服转来一个投诉:一个用户只下了一单却被扣了两次钱。我查日志发现这个用户的下单接口在几秒内被调用了两次,参数一模一样,数据库里多了两条几乎相同的订单,扣款也执行了两遍。我第一反应是用户手抖点了两次,可继续查下去发现根本不是——很多重复请求用户只点…- 2
- 0
-
接口幂等性完全指南:从一次"网络抖动让用户被扣了两次款"看懂幂等设计
2023 年我负责一个支付下单接口,扣余额、生成订单、返回成功。测试一路绿,上线几个月后客服转来投诉:一个用户只买了一次,余额被扣两次,订单列表躺着两笔一模一样的订单。翻日志才发现那个请求在服务器上确确实实被完整执行了两次。问题不在我的逻辑,在它之外:用户网络抖了一下,第一次请求其实已处理完,但响应在回程丢了,前端超时自动重发,第二次又被老老实实执行了一遍。我以为接口自己不写 bug 就不会重复扣…- 0
- 0
-
用户付了两次款:一次接口幂等性设计的复盘
用户只下一单却被扣两次款:网络卡用户点了两次、网关又自动重试了一次。重复请求是分布式系统的常态,躲不掉只能接住。几天梳理改造:唯一索引兜底、幂等号+去重表、状态机 CAS 更新、Token 防重复提交、分布式锁配合,以及幂等的边界。- 5
- 0
-
接口幂等设计实战:从一次重复扣款事故说起
支付系统出过一次后背发凉的事故:用户被同一笔订单扣了两次款。根因是前端网络抖动时重试了提交请求,而下单接口压根没做幂等。一周治理:理清哪些写接口必须幂等、补数据库唯一索引兜底、幂等号前置查重、token 机制防表单重复提交、状态机幂等。同一请求并发重放 200 次只落 1 笔订单。- 0
- 0
接口设计
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×