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

这次事故让我们深刻认识到：在高并发场景下，任何非原子操作都是定时炸弹。这也成为我们技术团队涅槃重生的转折点。

技术演进：九层防御体系构建之路

数据库层防护（第三重境界）

乐观锁的救赎

SQL
UPDATE item_stock 
SET available = available - #{quantity}, version = version + 1 
WHERE sku_id = #{skuId} AND version = #{oldVersion}

这是我们迈出的第一步，但实测中发现当库存剩余5件时，10个并发请求会有7个返回更新失败（原以为乐观锁能解决所有问题，后来发现需配合请求队列使用）。

悲观锁的代价

Java
@Transactional
public 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指着监控图吐槽："这曲线比我上周的心电图还平稳，完全没有波动空间！"

缓存层突围（第六重境界）

Redis原子操作

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转换）。

分布式锁的陷阱

Java
public 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个redisKey
String[] 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<MessageExt> {
    @Override
    public void onMessage(MessageExt message) {
        // 解析消息
        StockOperateLog log = JSON.parseObject(message.getBody(), StockOperateLog.class);
        // 检查订单状态
        if(!orderService.checkOrderExists(log.getOrderNo())){
            stockService.rollbackStock(log); // 逆向操作
        }
    }
}

这个方案成功解决了"幽灵订单"问题，但也带来了新的挑战——消息重复消费问题需要幂等处理。

巅峰对决：综合解决方案的诞生

在2024年某头部手机品牌的新品首发中，我们采用了混合方案：

1. 前端拦截层：按钮点击后立即执行localStorage写入，防止连点器攻击（曾拦截过某黄牛组织的10万次/秒的脚本攻击）
2. 网关层：按用户ID+设备指纹进行滑动窗口限流
3. 库存服务：

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("抢购成功");
}

4. 监控体系：基于Prometheus+Grafana构建实时监控大盘，关键指标包括：库存分片命中率令牌桶剩余容量消息队列积压量

防超卖的本质思考

在经历了从数据库行锁到分布式事务的完整技术演进后，我们得出三个核心认知：

1. 原子性是生命线：任何非原子操作在高并发场景下都是不可靠的，这包括但不限于：

• 先查后改的非原子SQL
• 未加锁的余额计算
• 未做幂等设计的重试机制

2. 性能与安全的平衡：通过分级降级策略，在极端情况下优先保障核心链路：

• 当Redis集群CPU>80%时，自动切换为本地Guava缓存
• 数据库连接池满时，启用库存本地预扣模式

3. 监控比预防更重要：我们建立了三级熔断机制：

• 库存波动异常熔断（5秒内波动超过库存总量20%）
• 订单创建失败率熔断（失败率>30%持续10秒）
• 支付回调超时熔断（超时率>50%持续30秒）

某次大促中，这套熔断机制在1秒内切掉了60%的流量，成功避免了系统雪崩。当运维组的张工看到监控曲线从悬崖式下跌变为平缓下降时，激动得把手中的枸杞茶都洒在了键盘上——这个价值2000块的机械键盘，成为了技术胜利的最佳见证。

在这个充满挑战的技术领域，我们永远在探索更好的解决方案。或许正如某位不愿透露姓名的高级工程师所说："防超卖的终极方案，可能就是让黄牛们都去写代码吧。" 这句话虽然带着程序员的黑色幽默，却也道出了这个领域持续演进的真谛。