兄弟们，今天做并发压测差点翻车。
40个并发请求去抢50个库存，按理说最多25人成功。结果压测跑完：成功5个，失败35个，数据库库存居然还剩40个。
数值是守恒的，但吞吐量直接崩盘，而且更诡异的是，本该成功的25个请求被“冤杀”了一大半。
本以为加了 Redis 预扣减、套上 @Transactional 和 Spring Retry 就能完美防超卖，结果一查 Redis，库存居然被扣成了负数！
很多人以为高并发下写个 @Version 乐观锁，或者加个缓存预扣就能高枕无忧，其实跨数据源操作遇上重试机制，分分钟产生致命的“悬挂扣减”。
刚爆肝复盘了耗材系统防超卖方案的三次填坑迭代，最终靠一行原生的 MySQL 原子 SQL 彻底稳住了局面。做秒杀和高并发业务的兄弟，这篇实战避坑指南纯靠压测报错堆出来，建议一定要看看
：