Redis Lua脚本是唯一能真正保障秒杀库存扣减+限流原子性的方案，因其在服务端串行执行，确保“检查库存”与“扣减库存”等操作不可分割；若拆分为多次命令则必然导致超卖或漏限。
Redis Lua脚本是唯一能真正保障秒杀库存扣减+限流原子性的方案，单纯用 SETNX 或 INCR 配合业务层判断必然出现超卖或漏限。
为什么必须用 Lua 脚本而不是多个 Redis 命令
秒杀场景下，“检查库存是否充足”和“扣减库存”必须在一个不可分割的步骤里完成。如果拆成两次网络请求（先 GET 再 DECR），高并发时多个请求可能同时读到库存=1，然后都执行 DECR，最终库存变成 -1。
Redis 单个 Lua 脚本在服务端串行执行，天然具备原子性。整个逻辑从读、判、改到返回结果，都在一个 EVAL 原子上下文中完成。
常见错误现象：redis.clients.jedis.exceptions.JedisDataException: ERR Error running script (call to f_...): @user_script:... —— 多数是因为脚本里用了不支持的命令（比如 TIME）或参数传错类型。
- Lua 脚本中不能使用
KEYS命令（集群模式不支持），必须用ARGV传参 - 所有 key 必须显式通过
keys参数传入，不能硬编码 - 脚本返回值只能是 number / string / boolean / table（对应 Java 的 Long / String / Boolean / List）
一个可直接复用的秒杀+限流 Lua 脚本
这个脚本同时完成：① 库存校验与扣减；② 用户级单日限购（如每人最多抢 1 件）；③ 全局请求频控（如每秒最多 1000 次请求）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
local stockKey = KEYS[1]
local userLimitKey = KEYS[2]
local rateLimitKey = KEYS[3]
local stock = tonumber(ARGV[1])
local userLimit = tonumber(ARGV[2])
local rateLimit = tonumber(ARGV[3])
local windowSec = tonumber(ARGV[4])
local userId = ARGV[5]
<p>-- 1. 检查并扣减库存
local currStock = redis.call('GET', stockKey)
if not currStock or tonumber(currStock) < 1 then
return {0, 'sold_out'}
end
local res = redis.call('DECR', stockKey)
if res < 0 then
redis.call('INCR', stockKey) -- 回滚
return {0, 'over_sold'}
end</p><p>-- 2. 检查用户当日限购
local userKey = userLimitKey .. ':' .. userId
local userCount = tonumber(redis.call('GET', userKey) or '0')
if userCount >= userLimit then
redis.call('INCR', stockKey) -- 补回库存
return {0, 'user_limit_exceeded'}
end
redis.call('INCR', userKey)
redis.call('EXPIRE', userKey, windowSec)</p><p>-- 3. 全局速率限制（滑动窗口简易版）
local rateKey = rateLimitKey .. ':window'
local now = tonumber(ARGV[6]) or tonumber(redis.call('TIME')[1])
local windowStart = now - windowSec
local entries = redis.call('ZRANGEBYSCORE', rateKey, 0, windowStart)
if #entries > 0 then
redis.call('ZREM', rateKey, unpack(entries))
end
local currentCount = tonumber(redis.call('ZCARD', rateKey))
if currentCount >= rateLimit then
redis.call('INCR', stockKey)
redis.call('DECR', userKey)
return {0, 'rate_limited'}
end
redis.call('ZADD', rateKey, now, userId .. ':' .. now)
redis.call('EXPIRE', rateKey, windowSec + 1)</p><p>return {1, 'success'}调用时注意传参顺序和类型一致，Java 中用 Jedis.eval() 或 RedisTemplate.execute() 执行，KEYS 是 3 个 key，ARGV 是 6 个参数（库存阈值、用户限购数、全局 QPS、时间窗口秒数、用户 ID、当前时间戳）。
Spring Boot 中集成的关键细节
别直接拼接字符串加载 Lua 脚本——每次 EVAL 都会重新解析，浪费 CPU；要用 EVALSHA + SCRIPT LOAD 缓存。
- 用
DefaultRedisScript封装脚本，设置resultType为java.util.List.class - 确保所有 key 落在同一个 Redis 分片上（集群模式下，用
{xxx}包裹 key 前缀强制路由） - 对返回结果做严格判空和类型检查：
if (result == null || ((List<?>) result).isEmpty()) - 不要在 Lua 脚本里 sleep 或做复杂计算，否则阻塞 Redis 主线程
- 本地开发用 Redis Desktop Manager 测试脚本时，注意它默认不传
KEYS和ARGV，要手动模拟
压测时最容易被忽略的三个点
很多人脚本写对了，但一压测就超卖或限流失效，问题往往不在 Lua 本身。
- 客户端时间不同步导致
TIME返回值偏差，建议统一用服务端redis.call('TIME')获取时间戳，而非传入系统时间 - 没给 key 设置过期时间（
EXPIRE），用户限流 key 永久存在，第二天还生效 - 误把
userLimitKey和rateLimitKey设为同一个值，导致用户维度和全局维度互相干扰
真实生产环境里，Lua 脚本的边界 case 比想象中多：库存归零后又被其他流程误加、用户 ID 为空字符串、时间窗口跨天未清理……这些都得在脚本里防御性处理，而不是靠外围兜底。
