分布式锁|高并发 Redis锁助力服务器性能提升，redis 锁命令解析

分布式锁 | 高并发 Redis锁助力服务器性能提升，redis 锁命令解析

场景引入：抢购引发的血案

"小王啊，咱们昨晚的秒杀活动出大问题了！" 周一早晨我刚到公司，产品经理老张就火急火燎地冲过来，原来昨晚限量1000份的特价商品，后台显示卖出了1200多份，仓库那边直接炸锅了。

我赶紧查看日志,发现同一个商品ID在极短时间内被多个用户同时"抢到"，这明显是典型的高并发场景下的超卖问题——多个服务器实例同时处理订单，库存检查出现了"先读后写"的竞态条件。

"得用分布式锁了，"我对老张说，"特别是Redis实现的分布式锁，能完美解决这种跨进程的资源竞争问题。"

为什么需要分布式锁？

在单机时代,我们用Java的synchronized或者ReentrantLock就能解决线程安全问题，但在分布式系统中，服务部署在多台机器上，传统的线程锁就力不从心了。

想象一下：三台服务器同时处理订单请求，每台服务器的本地锁只能管自己的线程，完全不知道其他服务器的存在，这时候就需要一个所有服务器都能访问的"公证人"来协调——这就是分布式锁。

Redis凭借其高性能、原子性操作和丰富的数据结构，成为实现分布式锁的首选方案。

Redis分布式锁核心命令解析

基础版：SETNX + EXPIRE

最朴素的实现方式：

# 尝试获取锁（SET if Not eXists）
SETNX lock_key unique_value
# 设置锁过期时间（避免死锁）
EXPIRE lock_key 30

但这种写法有致命缺陷——两条命令不是原子的！如果在SETNX后服务器宕机，EXPIRE没执行，锁就永远不释放了。

进阶版：SET扩展参数

Redis 2.6.12后，SET命令支持扩展参数，可以原子性完成上述操作：

SET lock_key unique_value NX EX 30

参数说明：

• NX：等同于SETNX，键不存在时才设置
• EX：设置过期时间，单位秒（PX则是毫秒）
• unique_value：客户端生成的唯一标识，通常用UUID

释放锁的正确姿势

很多人直接这样解锁：

DEL lock_key

这是非常危险的！假设：

1. 客户端A获取锁,执行时间超过30秒，锁自动释放
2. 客户端B获取了锁
3. 客户端A执行完任务,直接DEL会删除B的锁

正确做法是用Lua脚本保证原子性：

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

生产环境最佳实践

锁的续期问题（看门狗机制）

如果业务执行时间不确定,可以使用"看门狗"定期续期，Redisson库就内置了这个功能，每隔10秒检查是否还持有锁，如果是就延长过期时间。

集群环境下的特殊考量

在Redis集群中,主节点写入后可能还未同步到从节点就宕机，此时从节点晋升为新主，可能导致锁丢失，Redis官方提出了RedLock算法，需要同时向多个独立节点获取锁，但这会显著降低性能。

锁的粒度控制

锁的key要足够具体,比如商品秒杀应该用product_123_lock而不是简单的order_lock，这样可以最大限度提高并发度。

性能对比实测

我们在测试环境做了对比（基于2025年8月最新Redis7.2版本）：

可以看到Redis锁的性能损耗仅在2-3%左右，远优于Zookeeper的实现方案。

常见踩坑记录

1. 锁过期时间设置过短：业务没执行完锁就释放了，导致数据不一致，建议根据业务耗时设置合理TTL，并实现续期机制。

2. 未设置唯一标识：某个客户端释放了其他客户端的锁，务必保证每个客户端使用唯一value。

3. 误解原子性：认为Redis单线程就等于所有操作原子性，实际上多个命令之间仍可能被其他客户端操作插入。

Redis分布式锁就像十字路口的交通信号灯,协调着分布式系统中各个服务的行进节奏，它的优势在于：

• 性能极高：内存操作，单线程无竞争
• 实现简单：几个基础命令就能搭建
• 功能丰富：支持TTL、可重入等特性

但也要记住,没有银弹，对于金融级强一致性要求的场景，可能需要考虑更严格的分布式协调服务，不过对于大多数互联网应用来说，Redis分布式锁已经是最佳选择。

"所以老张，"我合上笔记本，"今晚的秒杀活动，咱们用Redis锁重新部署，保证不会再超卖。" 老张终于露出了放心的笑容。