假设商品库存不足了，如何防止超卖_

场景题与系统设计_订单支付类 0 45

首先我先解释下什么是超卖?

在支付场景中，订单超卖（即库存不足时仍然允许用户下单）是一个非常重要的问题，特别是在高并发的情况下。超卖通常会导致用户购买到已售完的商品，进而影响用户体验和造成运营风险。

下面是一些防止超卖的策略，大家选一种自己最熟的就行，这样临场也不慌张。

1. 库存锁定机制

库存锁定是一种常用的防止超卖的方法。在用户提交订单时，系统会先锁定库存，确保在用户支付成功之前，库存不能被其他用户购买。锁定库存的常见做法有以下几种：

1.1 悲观锁

悲观锁在数据库层面锁定库存，直到用户完成支付或者超时取消。锁定期间，其他用户无法再购买该商品。

实现方式：使用数据库的锁机制（如 SELECT ... FOR UPDATE）锁定商品库存记录，直到支付完成或取消。

示例：

SELECT * FROM products WHERE id = ? FOR UPDATE;

优点：确保同一时间只有一个用户可以对库存进行修改。
缺点：可能导致性能瓶颈，尤其是在高并发场景下。

1.2 乐观锁

乐观锁允许多个用户同时查询库存，但在库存更新时会检查库存数量是否与查询时一致。如果库存发生了变化，则拒绝更新。

实现方式：在库存记录中增加一个版本号字段，每次更新时检查版本号是否一致。如果一致，则更新库存，否则拒绝操作。

示例：

public class Product {
    private Long id;
    private Integer stock;
    private Integer version;  // 版本号，用于乐观锁控制
}

更新库存时：

public void updateStock(Long productId, Integer quantity, Integer version) {
    //下面这行语句的意思:
    //只有在商品的库存足够且版本号一致时，才会减少库存并增加版本号，防止超卖和并发修改问题
    int rowsAffected = jdbcTemplate.update(
        "UPDATE products SET stock = stock - ? , version = version + 1 WHERE id = ? AND version = ? AND stock >= ?",
        quantity, productId, version, quantity);
    if (rowsAffected == 0) {
        // 库存不足或版本号不匹配，说明其他用户已修改库存
        throw new StockNotAvailableException("库存不足或已被其他用户购买");
    }
}

优点：避免了悲观锁的性能瓶颈，适用于高并发环境。
缺点：需要通过版本号来判断是否库存已发生变化，可能存在稍微延迟的情况。

2. 库存预扣机制

在用户提交订单后，系统会暂时预扣一定的库存数量，直到支付成功。预扣的库存将在支付失败或超时后释放。

2.1 支付前预扣库存

当用户提交订单时，系统会先锁定或预扣库存，确保其他用户无法再购买该商品。此时，用户的订单状态为 “等待支付”。

示例：

public void preDeductStock(Long productId, Integer quantity) {
    int updatedRows = productRepository.deductStock(productId, quantity);
    if (updatedRows == 0) {
        throw new InsufficientStockException("库存不足");
    }
}

优点：确保在用户支付期间库存不被其他用户占用。
缺点：如果用户放弃支付或者超时，已预扣的库存需要及时释放。

2.2 支付成功后真正扣减库存

当用户支付成功后，才会真正扣减库存，这时候的库存更具权威性，减少了因支付失败而导致的库存浪费。

3. 排队机制

在高并发情况下，使用排队机制来确保用户按顺序下单，避免多个用户同时请求购买同一件商品导致超卖。

3.1 分布式锁

通过分布式锁来控制在高并发情况下只有一个用户可以下单。比如使用 Redis 或 Zookeeper 来实现分布式锁。

Redis分布式锁示例：使用 Redis 的 SETNX 命令实现分布式锁：

public boolean acquireLock(String key) {
    return redisTemplate.opsForValue().setIfAbsent(key, "locked", 5, TimeUnit.SECONDS);
}

优点：分布式锁可以确保在分布式环境中只有一个用户可以修改库存。
缺点：需要处理锁的释放与超时，避免死锁问题。

3.2 异步排队

可以使用消息队列（如 Kafka、RabbitMQ）来异步处理订单创建请求，确保订单按顺序处理，防止多个请求同时操作库存。

实现方式：当用户下单时，订单请求被放入消息队列中，后台服务按顺序处理这些请求，并在库存更新时确保库存不足的订单被延迟或拒绝。
优点：可以平滑高并发压力，避免瞬时爆发带来的库存超卖问题。
缺点：增加了系统复杂度和延迟。

总结:这些防止超卖的策略都各有各自的优点，大家在选择回答时可以匹配自己项目的业务，系统的复杂性来回答，这样可以体现回答的独特性和项目的兼容性。