分布式锁要协调的是不同进程对同一资源的访问，而不是只锁住单个应用实例内的线程。竞争者需要使用一致的资源标识，通过共享的协调服务决定谁可进入临界区；获取失败时不得继续执行受保护操作。互斥、释放策略和故障边界需要分别设计，不能因为使用了 Redis 就默认全部具备。

分布式锁的核心是实现多进程之间互斥，而满足这一点的方式有很多，常见的有三种:

注意redis的超时释放

过期时间限制的是 Redis 锁键的存活，并不会中断持锁线程。旧线程停顿期间锁可能到期，另一个线程随后获得同名锁；旧线程恢复后若直接删除该键，就删除了别人的锁。解锁需要核对本次加锁标识，并且将核对与删除合并执行，避免新的竞争窗口。

租期结束后，同名锁可能已经属于新的请求。旧持有者恢复执行时，如果不检查当前锁值便直接删除，就会把新持有者的锁一并释放，使后续请求也进入临界区。超时机制有助于故障后的自动释放，却不会停止仍在执行的旧业务，因此不能把键过期理解为业务已经结束。

解决方法：释放锁的时候判断一下锁标识

锁值应保存本次加锁生成的唯一标识，释放前只接受与该标识一致的所有者。仅记录一个容易被不同进程重复使用的线程编号并不充分；不同持有者必须能够区分。检查归属只能确定应该删除谁的锁，若检查与删除分成两次命令，仍存在中间过期、换主人的竞争窗口。

先 GET 再 DEL 即使检查过所有者，也可能在两条命令之间发生过期和重新加锁。把比较与条件删除放进同一个 Lua 脚本，只有锁值等于预期标识时才删除同一把锁，其他客户端无法在这两个步骤之间插入命令。这个保证限于脚本内的 Redis 操作，不覆盖数据库事务。

==使用Redis事务（Redis只保证了原子性，不能保证一致性，要不然再加上乐观锁进行判断，复杂==

==使用简单的Lua脚本，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性。==

样例：

调用解锁脚本时，要把实际锁键作为键参数传入，再把期望的所有者标识作为普通参数传入。脚本中的 KEYS[1] 与 ARGV[1] 分别读取这两类输入，不应把用户输入直接拼进脚本文本。调用方还要解释返回值，区分本次确实删除了锁与锁已不存在、已不属于自己等未释放情况。

这段 Lua 的核心是先读取目标锁的当前值，再与调用者提供的标识比较，匹配时删除的必须仍是同一个键。这里键参数应统一使用 KEYS[1]，不能换成未定义的 key 变量。返回值也应与删除结果对应，否则调用者无法仅凭固定返回值知道是否真正完成了释放。

1
-- 比较标识的一致性
2
if(redis.call('get', KEYS[1]) == ARGV[1]) then
3
    -- 释放锁
4
    redis.call('del', key)
5
end
6
return 0

完整的锁生命周期需要两处不可分割的操作：获取时用一条带 NX 与过期参数的 SET 同时建立互斥和租期，避免先加锁后设置过期之间中断；释放时用脚本原子比较标识并条件删除。租期仍应覆盖业务风险，自动过期本身不能保证旧执行者已停止访问受保护资源。

基于Redis的分布式锁实现思路:

• 利用set nx ex获取锁，并设置过期时间，保存线程标示
• 释放锁时先判断线程标示是否与自己一致，一致则删除锁

特性:

• 利用set nx满足互斥性
• 利用set ex保证故障时锁依然能释放，避免死锁，提高安全性·利用Redis集群保证高可用和高并发特性