分布式锁实现指南：Redis方案详解，助你高效选择

结论是用Redis的SET命令配合NX和PX参数，再加一个唯一值，是当前最实用和安全的分布式锁实现方法。

为什么需要分布式锁

想象一下一个有多台服务器的电商系统，很多用户同时抢购一件商品。如果不加控制，库存就可能被多卖。分布式锁就像是一把大家都能看见的公共钥匙，谁拿到了钥匙，谁就能去修改库存，这样就保证了库存不会出错。

Redis实现锁的核心方法

核心就是使用Redis的一个命令：`SET key value NX PX timeout`。这个命令能一次完成好几件事：1. `NX`表示只有当这个key不存在时才设置成功，这就保证了只有第一个请求能拿到锁。2. `PX timeout`表示给这个key设置一个过期时间（比如10000毫秒），过期后自动删除，这样即使拿到锁的程序崩溃了锁也会自动释放，不会永远锁死。3. `value`要设置成一个唯一的值，比如UUID，这是为了防止误删别人的锁。比如你的锁超时了，但你的程序还在运行，另一个程序拿到了新锁，如果你直接用DEL命令删锁，删掉的就是别人的锁。所以释放锁时，要先用GET看看锁的值是不是自己的，是自己的才删除，这可以用Lua脚本来保证原子性。

一步步实现Redis锁

首先，获取锁。向Redis发送命令：`SET lock_key my_unique_uuid NX PX 10000`。如果返回OK，说明你成功拿到了锁，可以执行业务代码了。这个锁会在10秒后自动过期。然后，执行业务逻辑，比如扣减库存。最后，释放锁。不要直接用DEL命令。你需要写一个Lua脚本传到Redis执行。脚本逻辑是：先GET lock_key的值，如果取到的值等于我自己的`my_unique_uuid`，那么就执行DEL删除它；如果不等于，说明锁已经不属于我了，就什么也不做。这样整个判断和删除的操作在Redis里是原子执行的，不会被打断。

常见问题和选择要点

第一个要点是过期时间设置多长？太短，业务没执行完锁就没了，会导致多个程序同时进入；太长，程序挂了后其他程序要等很久。通常要根据业务平均执行时间来定，并且最好在程序里启动一个守护线程，在锁快要过期时如果业务还没执行完，就自动延长锁的过期时间。第二个问题是单点故障怎么办？如果只有一个Redis实例，它宕机了锁就全丢了。所以生产环境通常用Redis主从集群或者Redis哨兵模式。但主从切换时，如果锁还没同步到从节点，也可能导致锁失效。对一致性要求极高的场景，可以考虑RedLock算法，它要求同时向多个独立的Redis主节点申请锁，超过半数成功才算拿到锁，但实现复杂且性能有损耗。对于大多数业务，用主从或哨兵模式已经足够了。

总结与建议

对于大部分Java、Go、Python等语言的项目，你不需要自己从头写这些代码，可以直接用成熟的客户端库，比如Java的Redisson，它内置了分布式锁的实现，处理了锁续期、等待重试等复杂逻辑，非常可靠。如果只是简单场景，自己用SET NX PX命令和Lua脚本实现也足够了。记住关键是：锁要带唯一值、设置超时、用原子操作释放。

FAQ

问题1：Redis锁设置了超时时间，但我的业务执行时间不确定，可能超过超时时间，怎么办？
这是一个典型问题。解决方案有两种：一是在代码里估计一个相对安全的较长超时时间，但这可能造成不必要的等待。更好的方法是使用“看门狗”机制。像Redisson库就实现了这个，它在后台启动一个线程，定期检查业务是否还在执行，如果还在执行，就自动延长锁的过期时间，直到业务执行完毕再释放锁。

问题2：在Redis主从架构下，主节点宕机可能导致锁丢失，有更好的方案吗？
是的，主从异步复制可能导致锁丢失。如果你对锁的绝对安全有极高要求，可以考虑使用RedLock算法，它需要部署多个独立的Redis主节点（通常是奇数个，如5个）。客户端依次向这些节点申请锁，只有当拿到超过半数的锁（比如5个里拿到3个）时才算成功。这提高了可靠性，但代价是性能下降和部署复杂度增加。需要根据业务对一致性和性能的权衡来做选择。大多数电商秒杀等场景，使用带故障转移的主从或哨兵模式已经可以接受。

具体的引用来源：本文的实现思路主要参考了Redis官方网站关于分布式锁的权威文档（https://redis.io/docs/manual/patterns/distributed-locks/），并结合了社区实践和主流客户端库（如Redisson）的实现方式。