秒杀业务的核心特征在于瞬时高并发流量，即在极短的时间内涌入大量请求。如果将这些请求直接打到关系型数据库上执行库存扣减操作，会引发严重的性能瓶颈。关系型数据库在处理并发更新时通常采用行锁机制，当大量事务同时竞争同一行记录的锁时，会导致大量线程阻塞等待，进而引发数据库连接池耗尽、响应超时甚至系统雪崩。
为什么秒杀库存扣减不能直接依赖数据库
在传统的电商架构中，库存扣减往往是直接操作数据库的UPDATE语句。但在秒杀场景下，这种做法的弊端会被无限放大。假设有一款秒杀商品库存为100件，瞬间涌入十万并发请求，数据库需要处理这十万条更新语句。由于行锁的存在，这十万条请求只能串行化执行，前面的请求不释放锁，后面的请求只能排队等待。这种长时间的阻塞会迅速耗尽数据库的连接资源，导致整个系统不可用。
为了解决这一痛点，引入Redis作为前置缓存层进行库存扣减是业界通用做法。Redis基于内存存储，读写速度极快，且采用单线程模型处理命令，天然避免了并发更新带来的线程安全问题。通过将库存预热到Redis中，所有的扣减操作都在Redis内完成，能够瞬间拦截掉绝大部分无效请求，极大减轻后端数据库的压力。只有当Redis扣减成功后，才会异步地去更新数据库，从而实现流量削峰。
基于Lua脚本实现原子性库存扣减
虽然Redis是单线程执行命令，但在高并发场景下，如果客户端先通过GET获取库存值，判断大于零后再执行DECR扣减，这种非原子性操作依然会导致超卖问题。因为在判断和扣减的间隙，其他请求可能已经修改了库存。为了保证操作的原子性，必须使用Lua脚本。Redis会将整个Lua脚本作为一个整体去执行，在执行期间不会被其他命令打断，从而保证了库存查询与扣减的连贯性。
下面是一个典型的库存扣减Lua脚本示例。脚本逻辑为：首先检查库存是否存在，如果不存在则返回特定错误码；如果库存充足则执行扣减并记录扣减日志，最后返回成功标识。同时，为了防止同一用户重复购买，还可以在脚本中加入用户购买校验逻辑。
local stock_key = KEYS[1]
local user_key = KEYS[2]
local stock = tonumber(redis.call('GET', stock_key))
if stock == nil then
return -1 -- 商品未初始化
end
if stock <= 0 then
return 0 -- 库存不足
end
-- 判断用户是否已经购买过，防止重复购买
if redis.call('SISMEMBER', user_key, ARGV[1]) == 1 then
return -2 -- 重复购买
end
-- 扣减库存并记录用户
redis.call('DECR', stock_key)
redis.call('SADD', user_key, ARGV[1])
return 1 -- 扣减成功
使用Lua脚本不仅保证了原子性，还减少了网络交互次数。原本需要多次网络请求的操作现在只需发送一次脚本即可完成。不过这种方案也有局限性，比如在Redis Cluster集群模式下，如果涉及多个槽位的键操作，Lua脚本可能会报错。因此设计时需要确保相关的键落在同一个节点上，通常可以通过Hash Tag机制，将相关的键名加上大括号，例如{goods:100}:stock和{goods:100}:users，强制它们路由到同一个节点。
异步削峰与最终一致性落库设计
在Redis中扣减库存成功后，并不意味着整个秒杀流程结束。真正的库存数据最终需要持久化到数据库中，用于后续的订单生成、发货等流程。如果每次Redis扣减成功后同步去更新数据库，依然无法彻底解决数据库并发写入瓶颈。因此，必须采用异步削峰与最终一致性落库的设计思路。
具体方案是，Redis扣减成功后，立即向消息队列（如RabbitMQ或Kafka）发送一条扣减成功的消息。后端的订单服务监听这些消息，异步地进行订单创建和数据库库存扣减操作。这样，数据库的写入压力被消息队列平滑削峰，数据库可以按照自身能够承受的速率消费消息，不会因为瞬时流量而崩溃。
public boolean deductStock(String userId, String goodsId) {
String luaScript = loadLuaScript();
Long result = redisTemplate.execute(
new DefaultRedisScript<>(luaScript, Long.class),
Arrays.asList("stock:" + goodsId, "users:" + goodsId),
userId
);
if (result != null && result == 1) {
// Redis扣减成功，发送消息到MQ
mqProducer.send(new StockDeductMessage(goodsId, userId));
return true;
}
return false;
}
这种异步落库方案引入了最终一致性问题。如果消息队列出现积压或消费者宕机，会导致Redis与数据库数据短暂不一致。为了兜底，通常需要设计定时校验任务，定期比对Redis中的剩余库存与数据库中的实际库存，发现异常及时报警并人工介入。同时，在订单服务消费消息时，必须做好幂等性处理，防止消息重复消费导致多扣库存。可以通过在数据库中建立唯一索引或利用状态机来保证幂等性。
库存超卖防范与高可用兜底策略
秒杀系统最怕的就是超卖，即卖出的商品数量大于实际库存。除了前面提到的利用Lua脚本保证扣减原子性外，还需要在系统架构层面做多重兜底。首先是限流，在网关层或应用层设置严格的请求限流策略，拦截掉超出系统承载能力的洪水流量，确保只有少部分请求能够到达Redis层。常用的限流算法包括令牌桶和漏桶算法。
其次是熔断降级机制。当Redis集群出现故障或响应缓慢时，秒杀服务应该能够快速失败，而不是让请求一直阻塞。此时可以触发降级逻辑，比如暂停秒杀活动，返回系统繁忙提示，或者将请求快速拒绝，保护后端数据库不被击垮。熔断器可以使用Sentinel或Hystrix等组件实现，当错误率或响应时间超过阈值时自动熔断。
最后是库存预热与回滚机制。在秒杀活动开始前，需要将数据库中的库存准确无误地预热到Redis中。如果秒杀过程中出现异常，比如订单服务创建订单失败，需要将之前在Redis中扣减的库存加回去。这就要求在发送异步消息时携带事务ID，一旦后续流程失败，通过反向操作恢复Redis库存，确保数据的绝对准确。此外，还可以引入对账机制，在活动结束后进行全量数据核对，保证账实相符。