怎么利用Redis String实现分布式锁_基于SETNX与Lua脚本原子化操作

不能只用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 1else    return 0end

调用方式（以 redis-cli 为例）：

redis-cli --eval lock.lua lock:pay:123 , 30 "abc123"

说明：

• 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 0end

调用方式：

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，而是想清楚：谁来续期？锁失效后怎么兜底？重试间隔怎么设？这些没设计好，再“原子”的脚本也救不了业务。