redis lua脚本能保证信号量操作原子性，因其在单线程中执行整个脚本，将读值、判断、写回封装为不可分割的操作，避免并发竞态；而客户端分步操作（如get+incrby+set）存在读-判-写窗口期，必然导致超限。
Redis Lua脚本为什么能保证信号量操作的原子性
因为整个 Lua 脚本在 Redis 单线程中执行，从读取当前值、判断是否可扣减、到写回新值，全部在一个 EVAL 请求内完成，不会被其他客户端中断。这比“先 GET 再 INCRBY 再 SET”这种三步客户端逻辑可靠得多——后者在并发下必然出现竞态。
注意：Lua 脚本里不能调用阻塞命令（如 BLPOP），也不能访问外部状态；所有数据必须通过 KEYS 和 ARGV 传入。
实现带阈值校验的原子计数器增减（信号量核心逻辑）
典型场景是限制某资源最多被 N 个客户端同时占用，比如数据库连接池上限为 10，每次 acquire 尝试 +1，但不能超过 10；release 时 -1。关键在于“+1 前检查是否已达上限”和“-1 前检查是否已为 0”都必须原子。
下面是一个安全的 acquire 脚本示例（返回 1 表示成功，0 表示失败）：
local key = KEYS[1]
local max = tonumber(ARGV[1])
local current = tonumber(redis.call('GET', key) or '0')
if current
<p>对应 release 脚本（返回 1 表示成功释放，0 表示无资源可释放）：</p>
<pre class="brush:php;toolbar:false;">local key = KEYS[1]
local current = tonumber(redis.call('GET', key) or '0')
if current > 0 then
redis.call('DECR', key)
return 1
else
return 0
end
调用方式（以 redis-cli 为例）：
redis-cli --eval acquire.lua my_semaphore , 10
redis-cli --eval release.lua my_semaphore
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
注意：--eval 后第一个参数是脚本路径，, 分隔 keys 和 args，key 列表不能为空（哪怕只用一个 key），所以这里写 my_semaphore , 是合法的。
为什么不能直接用 INCR/DECR + 条件判断？
常见错误是客户端先 GET，再在本地 if 判断，然后决定是否发 INCR。这在多实例或高并发下必然失效——两个客户端几乎同时读到 “9”，都判断“可以 +1”，结果变成 11，突破上限。
另一个坑是误用 INCRBY 配合 GETSET 等组合，依然无法规避读-判-写的窗口期。只有 Lua 脚本能真正把“读+判+写”锁死为一个不可分割的操作。
还有一点容易忽略：如果 key 不存在，GET 返回 nil，Lua 中 tonumber(nil) 是 nil，参与比较会出错。所以上面脚本里用了 or '0' 做兜底，确保 current 总是数字。
超时与自动清理怎么加进 Lua 逻辑里？
纯计数器不处理过期，意味着一旦客户端崩溃未 release，信号量就永远卡死。真实场景需要带 TTL 的信号量，但 Redis 不允许在 Lua 中调用 EXPIRE 对非空 key 生效（如果 key 已存在，EXPIRE 仍有效；但如果刚 INCR 出来，key 是新创建的，此时 EXPIRE 才真正设置 TTL）。
稳妥做法是在 acquire 成功后，**单独发一条 EXPIRE 命令**（客户端层面，非 Lua 内），或者用 SETEX 替代 INCR ——但 SETEX 会覆盖值，不适合累加场景。因此更推荐：acquire 脚本只做计数，客户端在收到成功响应后，立刻执行 EXPIRE my_semaphore 300（设 5 分钟过期）。虽然多一次网络往返，但语义清晰、可控性强。
如果你坚持全在 Lua 里做，只能用 SET my_semaphore 1 EX 300 NX 初始化，后续用 INCR + EXPIRE 组合，但要注意 EXPIRE 对已存在的 key 总是成功的，所以可以放心调用。
实际部署时，建议给信号量 key 加命名空间前缀（如 sem:db_pool），避免 key 冲突；并始终用 DEL 清理废弃 key，而不是依赖 TTL——因为 TTL 只是兜底，不是主逻辑。
