在实际开发中，一个常见的陷阱是直接使用 INCR 配合 EXPIRE 来实现信号量。虽然写法简单，但在生产环境中极易出现问题。核心原因在于原子性缺失——这两条命令并非原子执行，中间可能被其他请求中断，或者网络超时导致仅执行一半。最终可能造成 key 存在但未设置过期时间，或者过期时间已设置但自增失败，从而引发后续请求无限制涌入，导致超卖和并发越界等问题。
为什么不能直接用 INCR + EXPIRE 实现信号量？
因为两条命令非原子执行，一旦中间被中断或超时，key 可能出现有值无过期时间，或过期时间已设置但自增未成功的情况。后续请求检测到空间，就会继续累加，导致超卖。而使用 Lua 脚本，Redis 可以确保“检查 → 加锁 → 设置过期”三步连续完成，中间不会被任何操作打断。
EVAL 脚本里怎么安全地实现 acquire 和 release？
acquire 脚本的逻辑比较直观：首先检查当前计数是否小于最大许可数，如果满足条件则执行 INCR 并设置过期时间；release 操作则先验证 key 是否存在且为数字类型，然后执行 DECR，归零后可选择删除 key。这里有一个容易忽略的细节：不能通过 GET 获取值后再自行判断，而必须使用 redis.call('GET', KEYS[1]) 并配合类型检查，否则空值或字符串值会导致 INCR 报错 ERR value is not an integer or out of range。
一个常见的 acquire 脚本写法参考：
if redis.call('EXISTS', KEYS[1]) == 0 then
redis.call('SET', KEYS[1], 0)
redis.call('EXPIRE', KEYS[1], ARGV[2])
end
local current = tonumber(redis.call('GET', KEYS[1]))
if current and current < tonumber(ARGV[1]) then
redis.call('INCR', KEYS[1])
return 1
else
return 0
end
用 EVALSHA 替代 EVAL 有什么坑？
使用 EVALSHA 代替 EVAL 时，需要先用 SCRIPT LOAD 加载脚本并获取 SHA1 值，否则直接调用 EVALSHA 会返回 NOSCRIPT 错误。更关键的是在集群环境下，所有 KEYS 必须属于同一个 slot，否则 Redis Cluster 会拒绝执行。解决方案是为信号量 key 添加固定 hash tag，例如 semaphore:{order}，确保集群正确路由。
容易忽略的细节还有：
SCRIPT LOAD返回的 SHA 是字符串，调用EVALSHA时需原样传入，注意大小写敏感- 脚本中的所有 key 必须通过
KEYS数组传入，硬编码 key 名会导致集群路由失败 - 释放操作如果使用
DEL直接删除，可能误删其他线程刚 acquire 的计数，正确做法是只执行DECR，不删除 key
客户端如何处理 acquire 失败和连接异常？
Redis 执行 Lua 脚本后返回整数结果：1 表示成功，0 表示拒绝。但网络中断、timeout、LOADING 状态等不会返回 0，而是直接抛异常。在这种情况下不能简单重试，否则可能导致重复 acquire——必须配合唯一 client token（比如 UUID）写入 value，或者用 HASH 结构记录持有者，否则无法判断是否真正获取到了锁。
更实用的做法是：把信号量 key 的 value 设计成 current_count:timestamp:client_id 这类复合结构，方便 debug 和主动清理过期持有者。当然，脚本会因此变复杂，要不要这么做，取决于你是否真的需要强持有追溯能力。
最棘手的问题在于：acquire 成功但客户端在后续业务逻辑中崩溃，又没来得及 release。这时只能靠 EXPIRE 时间兜底，所以 ARGV[2]（TTL）不能设太长，也不能太短——要略大于最长业务耗时，才能确保不留下“僵尸锁”。
