基于Spring Boot电商系统：Redisson分布式锁(tryLock)防超卖方案评估

我正在用Spring Boot、Spring Data JPA（MySQL）和Redis构建中型电商Web应用，核心要解决并发订单创建时的超卖问题（避免竞态条件）。目前计划用Redisson分布式锁的快速失败模式（tryLock）包裹数据库事务，以下是OrderService的简化实现：

@Service
@RequiredArgsConstructor
public class OrderService {

    private final RedissonClient redissonClient;
    private final TransactionTemplate transactionTemplate;
    
    public OrderResponse createOrder(OrderRequest request) {
        // 1. 排序商品ID避免死锁
        List<Integer> sortedIds = getSortedProductIds(request);
        
        // 2. 创建多锁
        RLock multiLock = getRedissonMultiLock(sortedIds);
        
        boolean isLocked = false;
        try {
            // 3. 快速失败式尝试加锁（最多等待2秒）
            isLocked = multiLock.tryLock(2, TimeUnit.SECONDS);
            
            if (!isLocked) {
                // 高竞争下直接返回系统繁忙
                throw new SystemBusyException("System is busy, please try again later.");
            }
            
            // 4. 在锁内执行数据库事务
            return transactionTemplate.execute(status -> {
                // 读取MySQL库存 -> 校验库存 -> 扣减库存 -> 保存订单
                return executeOrderCreationDBLogic(request);
            });
            
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("Thread interrupted");
        } finally {
            if (isLocked) {
                multiLock.unlock();
            }
        }
    }
}

1. 高并发场景下的快速失败模式是否合理？ #

这种快速失败的熔断式保护是合理的，而非反模式，核心原因有两点：

• 系统资源保护：秒杀场景下10000个请求同时涌入，若强行让所有请求排队，会导致Redis锁等待队列过长、数据库连接池耗尽，最终引发系统雪崩。2秒的等待窗口既能过滤掉大部分无效请求，又能让真正有机会下单的用户（比如前几十名）完成操作，避免系统被压垮。
• 用户体验平衡：虽然大部分用户会收到“系统繁忙”提示，但相比让所有用户无限等待直到超时，明确的反馈反而能降低用户焦虑。可以配合前端优化（比如按钮置灰、倒计时提示），引导用户稍后重试，体验反而优于无响应的加载状态。

也可以做针对性优化：比如根据商品库存动态调整等待时间——库存充足时延长等待窗口，库存不足时缩短甚至直接快速失败；或者引入队列削峰（比如用Redis队列缓存请求，异步处理订单），但快速失败是秒杀场景下最直接有效的兜底方案。

2. 事务包裹在Redis锁内是否安全？ #

是安全的，能确保事务提交完成后再释放锁，但要注意几个细节：

• Spring的TransactionTemplate.execute()方法是同步执行的，只有当事务提交（或回滚）完成后，代码才会走到finally块的解锁逻辑。也就是说，锁的释放时机严格晚于数据库事务的结束，不会出现“锁提前释放导致其他请求读到未提交数据”的问题。
• 风险点：如果事务执行过程中出现JVM崩溃、网络中断等极端情况，Redisson的锁会因为看门狗机制自动续期，直到锁超时（默认30秒），不会出现永久死锁。但要确保锁的超时时间大于事务的最大执行时间，避免事务还没提交锁就过期。
• 额外注意：不要在事务内部调用解锁逻辑，必须放在finally块中，防止事务回滚时锁没被释放。

3. 乐观锁vs分布式锁：哪种更适合中型应用？ #

两种方案各有优劣，要结合业务场景选择：

乐观锁（@Version）的优势： #

• 实现简单：不需要引入Redis依赖，只需要在Product实体上加@Version注解，扣减库存时用update product set stock = stock -1, version = version +1 where id = ? and version = ? and stock >=1，失败则抛出乐观锁异常。
• 无网络开销：完全依赖数据库，避免了Redis锁的网络往返延迟，在中等并发（比如每秒几百到上千请求）下性能更优。
• 避免锁竞争：不会像分布式锁那样让请求排队，而是让冲突的请求快速失败，适合库存充足、并发不是极端高的场景。

分布式锁的优势： #

• 强一致性：在秒杀这种极端高并发、库存极少的场景下，分布式锁能确保同一时间只有一个请求操作库存，避免大量乐观锁失败导致的事务回滚，减少数据库压力。
• 支持多商品锁：如果订单包含多个商品，乐观锁需要逐个校验，容易出现部分商品扣减成功、部分失败的情况；而Redisson的MultiLock可以一次性锁住所有商品，保证订单的原子性。

中型应用的选择建议： #

如果你的电商以日常销售为主，秒杀只是偶尔的营销活动，优先用乐观锁——实现简单、维护成本低，足够应对大部分并发场景。如果秒杀是核心业务场景，或者经常有多个商品的订单，再引入分布式锁，同时可以结合乐观锁做二次校验（比如锁内扣减库存时再加乐观锁，防止锁超时导致的超卖）。

内容的提问来源于stack exchange，提问作者Nguyễn Trung Nghĩa