不能用 incr+get 分两步做配额检查,因网络延迟和并发会导致竞态;必须用lua脚本原子执行“读-判-写”,覆盖初始化、超限拒绝、正常扣减三分支,并注意keys/argv分工及过期时间外部管理。

为什么不能用 INCR + GET 分两步做配额检查
因为网络延迟和并发请求会让 INCR 和 GET 之间产生竞态:A 用户刚 INCR 到 99,B 用户同时读到旧值 98,俩人都以为还能用,结果一起冲到 101。Lua 脚本在 Redis 单线程中执行,整个“读-判-写”过程天然原子,这是唯一靠谱的解法。
配额扣减脚本必须包含三个核心逻辑分支
一个健壮的 Lua 脚本不能只做“加一再比大小”,得覆盖初始化、超限拒绝、正常扣减三种状态。Redis 不会自动创建 key,首次访问必须设初值;上限值通常存在另一个 key(比如 quota:limit:user123),得用 redis.call("GET", ...) 拿到它再比对。
- 先
GET配额当前值(current),若为nil,用SET初始化为 0 - 再
GET上限值(limit),若为nil或非数字,直接返回错误码(如 -1) - 若
current + 1 > limit,返回 -2(超限);否则用INCR并返回新值
示例脚本片段:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
local current = redis.call("GET", KEYS[1])
if not current then
redis.call("SET", KEYS[1], 0)
current = "0"
end
local limit = redis.call("GET", KEYS[2])
if not limit or not tonumber(limit) then
return -1
end
if tonumber(current) + 1 > tonumber(limit) then
return -2
end
return redis.call("INCR", KEYS[1])
调用时 KEYS 和 ARGV 的分工容易搞反
KEYS 只能是 Redis key 名(如 "quota:used:user123"、"quota:limit:user123"),不能传数值;数值类参数(比如本次要扣几份、是否允许透支)必须走 ARGV。如果把上限值塞进 KEYS,脚本会报错 ERR Error running script (call to f_...): @user_script:...: WRONGTYPE Operation against a key holding the wrong kind of value —— 因为 Redis 尝试对一个“字符串值”当 key 去操作。
- 推荐调用方式:
EVAL "...script..." 2 quota:used:user123 quota:limit:user123 - 如果想支持动态扣减量(不止扣 1),把增量放
ARGV[1],脚本里用tonumber(ARGV[1]) - 注意:Lua 中
redis.call("INCRBY", KEYS[1], ARGV[1])比多次INCR更安全,避免浮点数或负数导致异常
过期时间得在 Lua 外单独 SETEX,不能靠脚本里 SET
Lua 脚本里用 SET 创建的 key 默认永不过期;但配额 key 通常需自动清理(比如用户注销后)。你不能在脚本里写 SETEX 来覆盖,因为 SETEX 是原子命令,会重置 TTL —— 如果用户高频使用,每次扣减都刷新过期时间,就失去了“闲置自动清理”的意义。
- 正确做法:首次初始化时,在脚本外用
SETEX quota:used:user123 86400 0 - 后续所有扣减都复用该 key,TTL 自动递减
- 如果脚本里检测到 key 不存在(
current == nil),说明已过期,应返回特殊码(如 -3),由业务层决定是重建还是拒绝
这个细节不处理,上线后可能发现“明明设了 24 小时过期,配额却永远不归零”。










