摘要：2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时，订单系统却产生了1200笔有效订单。事故复盘发现，核心问题出在库存服务的这段代码：
2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时，订单系统却产生了1200笔有效订单。事故复盘发现，核心问题出在库存服务的这段代码：
Java// 原始错误实现（已脱敏）public boolean deductStock(Long skuId, Integer quantity) { ItemStock stock = stockMapper.selectById(skuId); // 致命错误1：未加锁 if(stock.getAvailable >= quantity){ stock.setAvailable(stock.getAvailable - quantity); return stockMapper.updateById(stock) > 0; // 致命错误2：非原子操作 } return false;}这个看似合理的实现，在1000QPS的并发请求下，select与update之间的时间窗口成了潘多拉魔盒。更糟糕的是，DBA发现事务日志中出现了诡异的负库存：
SQL-- 事故现场数据库日志UPDATE item_stock SET available=available-2 WHERE sku_id=10086;-- 执行前available=1，执行后available=-1这次事故让我们深刻认识到：在高并发场景下，任何非原子操作都是定时炸弹。这也成为我们技术团队涅槃重生的转折点。
这是我们迈出的第一步，但实测中发现当库存剩余5件时，10个并发请求会有7个返回更新失败（原以为乐观锁能解决所有问题，后来发现需配合请求队列使用）。
Java@Transactionalpublic boolean safeDeduct(Long skuId) { // 必须配合for update使用 ItemStock stock = stockMapper.selectForUpdate(skuId); if(stock.getAvailable > 0){ stockMapper.decrementAvailable(skuId); return true; } return false;}在压测中，这个方案虽然保证了数据安全，但TPS直接跌到50以下。DBA指着监控图吐槽："这曲线比我上周的心电图还平稳，完全没有波动空间！"
Lua-- 库存扣减Lua脚本（关键调试点）local key = KEYS[1]local num = tonumber(ARGV[1])local remain = redis.call('GET', key)if remain and tonumber(remain) >= num then return redis.call('DECRBY', key, num) -- 注意DECRBY返回的是操作后的值else return -1 -- 特意返回-1用于区分库存不足end某次压测中脚本返回-2的诡异值，后来发现是测试同学误传了字符串参数（所有数值参数必须做tonumber转换）。
Javapublic boolean distributedLockDeduct(String skuId) { String lockKey = "LOCK:" + skuId; // 错误示范：未设置过期时间 Boolean locked = redisTemplate.opsForValue.setIfAbsent(lockKey, "1"); try { if(locked){ // 业务逻辑 } } finally { redisTemplate.delete(lockKey); }}这个实现导致了著名的"锁永久失效"事故，后来改用Redisson的看门狗机制才解决。
Java// 将SKU_10086的库存分到10个redisKeyString shardKeys = {"stock_10086_0","stock_10086_1"...}; public boolean shardingDeduct(String skuId, int quantity) { for(String key : shardKeys){ Long remain = redisTemplate.execute(DECRBY_SCRIPT, Collections.singletonList(key), String.valueOf(quantity)); if(remain != null && remain >=0){ return true; // 成功扣减任意分片即可 } } return false;}这种设计将单商品QPS从3000提升到20000+，但需要注意分片数不宜超过16个（经验值）。
Java// 事务消息处理器@RocketMQMessageListener(topic = "STOCK_COMPENSATE", consumerGroup = "group1")public class StockCompensateHandler implements RocketMQListener { @Override public void onMessage(MessageExt message) { // 解析消息 StockOperateLog log = JSON.parseObject(message.getBody, StockOperateLog.class); // 检查订单状态 if(!orderService.checkOrderExists(log.getOrderNo)){ stockService.rollbackStock(log); // 逆向操作 } }}这个方案成功解决了"幽灵订单"问题，但也带来了新的挑战——消息重复消费问题需要幂等处理。
在2024年某头部手机品牌的新品首发中，我们采用了混合方案：
前端拦截层：按钮点击后立即执行localStorage写入，防止连点器攻击（曾拦截过某黄牛组织的10万次/秒的脚本攻击）网关层：按用户ID+设备指纹进行滑动窗口限流库存服务：public ApiResponse deductStock(StockRequest request) { // 阶段1：令牌校验 String token = tokenBucket.acquireToken(request.getSkuId); if(StringUtils.isEmpty(token)){ return ApiResponse.error("手速太快，请稍后再试"); } // 阶段2：库存预占 StockLock lock = stockLockService.tryLock(request); if(!lock.isSuccess){ return ApiResponse.error(lock.getErrorMsg); } // 阶段3：异步落库 stockLogService.asyncSaveLog(lock); return ApiResponse.success("抢购成功");}监控体系：基于Prometheus+Grafana构建实时监控大盘，关键指标包括：库存分片命中率令牌桶剩余容量消息队列积压量在经历了从数据库行锁到分布式事务的完整技术演进后，我们得出三个核心认知：
原子性是生命线：任何非原子操作在高并发场景下都是不可靠的，这包括但不限于：先查后改的非原子SQL未加锁的余额计算未做幂等设计的重试机制监控比预防更重要：我们建立了三级熔断机制：某次大促中，这套熔断机制在1秒内切掉了60%的流量，成功避免了系统雪崩。当运维组的张工看到监控曲线从悬崖式下跌变为平缓下降时，激动得把手中的枸杞茶都洒在了键盘上——这个价值2000块的机械键盘，成为了技术胜利的最佳见证。
在这个充满挑战的技术领域，我们永远在探索更好的解决方案。或许正如某位不愿透露姓名的高级工程师所说："防超卖的终极方案，可能就是让黄牛们都去写代码吧。" 这句话虽然带着程序员的黑色幽默，却也道出了这个领域持续演进的真谛。
来源：电脑技术汇
