-
分布式 ID 生成完全指南:从一次"两台机器同时生成了一样的订单号"看懂雪花算法
2021 年我做一个订单系统要给每一笔订单生成一个全局唯一的订单号。第一版我做得很省事订单表是 MySQL 我直接用了表的自增主键当订单号。本地一测完美每插一条订单 ID 自动加一从不重复。我心里很踏实生成唯一 ID 嘛数据库自增不就行了要么随手 UUID 一下。可等系统真正长大扛着真实的业务量一串问题冒了出来。第一种最先把我打懵订单量上来后我做了分库分表把订单拆到两个库结果两个库各自从 1 开始…- 0
- 0
-
接口幂等性完全指南:从一次"用户点了两下、扣了两次钱"看懂幂等设计
2023 年我做一个支付下单接口。逻辑很简单:用户点支付,前端把请求发到后端,后端扣款然后创建订单。第一版做得很直接本地测上线初期都挺好。可上线一段时间后客服转来一个投诉:有用户说自己只买了一件东西却被扣了两次钱后台还生成了两个一模一样的订单。我翻日志发现同一个用户同样的金额几乎同一时刻有两条一模一样的请求打进了后端。我第一反应是用户手抖点了两下让前端在点击后把按钮禁用掉结果还是有重复。我又翻了更…- 0
- 0
-
接口幂等设计完全指南:从一次"网络重试把用户扣款扣了两次"看懂幂等
2019 年我做一个电商的下单支付接口,逻辑很直白:用户点提交订单,后端创建一条订单记录,从余额里扣钱,返回订单号。本地测试一切正常,上线后也好好的。直到客服转来一个投诉:一个用户只下了一单却被扣了两次钱。我查日志发现这个用户的下单接口在几秒内被调用了两次,参数一模一样,数据库里多了两条几乎相同的订单,扣款也执行了两遍。我第一反应是用户手抖点了两次,可继续查下去发现根本不是——很多重复请求用户只点…- 0
- 0
-
分布式锁完全指南:从一次"扩容后对账任务跑了三遍、结算被重复打款"看懂分布式锁
2023 年我维护一个对账定时任务,每天凌晨核对订单和支付流水、生成结算单、发结算邮件。单实例跑了大半年稳稳当当,直到运维把服务从 1 个实例扩容到 3 个,第二天就出事:同一用户收到三封结算邮件,有几笔结算被重复打款。翻代码一行 bug 都没有,盯着部署结构才反应过来:定时任务代码被原封不动部署到 3 个实例上,凌晨那一刻 3 个实例各自都跑了一遍。我以为代码里加了 Lock 就并发安全,真相是…- 0
- 0
-
接口幂等性完全指南:从一次"网络抖动让用户被扣了两次款"看懂幂等设计
2023 年我负责一个支付下单接口,扣余额、生成订单、返回成功。测试一路绿,上线几个月后客服转来投诉:一个用户只买了一次,余额被扣两次,订单列表躺着两笔一模一样的订单。翻日志才发现那个请求在服务器上确确实实被完整执行了两次。问题不在我的逻辑,在它之外:用户网络抖了一下,第一次请求其实已处理完,但响应在回程丢了,前端超时自动重发,第二次又被老老实实执行了一遍。我以为接口自己不写 bug 就不会重复扣…- 0
- 0
分布式系统
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×