-
我用 Redis 加了分布式锁保护临界区,以为万无一失,结果偶发两个进程同时进了临界区、一个进程还把别人的锁给删了:一次分布式锁实现陷阱的深度复盘
我有段临界区代码用 Redis 加了分布式锁保护:SET lock NX EX 30 抢锁、处理完 DEL 释放,以为万无一失。可线上偶发两个进程同时进入临界区的数据错乱,有时还有一个进程把另一个进程正持有的锁删了。推演时序才看明白这锁有两个致命漏洞:漏洞一,锁 EX 30 过期了但业务还没跑完,锁自动释放、B 抢到、A 和 B 同时在临界区;漏洞二,释放时直接 DEL 没校验是不是自己的锁,A …- 0
- 0
-
一个在 forEach 回调里写 await 的批处理脚本,以为会一个个等着处理完,结果还没处理完就往下走、还吞掉了异常:一次 JavaScript 异步遍历的深度复盘
数据迁移脚本用 forEach 遍历、在回调里 await 逐条同步,处理完打印'全部同步完成'。结果那句几乎立刻就打印了(其实没同步完),而且某条失败抛的异常外层 try-catch 一个都没抓到、变成了 UnhandledPromiseRejection。根因是 Array.prototype.forEach 是同步遍历、完全忽略回调返回的 Promise、不会等待 awa…- 4
- 0
-
一个 Redis 分布式锁的过期时间没扛住业务耗时,锁提前自动释放让两个线程同时进了临界区、还互相误删了对方的锁:一次分布式锁失效的深度复盘
用 Redis 分布式锁保证同一笔账只有一个节点处理,跑了大半年都好好的,直到对账量大、业务跑了 40 秒、超过了锁的 30 秒过期时间——锁中途自动释放,第二个线程进了临界区两线程同时处理,第一个线程干完 del 又删掉了第二个线程的锁,锁彻底形同虚设。本文讲透分布式锁的两大核心难题(过期时间两难、误删),给出唯一标识+Lua 原子校验删除防误删、看门狗自动续期解决过期、生产用 Redisson…- 0
- 0
-
Redis 分布式锁完全指南:从一次"同一笔订单被扣三次款"看懂 SET NX EX 为什么不是分布式锁
2023 年我接手一个老项目里面有个用 Redis 做的分布式锁场景是订单去重防止用户连续点击下单按钮造成重复扣款这套锁跑了两年没出过事我以为它就是稳的某天大促当晚一个用户疯狂连点付款页面客服那边几分钟后就传来同一笔订单被扣了三次的截图我打开日志一看三次请求确实都拿到了锁三次都执行了下单我去翻代码这把锁的实现是经典的 SET key value EX 30 NX 加锁成功就执行业务执行完 DEL …- 0
- 0
-
接口幂等性设计完全指南:从一次"用户被扣了两次款"看懂前端置灰按钮为什么挡不住重复请求
2023 年我做一个电商的下单接口用户在前端点提交订单后端创建一笔订单扣一次款这件事我没多想就有了方案接口收到请求插入一条订单记录调支付返回成功第一版我做得很顺手为了防止用户手抖点两下我还特意在前端做了处理点击之后按钮立刻置灰本地点几下订单一笔一笔干净利落我心里很笃定重复提交嘛前端把按钮一灰用户想点第二下也点不了可等真实用户用起来一串问题冒了出来第一种最先把我打懵还是有用户创建了两笔一模一样的订单…- 2
- 0
-
数据库事务隔离级别完全指南:从一次"开了事务库存还是被超卖"看懂脏读幻读到底怎么挡
2023 年我做一个电商系统的库存扣减功能用户下单系统从商品库存里减掉相应的数量这件事我没多想就有了方案开个事务把查库存判断够不够扣库存这几步包进去第一版我做得很顺手我在代码里 BEGIN 先 SELECT 出当前库存在程序里判断库存够再 UPDATE 把库存减掉最后 COMMIT 本地点几下下单扣库存数字一分不差我心里很笃定并发安全嘛把这几步包进一个事务里数据库自然就帮我管好了可等大促一来并发一…- 2
- 0
-
分布式锁完全指南:从一次"多实例部署后库存被超卖"看懂为什么单机锁挡不住分布式并发
2023 年我做一个电商的库存扣减接口用户下单要先扣库存怎么保证不会超卖这件事我没多想就有了方案加锁第一版我做得很顺手在扣库存的那段代码外面用一把锁圈起来同一时刻只放一个请求进去查库存够不够够就扣不够就拒绝本地一压测真不错并发再高库存也扣得分毫不差从来不会扣成负数我心里很笃定我都加锁了临界区同一时刻只有一个请求并发安全这不就有了可等这个接口真正上线被部署成多个实例扛起生产流量一串问题冒了出来第一种…- 4
- 0
-
数据库死锁完全指南:从一次"大促下单成片失败、库存还被扣两次"看懂死锁的根治
2022 年我做一个电商的下单系统下单时要在一个事务里挨个扣减购物车里每个商品的库存。第一版我做得很省事拿到购物车的商品列表就按列表里的顺序一个个 UPDATE 过去。本地我下了几十单测了测真不错库存扣得准订单也对得上。我心里很踏实事务嘛把要改的几行包进一个 BEGIN COMMIT 数据库自己会保证一致。可等这个系统真正上线扛起大促的并发下单一串问题冒了出来。第一种最先把我打懵后台日志里时不时蹦…- 43
- 0
-
大模型 API 并发完全指南:从一次"开 100 个线程狂调 API、结果全被 429 打回"看懂限流应对
2024 年我做一个批量处理功能要给几万条数据每一条都调一次大模型 API 去做分析。第一版我做得很省事既然要快那就开一个线程池放 100 个 worker 一起往外发请求。本地我拿几十条数据测了测真快几十条几秒钟就跑完了。我心里很踏实调大模型 API 要快嘛就是多开几个线程一起猛发发得越猛越快。可等它真正上线去跑那几万条真实数据一串问题冒了出来。第一种最先把我打懵跑了没几分钟日志里开始刷屏 42…- 0
- 0
-
数据库事务隔离级别完全指南:从一次"两个人同时下单、库存被卖成了负数"看懂脏读幻读
2023 年我做一个电商的库存扣减功能。逻辑看着特别简单用户下单我就查一下库存够不够够就扣减生成订单。第一版我做得很省事查库存判断够不够扣减三步我把它们包进了一个数据库事务里。本地一测毫无问题下单扣库存生成订单一气呵成。我心里很踏实把这几步包进一个事务里它就是原子的就安全了。可等它真正上线撞上大促的高并发一串问题冒了出来。第一种最离谱一个只有 1 件库存的商品居然卖出去了 3 单库存字段变成了负二…- 0
- 0
-
分布式锁完全指南:从一次"加了锁还超卖、库存被扣成负数"看懂分布式锁
2022 年我做一个秒杀活动的库存扣减接口。逻辑很简单:用户下单先查库存够不够,够就扣减一个。第一版在单机上跑,为了防止两个请求同时扣减同一个库存导致超卖,我加了个进程内的锁 threading.Lock。本地压测单机上线都没问题。后来活动流量涨了,运维把服务部署成了三个实例挂在负载均衡后面。某次活动结束我对账,发现一件吓人的事:库存明明只有 100 件,却卖出去了 130 单,超卖了 30 件。…- 2
- 0
并发控制
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×