不能只用SETNX再单独EXPIRE，因二者非原子操作：若SETNX成功后客户端崩溃，EXPIRE未执行，锁将永久存在导致死锁；Redis 2.6.12+应优先用SET key val NX EX seconds原子命令，旧版本可用Lua脚本保障原子性。
Redis String 本身不直接提供分布式锁，但通过 SETNX + 过期时间 + Lua 脚本可以构造出可用、相对安全的锁；不过原生 SETNX 单独用极易死锁，必须配合 EXPIRE 原子性或改用 SET 的 NX EX 选项。
为什么不能只用 SETNX 设置 key 再单独 EXPIRE
这是最常见误操作：先 SETNX lock:order 1 成功，紧接着执行 EXPIRE lock:order 30，但中间若客户端崩溃或网络中断，key 就没过期时间，变成永久锁。Redis 4.0+ 虽支持 SET key value NX EX 30 一条命令解决，但老版本或需兼容时仍得靠 Lua。
关键点：
-
SETNX和EXPIRE是两个独立命令，非原子执行 - 即使加了重试逻辑，也无法保证“设置成功必有超时”
- 生产环境应优先使用
SET key val NX EX seconds（Redis 2.6.12+ 支持）
用 Lua 脚本保证 set + expire 原子性（兼容旧 Redis）
当必须支持 Redis
典型加锁 Lua 脚本（lock.lua）：
if redis.call("exists", KEYS[1]) == 0 then
redis.call("setex", KEYS[1], ARGV[1], ARGV[2])
return 1
else
return 0
end
调用方式（以 redis-cli 为例）：
redis-cli --eval lock.lua lock:pay:123 , 30 "abc123"
说明：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
KEYS[1]是锁 key，ARGV[1]是过期秒数，ARGV[2]是唯一 client_id（用于解锁校验） - 返回
1表示加锁成功，0表示已存在 - 注意：脚本里用
setex而非set+expire，避免竞态
解锁必须用 Lua 校验 client_id，禁止 DEL 直删
如果解锁只是 DEL lock:xxx，任何客户端都能删掉别人持有的锁，导致业务错乱。正确做法是：只有值匹配当前 client_id 才删除。
解锁 Lua 脚本（unlock.lua）：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
调用方式：
redis-cli --eval unlock.lua lock:pay:123 , "abc123"
要点：
- 用
GET拿值再比对，不能用DEL后再检查——中间可能被其他客户端抢占 - 整个判断 + 删除必须在一个 Lua 脚本里完成，否则仍是竞态
- 返回
1表示解锁成功，0表示锁不属于当前 client
实际使用中几个容易被忽略的细节
分布式锁不是设个 key 就完事，真实场景下这些点常被跳过：
- 锁 key 必须带业务上下文前缀，比如
lock:order:create:1001，避免不同业务互相干扰 - client_id 必须全局唯一且不可预测（推荐用 UUID 或进程 ID + 时间戳 + 随机数），防止被猜测伪造
- 加锁要设合理超时（比如 3–5 倍于正常处理耗时），太短易误释放，太长故障恢复慢
- 网络分区时可能出现“双主”加锁，Redis 单节点锁无法替代 ZooKeeper 或 etcd 的强一致性锁
- 不要依赖
TTL命令查剩余时间做逻辑判断——它本身不精确，且两次调用间状态可能已变
真正难的不是写对那几行 Lua，而是想清楚：谁来续期？锁失效后怎么兜底？重试间隔怎么设？这些没设计好，再“原子”的脚本也救不了业务。
