在高并发秒杀场景中，“超卖”是程序员最头疼的问题之一。本文从实战角度出发，对比分析Java防超卖的4大核心方案，结合真实代码案例与压测数据，助你选出最优解。

一、超卖的本质与四大核心方案

超卖原因：当多个线程同时读取到同一库存值（如剩余10件），并各自执行减库存操作时，实际扣减总量超过库存上限（如扣减了15次）。本质是 并发读写导致数据不一致 。

核心方案对比：

二、四大方案实战解析

方案1：数据库乐观锁（适合低并发）

原理：通过版本号或时间戳控制并发更新，确保只有 最新版本的数据可修改 。

// SQL示例：通过版本号控制
public boolean updateStockWithVersion(int productId, int version) {
    String sql = "UPDATE product SET stock=stock-1, version=version+1 " 
               + "WHERE product_id=? AND version=? AND stock>0";
    int rows = jdbcTemplate.update(sql, productId, version);
    return rows > 0;
}

优点：实现简单，无需额外组件。
缺点：高并发下数据库压力大，失败率高（如1000并发下成功率仅30%）。

方案2：分布式锁（适合中并发）

原理：通过Redis或Zookeeper实现 全局唯一锁，确保同一时刻仅一个线程操作库存。

// Redis分布式锁示例（Redisson实现）
public boolean deductStockWithLock(String productId) {
    RLock lock = redisson.getLock("stock_lock:" + productId);
    try {
        lock.lock(10, TimeUnit.SECONDS); // 加锁10秒
        int stock = getStockFromDB(productId);
        if (stock > 0) {
            updateStock(productId, stock - 1);
            return true;
        }
        return false;
    } finally {
        lock.unlock();
    }
}

优点：强一致性，防止脏读。
缺点：锁竞争导致性能下降（压测QPS约500），Redis集群故障可能引发雪崩。

方案3：Redis原子操作+消息队列（适合高并发）

原理：利用Redis的 原子性操作（DECR）预减库存，异步队列处理订单。

// Redis预减库存 + RabbitMQ异步处理
public Result<String> seckill(String productId, String userId) {
    Long stock = redisTemplate.opsForValue().decrement("stock:" + productId);
    if (stock < 0) {
        redisTemplate.opsForValue().increment("stock:" + productId); // 回滚
        return Result.error("库存不足");
    }
    // 发送MQ异步处理订单
    rabbitTemplate.convertAndSend("seckill_queue", new SeckillMessage(productId, userId));
    return Result.success("排队中");
}

// 消费者处理订单
@RabbitListener(queues = "seckill_queue")
public void handleOrder(SeckillMessage message) {
    // 检查是否重复下单，最终更新数据库
    updateStockInDB(message.getProductId());
}

优点：QPS可达1万+，异步削峰。
缺点：需保证Redis与数据库的 最终一致性，实现复杂度高。

方案4：库存预减+内存标记（适合极端高并发）

原理：启动时加载库存至 本地内存，通过原子类（AtomicInteger）快速拦截。

// 本地内存标记 + Redis预减
private Map<Long, Boolean> localStockMap = new ConcurrentHashMap<>();

public Result<String> seckill(Long productId) {
    if (localStockMap.get(productId)) {
        return Result.error("已售罄");
    }
    Long stock = redisTemplate.opsForValue().decrement("stock:" + productId);
    if (stock < 0) {
        localStockMap.put(productId, true); // 标记售罄
        return Result.error("库存不足");
    }
    // 后续处理...
}

优点：QPS可达5万+，响应时间<10ms。
缺点：需解决 集群环境下数据同步问题，适合秒杀商品数极少的场景。

三、最佳实践与推荐方案

1.综合最优解：Redis原子操作+消息队列

• 适用场景：99%的秒杀场景，如电商大促、限量抢购。
• 推荐理由：
• 性能与一致性平衡：Redis原子操作拦截大部分请求，MQ异步保证数据库安全。
• 容错能力强：通过库存回滚和重试机制处理异常。

2.极端场景：库存预减+内存标记

• 适用场景：瞬时流量极高（如明星演唱会门票），需快速响应。

四、压测数据对比（JMeter模拟1万并发）

五、避坑指南

1. 防重复提交：前端按钮置灰 + Redis记录用户请求。
2. 库存回滚：MQ消费失败时需回滚Redis库存。
3. 热点Key优化：Redis分片（如商品ID取模）避免单节点瓶颈。

总结：没有银弹方案，需根据业务特点选择。中小项目推荐 Redis+MQ，极端场景可结合 内存标记。