Redis 分布式锁的深水区：原子性与 Lua 脚本演进
【摘要】 在前文中，我们提到了在处理缓存击穿时需要通过分布式锁来防止多线程并发回源数据库。然而，一个看似简单的加锁、释放锁逻辑，在分布式高并发、网络抖动以及极端故障场景下，隐藏着极大的技术陷阱。本节我们将深入探讨分布式锁的演进历史，重点剖析为什么释放锁必须使用 Lua 脚本，并给出工业级的生产代码实现。1. 分布式锁的四大核心要素在分布式环境中实现锁，必须满足以下严苛条件：互斥性（Mutual Exc...
在前文中，我们提到了在处理缓存击穿时需要通过分布式锁来防止多线程并发回源数据库。然而，一个看似简单的加锁、释放锁逻辑，在分布式高并发、网络抖动以及极端故障场景下，隐藏着极大的技术陷阱。
本节我们将深入探讨分布式锁的演进历史，重点剖析为什么释放锁必须使用 Lua 脚本，并给出工业级的生产代码实现。
1. 分布式锁的四大核心要素
在分布式环境中实现锁，必须满足以下严苛条件：
-
互斥性（Mutual Exclusion）： 在任意时刻，只有一个客户端能够持有锁。
-
防死锁（Deadlock Prevention）： 即使持有锁的客户端在异常崩溃（未主动释放锁）的情况下，锁也必须能够自动过期释放（依靠 Redis 的
EXPIRE机制）。 -
解铃还须系铃人（Lock Ownership）： 客户端 A 不能释放客户端 B 加的锁，即只能由加锁方自己解锁。
-
原子性（Atomicity）： 加锁、设置过期时间、以及最终的校验与删除锁操作，必须具备原子性。
2. 经典翻车现场：非原子性释放锁的隐患
在早期或粗糙的实现中，开发者常写出如下伪代码来释放锁：
Python
# 【错误示范：非原子性释放锁】
lock_key = "lock:product:1001"
client_id = "uuid-client-a"
# 步骤 1：判断当前锁是不是自己加的
val = r.get(lock_key)
if val == client_id:
# ⚠️ 危险分割线：在此处发生网络抖动、GC STW（Stop-The-World）或时间片耗尽！
# 假设此时锁刚好到期自动释放了，而被另一个客户端 C 抢先加了新锁
# 步骤 2：删除锁
r.delete(lock_key) # 结果：把客户端 C 刚加的锁给删了！引发锁混乱
故障机理分析： 步骤 1 的
GET 校验与步骤 2 的 DEL 操作是两条独立的命令。如果在执行完 GET 确认是自己的锁之后、执行 DEL 之前，线程遭遇了长时间卡顿（如 Java 的 Full GC 或 Python 的 GIL 调度延迟），导致锁在 Redis 中因超时自动过期。此时，另一个新的线程抢先获取了该锁。等原线程恢复执行并执行 DEL 时，就会错误地将别人刚加的锁删除，导致并发安全防线彻底崩溃。3. 终极解决方案：Lua 脚本保证原子性
为了彻底解决“判断”与“删除”之间的原子性断层问题，Redis 支持在服务端执行 Lua 脚本。Redis 会在执行 Lua 脚本期间保持单线程特性，不会中途插入处理其他客户端的命令，从而完美保证了整个释放锁流程的原子性。
生产级 Lua 释放锁脚本 (unlock.lua)
Lua
-- KEYS[1]: 锁的 Key
-- ARGV[1]: 客户端唯一标识（UUID / Token）
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
基于 Python (redis-py) 的完整加锁与 Lua 释放封装
Python
import uuid
import time
import redis
r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)
# 预先加载并注册 Lua 脚本，返回脚本对象以提升生产性能
UNLOCK_LUA_SCRIPT = r.register_script("""
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
""")
def execute_with_distributed_lock(key: str, expire_seconds: int = 5, retry_times: int = 3):
lock_key = f"lock:{key}"
# 生成当前客户端的专属签名（防止误删其他线程的锁）
client_token = str(uuid.uuid4())
# 1. 尝试获取锁（利用 SET NX EX 原子指令）
acquired = r.set(lock_key, client_token, nx=True, ex=expire_seconds)
if not acquired:
# 未获取到锁，可根据业务选择直接抛错、降级或自旋重试
return {"code": 503, "msg": "系统繁忙，请稍后再试"}
try:
# 2. 成功获取锁，执行核心业务逻辑（如回源数据库重建缓存）
print(f"[Lock] 客户端 {client_token} 成功获取锁，开始执行核心业务...")
# 模拟业务耗时处理
time.sleep(0.5)
business_data = {"id": key, "status": "synced"}
return {"code": 200, "data": business_data}
finally:
# 3. 无论业务是否抛出异常，必须在 finally 中安全释放锁
# 调用注册好的 Lua 脚本，传入 KEYS 和 ARGV
result = UNLOCK_LUA_SCRIPT(keys=[lock_key], args=[client_token])
if result == 1:
print(f"[Unlock] 客户端 {client_token} 释放锁成功。")
else:
print(f"[Unlock] 客户端 {client_token} 释放锁失败（锁可能已过期被其他线程接管）。")
五、 总结与架构思考
在分布式系统的演进道路上，缓存带来的不仅是吞吐量的飞跃，更是对系统架构鲁棒性的全方位考验：
-
面对缓存穿透，我们用布隆过滤器在网关前筑起第一道铜墙铁壁；
-
面对缓存击穿，我们依托分布式锁与 Lua 脚本确保数据库回源时的并发秩序；
-
面对缓存雪崩，我们通过随机 TTL 离散化与多级缓存架构化解大面积宕机风险。
唯有将这些防御策略组合成纵深防御矩阵，并在代码层面严控原子性与异常边界，才能在海量高并发浪潮中稳如磐石。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）