分布式锁 Redis命令 Redis实现分布式锁的具体方法与设置锁的常用命令

Redis分布式锁详解：原理、命令与实战技巧

最新动态：截至2025年7月，Redis官方在7.2版本中进一步优化了分布式锁的原子性操作性能，新增了EXAT和PXAT参数支持更精确的过期时间控制，同时社区推荐使用Redlock算法的改进版本来应对极端网络分区场景。

为什么需要分布式锁？

想象一下这个场景：你的电商系统在秒杀活动中，用户疯狂点击“立即购买”，如果没有锁机制，很可能出现超卖——10台手机卖给100个人，单机环境下用synchronized或ReentrantLock就能解决，但在分布式系统中，服务部署在多台机器上，就得靠分布式锁来协调了。

Redis因为高性能和丰富的原子命令，成了实现分布式锁的热门选择。

Redis实现分布式锁的核心命令

基础命令：SETNX + EXPIRE（已淘汰）

老版本常用组合，但存在原子性问题：

SETNX lock_key 1  # 尝试加锁（1表示锁的value，可自定义）
EXPIRE lock_key 10  # 设置10秒过期

问题：如果SETNX成功但EXPIRE执行前服务崩溃，锁永远不释放！

现代方案：SET命令扩展参数（推荐）

Redis 2.6.12之后，单条命令实现原子操作：

SET lock_key unique_value NX EX 10  

• NX：仅当key不存在时设置（加锁）
• EX 10：10秒后自动过期（防死锁）
• unique_value：客户端唯一标识（通常用UUID或线程ID），用于安全释放锁

完整分布式锁的实现步骤

加锁

# 示例：客户端A加锁（value为"clientA_123"）  
SET order_lock_101 clientA_123 NX PX 30000  

• 如果返回OK，表示加锁成功
• 如果返回nil，说明锁已被其他客户端持有

解锁（Lua脚本保证原子性）

if redis.call("GET", KEYS[1]) == ARGV[1] then  
    return redis.call("DEL", KEYS[1])  
else  
    return 0  
end  

为什么用Lua：避免误删其他客户端的锁（比如客户端A的锁已过期，B拿到锁后A才执行DEL）

锁续期（可选）

如果业务执行时间可能超过锁过期时间，需启动守护线程定期续期：

# 检查锁归属并延长过期时间  
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('PEXPIRE', KEYS[1], ARGV[2]) else return 0 end" 1 order_lock_101 clientA_123 30000  

高级场景与注意事项

Redlock算法（多节点容错）

当Redis为集群模式时，官方推荐Redlock：

1. 向5个独立Redis节点顺序请求加锁
2. 当多数节点（≥3）加锁成功，且总耗时小于锁有效期，才算成功
3. 解锁时向所有节点发送释放请求

常见坑点

• 时钟漂移：不同机器时间不一致可能导致锁过早失效
• 网络延迟：命令执行时间过长可能引发锁冲突
• 业务超时：锁过期时间需大于业务最久执行时间

生产环境最佳实践

1. 设置合理的过期时间：建议根据业务压测结果设定，例如支付业务通常设置30秒
2. value必须唯一：防止误删其他线程的锁
3. 避免大量锁竞争：可用随机退避（如指数退避算法）减少Redis压力
4. 监控锁等待时间：超过阈值时报警，可能需优化业务逻辑

：Redis分布式锁的核心是原子性加锁和安全释放，虽然实现简单，但在高并发、网络不可靠的场景下仍需谨慎，对于金融级场景,建议结合ZooKeeper或etcd等强一致性方案做兜底。