redis如何实现分布式锁：原生命令+安全机制实现高可用锁控制

Redis实现分布式锁的核心是通过SETNXEX原子命令抢占锁资源，搭配锁超时自动释放、防死锁、防误释放、锁续期、主从一致性机制，解决多服务多节点并发争抢资源的问题。该方案上手简单、性能极高，适配绝大多数中小型分布式并发场景，缺点是无法百分百保证强一致性，极端主从切换场景下会出现锁失效问题，适合最终一致业务，不适合金融交易等强一致性核心场景。你只需掌握加锁、解锁、续期三个核心操作，就能落地可用的Redis分布式锁。

分布式锁核心加锁逻辑

你实现Redis分布式锁加锁，必须使用单条原子命令，杜绝多命令执行导致的并发漏洞。标准加锁指令为SETlock_keyunique_valueNXEXexpire_time，其中lock_key是锁定的业务资源标识，unique_value是当前客户端生成的唯一随机字符串，NX代表仅key不存在时才设置成功，EX指定锁的自动过期时间。这条命令能一次性完成锁判断、锁抢占、超时设置，从根源避免并发加锁冲突。如果命令执行返回OK，代表你成功获取分布式锁，可执行业务逻辑；返回nil则说明资源已被其他节点锁定，需要重试或放弃执行。

非原子的分步操作是典型错误实现，若你先判断key不存在、再设置key，两步操作中间会出现时间窗口，多个客户端可同时通过判断并设置锁，直接导致锁失效，引发并发脏数据问题。

安全解锁的执行规则

解锁绝对不能直接删除锁key，会造成严重的锁误释放问题。当业务执行速度慢于锁超时时间，锁会被Redis自动释放，其他客户端会抢占新锁，此时旧客户端执行del命令，会删掉别人持有的有效锁。正确的解锁方式是通过Lua脚本原子校验唯一值再删除，先判断锁key对应的value是否等于当前客户端的unique_value，匹配一致则删除key释放锁，不匹配则直接返回，不执行任何操作。

这套Lua脚本保证了校验和删除两个操作原子执行，不会出现中间并发空隙，彻底杜绝跨客户端误解锁的问题，是生产环境必须落地的解锁规范。

长业务场景的锁续期方案

设置固定过期时间无法适配长耗时业务，业务未执行完毕、锁提前过期释放，会造成锁失效、业务并发错乱。你需要开启锁续期机制，也就是业内常说的看门狗机制。获取锁成功后，启动一个后台定时线程，定时检测当前客户端持有的锁是否存在，若锁有效且业务未结束，就主动延长锁的过期时间，默认续期间隔为过期时间的三分之一。

锁续期必须绑定持有锁的客户端，线程仅校验当前节点的唯一锁标识，避免续期其他客户端的锁。业务逻辑执行完成后，必须手动关闭续期线程，再执行解锁脚本，防止后台线程持续续期导致锁无法释放，造成资源永久占用。

集群模式下的一致性风险与优化

单机Redis分布式锁仅存在超时失效风险，Redis主从集群架构下会出现致命一致性问题。主节点加锁成功后，数据尚未同步到从节点，此时主节点宕机，从节点升级为主节点，新主节点无锁数据，其他客户端可重新加锁，出现同一资源两把锁的并发事故。

解决该问题的标准方案是Redlock算法，通过向集群中半数以上节点执行加锁命令，全部成功才算获取锁，大幅降低锁失效概率。但Redlock算法实现复杂、性能损耗高，多数业务无需强制使用，普通业务可通过适当延长锁超时时间、降低主从切换概率规避风险。

分布式锁落地适配标准

生产落地时必须严格遵守两个硬性限制，一是锁过期时间必须大于单次业务最大执行耗时，预留足够冗余时间；二是所有客户端必须统一加锁、解锁、续期规则，杜绝部分节点使用非标准操作破坏锁机制。