redis分布式锁因原子性、单点故障和超时问题存在缺陷，如误释放、死锁和数据不一致。SETNX非原子操作易致死锁，需用SET命令的NX/EX选项解决；锁超时导致客户端误删他人锁，须通过唯一标识加lua脚本保证释放原子性；主从切换可能引发锁失效或脑裂，RedLock试图缓解但争议大；建议在高一致性场景选用zookeeper或etcd等专业协调服务。
redis分布式锁，在我看来，它确实是个方便趁手的工具，但要说它完美无缺，那可就言过其实了。它在面对网络分区、节点故障以及客户端执行时间过长等场景时，会暴露出一些固有的缺陷，比如可能导致锁的误释放、死锁，甚至是数据不一致的问题。这就像你拿把瑞士军刀去劈柴，虽然也能用，但总归不是最合适的，而且用不好还容易伤到自己。
Redis分布式锁的缺陷主要体现在几个方面：首先是原子性问题，如果操作不当，很容易出现死锁；其次是单点故障的隐患，即使是主从模式，在故障切换时也可能短暂失效；最后，也是最难缠的，是时间漂移和客户端执行超时的边界问题，这直接关系到锁的有效性和安全性。
为什么基于SETNX实现的Redis锁不总是可靠？
我们最早接触Redis锁，可能很多人都是从
SETNX
开始的。它看起来很简单：
SETNX mylock true
，如果返回1就表示成功获取锁，然后
EXPIRE mylock 10
设置过期时间。但问题就出在这里，这两个操作不是原子的。设想一下，一个客户端A执行了
SETNX
成功拿到了锁，但还没来得及执行
EXPIRE
，它自己就崩溃了或者网络断开了。这时候，这个锁就成了“永生锁”，其他任何客户端都无法获取，直接导致死锁。
为了解决这个问题，Redis 2.6.12版本引入了
SET key value [EX seconds] [PX milliseconds] [NX|XX]
命令，它能将设置值和设置过期时间这两个操作原子化。比如，
SET mylock unique_id NX EX 10
，这样就避免了上述的死锁问题。
NX
表示只有当
key
不存在时才设置，
EX 10
表示10秒后过期。这里的
unique_id
非常关键，它通常是一个UUID或者其他能唯一标识客户端的值，用来防止客户端A释放了客户端B的锁。
然而，即使有了原子化的
SET
命令，也并非万事大吉。考虑一个场景：客户端A获取了锁，设置了10秒过期。但它在执行业务逻辑时，因为某些原因（比如GC停顿、网络延迟、CPU飙高）导致执行时间超过了10秒。锁过期了，客户端B获取了锁。此时，客户端A恢复执行，它并不知道锁已经失效，继续操作，甚至可能在业务逻辑结束后，去执行释放锁的操作。如果释放锁的逻辑只是简单地
DEL mylock
，那么它就误删了客户端B的锁，导致并发问题。这在分布式系统中是个非常隐蔽且危险的陷阱。
Redis分布式锁在节点故障时会遇到哪些挑战？
当Redis作为分布式锁的存储介质时，它的节点故障是不得不考虑的。最直接的，如果你用的是单点Redis，那一旦Redis进程挂了，所有依赖它的锁服务就全瘫痪了。这当然是不可接受的。
通常我们会部署Redis主从架构，甚至哨兵模式来提高可用性。然而，即使是这样，在主从切换（failover）的过程中，仍然存在短暂的窗口期，可能导致锁的失效或者重复获取。假设客户端A在旧的主节点上获取了锁，但这个主节点突然宕机了。哨兵系统会将一个从节点提升为新的主节点。如果旧主节点上的数据还没来得及同步到新的主节点，或者因为网络延迟导致同步不完整，那么新的主节点上可能就没有这个锁的信息，客户端B就有可能再次获取到这个“本应被A持有”的锁。这就造成了两个客户端同时持有同一个锁的局面，这在分布式系统中是灾难性的。
更糟糕的是，如果旧的主节点在宕机后又恢复了（比如仅仅是网络短暂中断，或者重启），它可能会“认为”自己仍然是主节点，并且还持有之前的锁信息。这就可能导致“脑裂”问题，即系统中存在两个主节点，各自认为自己是权威，从而导致数据不一致。
为了应对这些问题，Redis的创造者Salvatore Sanfilippo提出了RedLock算法。RedLock尝试通过在多个独立的Redis主节点上获取锁，并要求大多数节点都成功获取才能算作成功，以此来提高锁的可靠性。但RedLock本身也因为其复杂性和在特定网络分区场景下的可靠性问题，受到了业界的广泛争议，比如著名分布式系统专家Martin Kleppmann就对其提出过严厉的批评。我个人认为，RedLock虽然出发点是好的，但它引入的复杂性，以及在极端情况下的行为，使得它在实际生产环境中的应用需要非常谨慎，甚至不如直接使用ZooKeeper或Etcd这类专门的分布式协调服务来得稳妥。
如何避免Redis分布式锁的误释放和死锁问题？
要避免Redis分布式锁的误释放和死锁，我们必须从几个关键点入手，而且这需要一些设计上的考量，并非简单的代码修改。
防止误释放： 核心在于“谁加的锁谁来解”。正如前面提到的，在获取锁时，我们必须将一个唯一的标识符（比如UUID）作为锁的值。在释放锁时，不能简单地
DEL key
，而是要先判断这个锁的值是否是自己设置的。这个“判断并删除”的操作必须是原子的，否则仍然可能出现竞态条件。Redis提供了Lua脚本来保证原子性。
一个典型的释放锁的Lua脚本会是这样：
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
这段脚本的意思是：如果
KEYS[1]
（也就是锁的key）对应的值等于
ARGV[1]
（也就是客户端传入的唯一标识符），那么就执行删除操作并返回1，否则返回0。这样就确保了只有持有正确标识符的客户端才能删除锁。
避免死锁（除了原子化
SET
命令）：
- 合理设置过期时间： 这是最基本的，也是最重要的。过期时间应该根据业务逻辑的执行时间来预估，但要留有余量。如果业务逻辑执行时间不确定，可以考虑“看门狗”机制，即一个后台线程定期检查锁是否快过期，如果业务还在执行，就自动续期。但这个机制本身也增加了复杂性，需要仔细设计。
- 客户端异常处理： 客户端在获取锁后，如果因为崩溃、网络中断等原因未能正常释放锁，过期时间机制会最终解决死锁。但更重要的是，应用程序本身需要有健壮的异常处理逻辑，比如在
块中尝试释放锁，尽管这不能保证100%成功，但能覆盖大部分正常退出场景。
- 幂等性设计： 如果业务操作本身是幂等的，即使因为锁的失效导致重复执行，也不会产生副作用，这从根本上降低了对锁的强依赖。
- 超时机制： 在获取锁时，可以设置一个获取锁的超时时间。如果在这个时间内没有获取到锁，就放弃尝试，而不是无限等待，避免资源耗尽。
总的来说，Redis分布式锁是个权衡的产物。它简单、高性能，对于一些对一致性要求不是那么极致的场景（比如限流、防止表单重复提交）是足够用的。但对于强一致性、高可靠性的场景（比如分布式事务、秒杀库存扣减），我个人会倾向于使用ZooKeeper、Etcd这类为分布式协调而生的工具，或者结合数据库的唯一索引、乐观锁等机制，它们在面对复杂网络环境和节点故障时，有着更成熟、更健壮的保证。使用Redis锁，一定要清楚它的边界和缺陷，并做好相应的弥补措施。
评论（已关闭）
评论已关闭