分布式锁用于解决多实例并发访问共享资源的冲突问题,Java中常用Redis和Zookeeper实现。1. Redis通过SET命令的NX和EX选项实现加锁,value使用唯一标识,结合Lua脚本保证解锁原子性,推荐使用Redisson框架,支持可重入和看门狗机制;需注意超时设置、误删锁及主从切换导致的锁失效问题。2. Zookeeper利用临时有序节点实现,客户端创建节点后判断是否最小序号,若是则获锁,否则监听前一节点,Curator的InterProcessMutex简化了实现,具备强一致性和公平性,适合高可靠场景。3. 对比来看,Redis性能高但存在一致性风险,适合高并发低延迟需求;Zookeeper一致性强但性能较低,适合金融等关键系统;运维上Redis更易部署,Zookeeper需维护集群状态。建议优先选用Redisson或Curator等成熟库,避免自行实现复杂逻辑。

在分布式系统中,多个服务实例可能同时访问共享资源,为避免并发冲突,需要使用分布式锁来保证操作的互斥性。Java 中常用 Redis 或 Zookeeper 来实现分布式锁,下面分别介绍两种方式的核心实现思路和关键点。
基于 Redis 实现分布式锁
Redis 因其高性能和原子操作特性,常被用来实现轻量级分布式锁。核心是利用 SET key value NX EX 命令实现加锁,配合 Lua 脚本保证解锁的原子性。
主要步骤:
- 使用
SET lock_key unique_value NX EX expire_time加锁,NX 表示键不存在时才设置,EX 是秒级过期时间,防止死锁。 - value 使用唯一标识(如 UUID),确保只有加锁的线程才能释放锁。
- 释放锁时通过 Lua 脚本先判断 value 是否匹配,再执行删除,保证原子性。
- 建议使用 Redisson 等成熟框架,它封装了可重入、自动续期(看门狗机制)等功能。
简单代码示例(使用 Jedis):
立即学习“Java免费学习笔记(深入)”;
// 加锁
public boolean tryLock(String key, String requestId, int expireTime) {
String result = jedis.set(key, requestId, "NX", "EX", expireTime);
return "OK".equals(result);
}
// 释放锁(Lua 脚本)
public boolean releaseLock(String key, String requestId) {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
"return redis.call('del', KEYS[1]) " +
"else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(key), Collections.singletonList(requestId));
return "1".equals(result.toString());
}
注意:
- 设置合理的超时时间,避免业务未完成锁已释放。
- 防止误删其他客户端的锁。
- Redis 主从架构下存在锁失效风险(主节点宕机未同步到从节点),可考虑 Redlock 算法,但性能较低。
基于 Zookeeper 实现分布式锁
Zookeeper 利用其 ZNode 节点的有序性和临时性(ephemeral)实现分布式锁,可靠性高,适合对一致性要求严格的场景。
实现原理:
- 每个客户端尝试创建一个临时有序节点(如 /lock_00000001)。
- 获取当前所有子节点,判断自己创建的节点是否是序号最小的。
- 如果是,获得锁;如果不是,监听前一个节点的删除事件。
- 前一个节点释放后,当前节点被唤醒并重新判断是否可以获取锁。
优点:
- 强一致性,ZAB 协议保障数据一致。
- 临时节点在会话断开后自动删除,避免死锁。
- 支持公平锁(按创建顺序获取)。
常用工具:
- 使用 Curator 框架更简单:
InterProcessMutex lock = new InterProcessMutex(client, "/my-lock"); try { if (lock.acquire(30, TimeUnit.SECONDS)) { // 执行业务逻辑 } } finally { lock.release(); }
Redis vs Zookeeper 对比
选择依据:- 性能:Redis 更快,适合高并发、低延迟场景。
- 可靠性:Zookeeper 更强,适合金融、订单等对一致性要求高的系统。
- 复杂度:Redis 实现简单,但需处理网络分区等问题;Zookeeper 天然支持监听和临时节点,逻辑清晰。
- 运维成本:Redis 普及度高,Zookeeper 需维护集群状态。
基本上就这些。根据业务场景选择合适方案,优先推荐使用 Redisson 或 Curator 这类成熟库,避免重复造轮子。











