setnx+expire不能直接作分布式锁，因二者非原子操作，存在死锁和主从不一致风险；必须用set的nx+ex选项加唯一value，并用lua脚本校验后解锁。
为什么 setnx + expire 不能直接用作分布式锁
因为 SETNX 和 EXPIRE 是两个独立命令，中间存在窗口期：如果执行完 SETNX 返回 1，但还没来得及执行 EXPIRE 就发生进程崩溃或网络中断，这个锁就永远不释放了——变成死锁。
更隐蔽的问题是：Redis 主从异步复制下，主节点写入成功后挂掉，从节点升主，但锁信息可能没同步过去，导致多个客户端同时拿到“同一个锁”。
- 必须用原子操作保证“设值 + 过期”一步完成，例如
SET key value EX seconds NX - value 不能固定（比如都用
"1"），得是唯一标识（如 UUID 或线程 ID + 时间戳），否则解锁时无法判断是不是自己加的锁 - 解锁不能简单用
DEL，否则可能误删别人持有的锁；必须用 Lua 脚本先校验 value 再删除
如何安全地加锁和解锁（Java + Jedis 示例）
核心是两处原子性：加锁靠 SET 命令的 NX EX 选项；解锁靠 Lua 脚本防止误删。Jedis 本身不封装这些逻辑，得自己写。
public class RedisLock {
private static final String LOCK_SUCCESS = "OK";
private static final Long RELEASE_SUCCESS = 1L;
// 加锁，返回 value（即锁标识），失败返回 null
public String tryLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
if (LOCK_SUCCESS.equals(result)) {
return requestId;
}
return null;
}
// 解锁：Lua 脚本确保只有自己的锁才被删
private static final String UNLOCK_SCRIPT = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
public boolean unlock(Jedis jedis, String lockKey, String requestId) {
Object result = jedis.eval(UNLOCK_SCRIPT, Collections.singletonList(lockKey), Collections.singletonList(requestId));
return RELEASE_SUCCESS.equals(result);
}
}
注意点：
立即学习“Java免费学习笔记（深入）”；
eSiteGroup站群管理系统是基于eFramework低代码开发平台构建，是一款高度灵活、可扩展的智能化站群管理解决方案，全面支持SQL Server、SQLite、MySQL、Oracle等主流数据库，适配企业级高并发、轻量级本地化、云端分布式等多种部署场景。通过可视化建模与模块化设计，系统可实现多站点的快速搭建、跨平台协同管理及数据智能分析，满足政府、企业、教育机构等组织对多站点统一管控的
-
requestId必须全局唯一，建议用UUID.randomUUID().toString()，不要用时间戳或纯数字 - 不要在 finally 块里无条件 unlock——如果加锁失败，unlock 会删掉别人正在用的锁
- Jedis 连接要支持事务/eval，且连接池配置需合理，避免锁未释放时连接被回收
Redission 的看门狗（WatchDog）机制是怎么回事
Redission 默认加锁 30 秒，但如果你的业务执行超过 30 秒，又没手动续期，锁会被自动释放。WatchDog 就是解决这个问题的：它会在锁剩余时间过半（默认 15 秒）时，自动用新过期时间（仍是 30 秒）延长锁有效期，只要客户端还活着且没主动 unlock。
这个机制依赖心跳线程，默认每 10 秒检查一次。但它只在使用 RLock.lock() 无参方法时生效；如果传了超时时间（如 lock(10, TimeUnit.SECONDS)），WatchDog 就不启动。
- WatchDog 只对 Redission 自己获取的锁有效，你用原生命令加的锁它管不了
- 如果业务线程卡住（比如 full gc 或阻塞 IO），心跳发不出，锁仍会被释放——这不是 bug，是设计使然
- 关闭 WatchDog：构造
Config时调用setLockWatchdogTimeout(0)，但之后必须自己 handle 续期
Redis 集群下 RedLock 是否真有必要
RedLock（多节点独立加锁）理论上能提升容错，但 Martin Kleppmann 等人指出它在时钟漂移、GC 暂停等现实场景下并不能真正保证安全性。Redis 官方文档也已弱化 RedLock 推荐，转而建议优先用单节点 Redis（配合高可用架构）+ 正确的客户端实现。
实际项目中，95% 以上的分布式锁需求，用单个 Redis 实例 + 原子 set + Lua 解锁 + 合理超时，再配合服务降级（如锁失败走本地缓存或直接拒绝），比硬上 RedLock 更稳定、更易维护。
- RedLock 要求至少 3 个独立 Redis 节点，运维成本翻倍
- 每次加锁要向多数节点发起请求，延迟高、失败路径复杂
- 若用 JedisCluster，它的哈希槽重定向机制和 RedLock 的“逐节点尝试”逻辑容易冲突，出问题难排查
除非你的业务真的要求“Paxos 级别”的强一致性，否则别为“听起来更安全”而引入 RedLock。
