记录一次线上redis分布式锁的事故
场景举例
- 事故级别:P0
- 事故判责:营销活动推广用户较多,影响范围较大,研发整改代码并做复盘。
- 事故名称:秒杀方案独占竞态实现问题
- 事故现象:线上监控突然报警,CPU占用高,拖垮整个服务。用户看到可以购买,但只要一点下单就活动太火爆,换个小手试试。造成了大量客诉,紧急下线活动排查。
- 事故描述:这个一个商品活动秒杀的实现方案,最开始的设计是基于一个活动号ID进行锁定,秒杀时锁定这个ID,用户购买完后就进行释放。但在大量用户抢购时,出现了秒杀分布式锁后的业务逻辑处理中发生异常,释放锁失败。导致所有的用户都不能再拿到锁,也就造成了有商品但不能下单的问题。 事故处理:优化独占竞态为分段静态,将活动ID+库存编号作为动态锁标识。当前秒杀的用户如果发生锁失败那么后面的用户可以继续秒杀不受影响。而失败的锁会有worker进行补偿恢复,那么最终会避免超卖以及不能售卖。
- 学习总结: 核心的技术实现需要经过大量的数据验证以及压测,否则各个场景下很难评估是否会有风险。当然这也不是唯一的实现方案,可以根据不同的场景有不同的实现处理。
文档信息
- 本文作者:L1Chenxv
- 本文链接:https://l1chenxv.github.io//fragment/seckill-accident/
- 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)