分布式锁详解

最新推荐文章于 2026-05-04 12:15:34 发布

原创最新推荐文章于 2026-05-04 12:15:34 发布 · 828 阅读

7 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

java

分布式锁详解

分布式锁是一种用于在分布式系统中协调多个节点对共享资源访问的机制。它能够确保在多个进程或节点之间实现互斥访问，从而保证数据一致性。以下是对分布式锁的详细讲解。

1. 什么是分布式锁

分布式锁是一种锁机制，用于解决多个进程或节点同时操作共享资源时的冲突问题。

传统锁（如 Java 的 synchronized 或 ReentrantLock）通常用于单机环境，无法在分布式系统中直接使用。
分布式锁能在多台机器或多个进程间实现对资源的互斥访问。

分布式锁的特性

一个健壮的分布式锁应该具备以下特性：

互斥性：任意时刻，只有一个客户端能持有锁。
容错性：锁的实现机制能够容忍部分节点故障。
解锁保障：加锁的客户端可以正常释放锁，即使发生故障，也能通过超时机制避免死锁。
高性能：锁的加解锁操作尽量低延迟、高吞吐。

2. 分布式锁的典型实现方式

2.1 基于数据库实现分布式锁

使用关系型数据库的表记录来实现锁机制。

实现思路

创建一张锁表，包含字段 lock_name 和 lock_owner。
使用 INSERT 或 UPDATE 操作申请锁。
使用 DELETE 操作释放锁。

示例

-- 创建锁表
CREATE TABLE distributed_lock (
    lock_name VARCHAR(255) PRIMARY KEY,
    lock_owner VARCHAR(255),
    lock_time TIMESTAMP
);

-- 尝试获取锁
INSERT INTO distributed_lock (lock_name, lock_owner, lock_time)
VALUES ('resource_name', 'node1', NOW())
ON DUPLICATE KEY UPDATE lock_time = NOW();

-- 释放锁
DELETE FROM distributed_lock WHERE lock_name = 'resource_name' AND lock_owner = 'node1';

优点

简单易实现，适合小型项目。
利用现有的数据库，无需额外组件。

缺点

性能较低，数据库成为瓶颈。
无法天然支持锁超时机制，需要定期清理过期锁。

2.2 基于 Redis 实现分布式锁

Redis 提供了快速、高效的分布式锁支持。

实现思路

使用 Redis 的 SET 命令：
- SET key value NX EX <timeout>：
  - NX 保证操作是原子的（如果 key 不存在，则设置）。
  - EX 设置超时时间，避免死锁。
使用 Lua 脚本原子释放锁。

示例

加锁：

String result = jedis.set("lock_key", "lock_value", "NX", "EX", 30);
if ("OK".equals(result)) {
    // 加锁成功
}

解锁（Lua 脚本保证原子性）：

String luaScript =
    "if redis.call('get', KEYS[1]) == ARGV[1] then " +
    "    return redis.call('del', KEYS[1]) " +
    "else " +
    "    return 0 " +
    "end";
Object result = jedis.eval(luaScript, Collections.singletonList("lock_key"), Collections.singletonList("lock_value"));

优点

性能高，延迟低。
支持天然的过期时间，避免死锁。

缺点

Redis 本身需要高可用配置（如 Redis 集群）。
存在 Redis 主从同步延迟带来的锁丢失问题。

2.3 基于 ZooKeeper 实现分布式锁

ZooKeeper 是分布式协调服务，天然支持分布式锁。

实现思路

在 ZooKeeper 中为资源创建一个临时节点（EPHEMERAL）。
若节点创建成功，则获得锁。
释放锁时删除节点，或客户端断开时自动删除。

示例

加锁：

// 创建临时顺序节点
String path = zooKeeper.create("/lock/resource", new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);

解锁：

zooKeeper.delete(path, -1);

优点

提供强一致性，适用于复杂场景。
自动处理锁的释放（临时节点在客户端断开后自动删除）。

缺点

ZooKeeper 运维复杂，成本较高。
性能不如 Redis。

2.4 基于 Etcd 实现分布式锁

Etcd 是一个高可用的分布式键值存储，支持分布式锁。

实现思路

创建键并设置 TTL（租约）。
使用键值租约实现锁过期。
利用 CAS 操作确保锁的原子性。

3. 分布式锁的常见问题及解决方案

3.1 锁的超时和续期

问题：客户端获取锁后，未在锁超时时间内完成操作，可能导致锁被其他客户端抢占。
解决方案：
- 续期机制：在锁即将超时时延长锁的过期时间（如 Redis 的 WATCH）。
- 锁自动释放：超时未释放的锁自动被清理（ZooKeeper 的临时节点）。

3.2 锁的可重入性

问题：同一个线程或客户端在持有锁的情况下，再次尝试加锁可能失败。
解决方案：
- 基于计数实现可重入锁（如 Redis 中用一个计数器保存重入次数）。

3.3 主从同步延迟

问题：Redis 主从架构中，主节点加锁后未及时同步到从节点，从节点可能允许其他客户端加锁，导致锁丢失。
解决方案：
- 使用 Redis 单节点部署。
- 使用 Redlock 算法（分布式 Redis 实现）。

3.4 锁的故障恢复

问题：持有锁的客户端崩溃或断开连接，锁可能未及时释放。
解决方案：
- 利用 TTL 自动释放锁。
- ZooKeeper 临时节点自动删除。

4. 分布式锁的选型

选择依据

特性	数据库	Redis	ZooKeeper
性能	较低	高	中
实现难度	低	中	高
强一致性	较弱	较弱	强
高可用性	中	高	高
适用场景	简单任务调度或小型系统	高并发任务调度、缓存场景	分布式事务、强一致性场景