秒杀系统如何保证库存不超卖

在秒杀系统中，库存超卖是一个关键问题，需要通过多种技术手段来保证高并发情况下库存的正确性。以下是几种常见的解决库存超卖的技术方案及其具体实现方法。

1. 数据库乐观锁

使用乐观锁可以防止多用户同时更新库存时导致超卖。乐观锁通常通过"版本号"机制来实现。

实现步骤：

在库存表中增加一个 version 字段。
每次更新库存时，检查 version 是否与上次读取的一致，如果一致，则更新库存和 version；如果不一致，则说明库存已经被其他用户修改过，需要重新尝试。

SQL 例子：

sql 复制代码

-- 用户A在购买前读取库存和版本号
SELECT stock, version FROM products WHERE product_id = 1;

-- 用户A提交订单时，执行如下更新操作
UPDATE products
SET stock = stock - 1, version = version + 1
WHERE product_id = 1 AND version = 旧的version号;

如果 version 不匹配，则更新失败，用户需要重新尝试获取最新库存。

优点：

无需锁表，对数据库性能影响较小，适合中小规模并发。

缺点：

并发过高时可能导致更新失败频繁，用户体验下降。
适用于低中等并发场景，如果并发量极大，数据库压力仍然较大。

2. 分布式锁（基于 Redis）

分布式锁可以确保在多台服务器上并发处理库存时不会导致超卖，常用 Redis 来实现分布式锁。

实现步骤：

当用户请求秒杀时，先尝试通过 Redis 获得锁。
如果获得锁，则执行扣减库存操作，并释放锁。
如果未获得锁，则等待或重试。

Redis 实现分布式锁的示例：

python 复制代码

import redis
import time

r = redis.StrictRedis()

# 尝试获取锁，设置锁的有效期避免死锁
lock_key = "lock:product_1"
if r.set(lock_key, "locked", ex=5, nx=True):  # ex 表示锁定时间，nx 表示键必须不存在
    try:
        # 执行扣库存操作
        stock = r.get("product_stock_1")
        if stock and int(stock) > 0:
            r.decr("product_stock_1")
            print("库存扣减成功")
        else:
            print("库存不足")
    finally:
        # 释放锁
        r.delete(lock_key)
else:
    print("获取锁失败，稍后重试")

优点：

Redis 作为分布式缓存具有高性能，适合大规模并发场景。
锁机制能够确保多台服务器在并发情况下安全修改库存。

缺点：

如果 Redis 出现故障，可能会影响锁的管理和库存的正确性。
锁的粒度要控制好，锁的过大可能影响性能。

3. 库存预减 + 异步队列

在用户请求秒杀时，使用缓存进行库存预减（即在用户下单前就先减少库存），然后通过异步队列（如 Kafka 或 RabbitMQ）将订单请求发往后端进行异步处理。

实现步骤：

商品秒杀开始前，将商品库存预先加载到 Redis。
当用户请求秒杀时，先从 Redis 中预减库存。
将请求通过消息队列发送到后端进行订单处理和库存的最终确认。
如果订单处理失败（如支付失败等），则通过异步任务将 Redis 中的库存回补。

Redis 预减库存示例：

python 复制代码

# 假设秒杀商品的库存预存在 Redis 中
product_stock_key = "product_stock_1"

# 秒杀请求时，先从 Redis 中预减库存
stock = r.get(product_stock_key)
if stock and int(stock) > 0:
    r.decr(product_stock_key)
    # 将订单请求放入消息队列，进行后续处理
    print("库存预减成功，订单处理中")
else:
    print("库存不足，秒杀失败")

优点：

使用缓存大幅减少数据库压力，适合大规模并发场景。
削峰填谷，利用消息队列将订单处理异步化，缓解高并发对数据库的冲击。

缺点：

需要处理订单失败后的库存回补，增加了系统复杂性。
在极端情况下可能出现 Redis 库存与数据库库存不一致的问题，需要通过补偿机制来解决。

4. 数据库悲观锁

悲观锁通过直接锁定数据库中的某行数据，确保在高并发情况下只有一个用户可以修改库存。

实现步骤：

在用户请求秒杀时，锁定库存行，直到操作完成后才释放锁。

SQL 例子：

sql 复制代码

-- 通过 FOR UPDATE 语句对库存行进行加锁，防止其他事务修改
SELECT stock FROM products WHERE product_id = 1 FOR UPDATE;

-- 更新库存
UPDATE products SET stock = stock - 1 WHERE product_id = 1;

优点：

保证强一致性，在高并发下不会出现超卖问题。

缺点：

锁的开销较大，特别是在高并发情况下，容易导致数据库性能瓶颈。
使用过多的悲观锁可能会导致锁等待和死锁问题。

5. 秒杀令牌机制

提前生成秒杀令牌（Token）分发给用户，只有拿到令牌的用户才能参与秒杀，确保每个用户的请求是有限的，从而避免库存超卖。

实现步骤：

商品秒杀开始前，生成固定数量的秒杀令牌并缓存到 Redis。
用户请求秒杀时，必须先获取秒杀令牌。
获取令牌成功后，才能继续下单流程，否则秒杀失败。

示例：

python 复制代码

# 秒杀令牌提前生成
token_key = "seckill_token_1"
r.set(token_key, 100)  # 假设商品库存是 100

# 用户请求时，先获取令牌
if r.decr(token_key) >= 0:
    print("成功获取令牌，继续下单流程")
else:
    print("令牌获取失败，秒杀结束")

优点：

通过控制令牌数量来直接控制参与秒杀的用户数量，防止超卖。
极大减少数据库和缓存的压力。

缺点：

增加了系统的复杂性，需要额外管理秒杀令牌的生成和发放。

总结：

为了防止库存超卖，可以综合使用多种技术方案，常见的实现方式包括：

使用乐观锁 或悲观锁来确保数据库层面的并发安全。
使用Redis 缓存预减库存 结合异步队列来提高高并发下的性能。
分布式锁（如 Redis 锁）确保多节点环境下的库存操作一致性。
秒杀令牌机制可以有效控制用户数量，防止超卖和系统崩溃。

根据具体的业务场景和需求，可以选择合适的方案或将几种方案结合使用。