Redis如何利用Lua实现秒杀资格与库存的双重校验

必须用Lua脚本而非客户端分步判断，因GET+DECR在并发下必然超卖；Lua在Redis端原子执行“读-判-改”，避免中间插队导致库存为负或资格校验失效。为什么必须用 Lua 而不是客户端分步判断因为秒杀场景下，GET 库存再 DECR 的两步操作在并发时必然出现超卖——中间可能有其他请求插队。Lua 脚本在 Redis 服务端原子执行，整个“读-判-改”过程不会被中断。常见错误现象：(integer) -1 出现在库存字段里，或日志里反复看到“资格已用完”但用户实际没抢到——本质是业务层校验和 Redis 操作没对齐。不要在客户端做 if inventory > 0 then DECR：网络延迟 + 多实例部署会让这个判断彻底失效脚本里别用 redis.call("GET", ...) 再手动转数字：直接用 tonumber(ARGV[1]) 更安全，避免字符串比较陷阱如果用 EVALSHA 预加载脚本，记得先 SCRIPT LOAD，否则返回 NULL 导致逻辑跳过一个能同时校验用户资格和库存的 Lua 脚本怎么写核心思路：把用户资格（比如是否在白名单、是否已抢过）和库存扣减放在同一个脚本里，用 redis.call 统一查、统一改，返回值明确区分成功/失败原因。示例脚本（精简版）：if redis.call("SISMEMBER", "whitelist", KEYS[1]) == 0 then return {0, "not_in_whitelist"}endif redis.call("SISMEMBER", "seckilled", KEYS[1]) == 1 then return {0, "already_seckilled"}endlocal stock = tonumber(redis.call("GET", KEYS[2]))if stock <= 0 then return {0, "out_of_stock"}endredis.call("DECR", KEYS[2])redis.call("SADD", "seckilled", KEYS[1])return {1, stock - 1}说明：KEYS[1] 是用户 ID，KEYS[2] 是商品库存 key；返回数组第一个元素是结果码，第二个是附带信息。用 SISMEMBER 查白名单比 EXISTS + 字符串匹配更高效，也避免误匹配资格和库存检查顺序不能颠倒：先确认人有资格，再动库存，否则可能卡住有效用户别在脚本里用 redis.log：生产环境默认关闭日志，且影响性能Java 客户端调用时容易漏掉的关键点Spring Data Redis 的 execute() 方法传参稍不注意就会错位，导致脚本收到空 KEYS 或乱序 ARGV。 标贝科技 标贝科技-专业AI语音服务的人工智能开放平台