分布式锁的各种方案的区别总结

最新推荐文章于 2025-12-03 15:27:06 发布

原创最新推荐文章于 2025-12-03 15:27:06 发布 · 641 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #java #spring cloud

java 同时被 2 个专栏收录

64 篇文章

订阅专栏

分布式锁

1 篇文章

订阅专栏

分布式锁方案深度解析

分布式锁是分布式系统中协调多节点访问共享资源的重要机制。下面我将详细分析各种分布式锁实现方案的区别、优缺点及适用场景。

1. 基于数据库的实现

1.1 唯一索引/主键实现

原理：利用数据库唯一约束，多个客户端同时插入相同键值，只有一个能成功

实现：

INSERT INTO lock_table(lock_name,expire_time) VALUES ('resource_lock', '2023-12-31 23:59:59');

优点：实现简单，依赖现有数据库
缺点：
- 无自动失效机制，需业务代码保证释放
- 数据库单点问题
- 性能较差（尤其高并发时）

1.2 乐观锁实现

原理：使用版本号或条件更新

实现：

UPDATE resources SET version = version + 1 WHERE id = 1 AND version = current_version;

优点：避免阻塞
缺点：需业务处理重试逻辑，冲突多时性能下降

2. 基于Redis的实现

2.1 SETNX + EXPIRE

经典实现：
```
SET lock_key unique_value NX PX 30000
```
优点：性能极高，实现简单
缺点：
- 锁过期时间难确定（业务未完成锁已释放）
- 主从切换可能导致锁失效（Redis异步复制）

2.2 RedLock算法

原理：在多个独立Redis实例上获取锁，多数成功才算获取
流程：
1. 获取当前时间
2. 依次尝试从N个Redis实例获取锁
3. 计算获取锁总耗时，小于锁过期时间且多数成功则获取成功
4. 锁有效时间 = 初始有效时间 - 获取锁耗时
优点：解决单点问题
缺点：
- 实现复杂
- 性能下降
- 仍有争议（时钟漂移问题）

3. 基于ZooKeeper的实现

3.1 临时顺序节点

原理：
1. 创建临时顺序节点
2. 检查自己是否是最小节点，是则获取锁
3. 否则监听前一个节点的删除事件

实现：

// Curator框架示例
InterProcessMutex lock = new InterProcessMutex(client, "/resource_lock");
lock.acquire();
try {
    // 业务代码
} finally {
    lock.release();
}

优点：
- 可靠性高（CP系统）
- 自动释放（会话结束）
- 可实现公平锁
缺点：
- 性能不如Redis
- 需维护ZK集群

3.2 临时节点（非顺序）

更简单实现，但可能有"惊群效应"

4. 基于Etcd的实现

4.1 租约（Lease）实现

原理：
1. 创建租约（TTL）
2. 写入键值对并关联租约
3. 定期续约
优点：
- 高一致性
- 提供watch机制
缺点：学习成本较高

5. 方案对比分析

特性	数据库	Redis单机	RedLock	ZooKeeper	Etcd
性能	低	非常高	高	中等	中等
可靠性	低（单点）	低	中高	高	高
实现复杂度	简单	简单	复杂	中等	中等
自动释放	否	是	是	是	是
公平锁支持	否	否	否	是	是
可重入支持	需自行实现	需自行实现	需自行实现	支持	支持
适用场景	低并发简单系统	高并发AP系统	需要更高可靠性	CP系统要求高可靠	CP系统要求高可靠