分布式锁的四种实现方式：从原理到实践

引言：分布式锁的核心价值

在分布式系统中，多个服务实例同时访问共享资源时，传统的进程内锁（如Java的synchronized）已无法满足需求。分布式锁通过跨进程的协调机制，确保在分布式环境下对共享资源的互斥访问，是解决分布式事务、幂等性控制、并发限流等问题的核心组件。

本文将从实现原理、代码示例、场景对比三个维度，深入解析分布式锁的四种经典实现方式。

一、基于数据库的分布式锁：最直观的实现

1.1 唯一索引实现：利用数据库唯一性约束

-- 锁表结构设计
CREATE TABLE distributed_lock (lock_name VARCHAR(64) PRIMARY KEY,      -- 锁资源标识（唯一索引）client_id VARCHAR(128) NOT NULL,       -- 客户端标识expire_time DATETIME NOT NULL,         -- 锁过期时间create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);-- 加锁逻辑（INSERT + 冲突处理）
INSERT INTO distributed_lock(lock_name, client_id, expire_time)
VALUES('order_lock', 'client-123', NOW() + INTERVAL 30 SECOND)
ON DUPLICATE KEY UPDATE client_id = VALUES(client_id),expire_time = VALUES(expire_time);-- 解锁逻辑（需验证客户端标识）
DELETE FROM distributed_lock 
WHERE lock_name = 'order_lock' 
AND client_id = 'client-123';

1.2 行锁实现：利用数据库事务机制

-- 基于行锁的分布式锁（伪代码）
BEGIN;
-- 锁定资源记录（FOR UPDATE获取排他锁）
SELECT * FROM resource_table 
WHERE resource_id = 'order_123' 
FOR UPDATE;-- 执行业务逻辑...COMMIT; -- 提交事务释放锁

1.3 数据库锁的执行时序

下面是基于数据库行锁的分布式锁执行时序：

1.4 核心问题与优化

• 单点故障：数据库实例故障会导致锁服务不可用，需配合主从复制
• 性能瓶颈：高并发场景下数据库连接池易耗尽
• 优化方向：
  • 添加锁超时自动释放机制（定时任务清理过期锁）
  • 采用分库分表降低锁竞争

二、基于Redis的分布式锁：高性能之选

2.1 基础实现：SETNX + 过期时间

// 基于Jedis的分布式锁实现
public class RedisLock {private JedisPool jedisPool;private static final String LOCK_SUCCESS = "OK";private static final String SET_IF_NOT_EXIST = "NX";private static final String SET_WITH_EXPIRE_TIME = "PX";public RedisLock(JedisPool jedisPool) {this.jedisPool = jedisPool;}// 加锁方法（含过期时间）public boolean acquire(String lockKey, String clientId, long expireTime) {try (Jedis jedis = jedisPool.getResource()) {String result = jedis.set(lockKey, clientId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);return LOCK_SUCCESS.equals(result);}}// 解锁方法（需验证客户端标识）public boolean release(String lockKey, String clientId) {try (Jedis jedis = jedisPool.getResource()) {// 使用Lua脚本保证原子性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, 1, lockKey, clientId);return 1L.equals(result);}}
}

2.2 RedLock算法：应对Redis集群故障

// RedLock算法实现（基于Redisson框架）
public class RedissonRedLockDemo {public static void main(String[] args) {// 配置多节点Redis客户端Config config1 = new Config();config1.useSingleServer().setAddress("redis://node1:6379");Config config2 = new Config();config2.useSingleServer().setAddress("redis://node2:6379");Config config3 = new Config();config3.useSingleServer().setAddress("redis://node3:6379");RedissonClient client1 = Redisson.create(config1);RedissonClient client2 = Redisson.create(config2);RedissonClient client3 = Redisson.create(config3);// 创建分布式锁实例RLock lock1 = client1.getLock("resource_lock");RLock lock2 = client2.getLock("resource_lock");RLock lock3 = client3.getLock("resource_lock");// 构建RedLock（需要多数节点响应）RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);try {// 尝试获取锁（等待100ms，持有10s）boolean isLocked = redLock.tryLock(100, 10, TimeUnit.SECONDS);if (isLocked) {// 执行业务逻辑...System.out.println("获取分布式锁成功");}} catch (InterruptedException e) {Thread.currentThread().interrupt();} finally {// 释放锁（自动向所有节点发送释放命令）redLock.unlock();}}
}

2.3 Redis RedLock执行时序

RedLock算法的执行时序如下：

2.4 Redis锁的核心风险与应对

• 时钟漂移问题：节点间时钟不一致可能导致锁提前过期
• 主从切换丢失：异步复制下主节点宕机可能导致锁丢失
• 解决方案：
  • 采用RedLock算法提升可靠性
  • 客户端实现锁续期机制（Watch Dog）
  • 选择Redis 5.0+的RESP3协议提升性能

三、基于ZooKeeper的分布式锁：可靠性优先

3.1 临时顺序节点实现：天生的分布式协调

// 基于Curator框架的ZooKeeper锁实现
public class ZkDistributedLock {private CuratorFramework client;private InterProcessMutex lock;public ZkDistributedLock(String connectString, String lockPath) {// 配置重试策略RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);client = CuratorFrameworkFactory.newClient(connectString, retryPolicy);client.start();this.lock = new InterProcessMutex(client, lockPath);}// 加锁方法（带超时控制）public boolean acquire(long timeout, TimeUnit unit) throws Exception {return lock.acquire(timeout, unit);}// 解锁方法public void release() throws Exception {lock.release();}// 示例用法public static void main(String[] args) {try {ZkDistributedLock lock = new ZkDistributedLock("localhost:2181", "/distributed_lock");if (lock.acquire(5, TimeUnit.SECONDS)) {try {System.out.println("成功获取ZooKeeper锁");// 执行业务逻辑...} finally {lock.release();}}} catch (Exception e) {e.printStackTrace();}}
}

3.2 ZooKeeper锁的核心原理

ZooKeeper通过临时顺序节点实现分布式锁的核心逻辑：

3.3 ZooKeeper锁的执行时序

下面是ZooKeeper分布式锁的获取和释放时序：

3.4 ZooKeeper vs Redis锁的核心差异

特性	ZooKeeper锁	Redis锁
一致性	强一致性（基于ZAB协议）	最终一致性（异步复制）
故障处理	自动选举新Leader维持服务	主从切换可能丢失锁
性能	吞吐量低于Redis	单节点QPS可达10万+
实现复杂度	依赖ZooKeeper集群管理	简单单机/集群部署

四、基于分布式算法的实现：理论基石

4.1 Raft算法实现分布式锁

Raft算法实现分布式锁的核心流程：

4.2 分布式算法锁的适用场景

• 强一致性需求：如金融交易、分布式事务协调
• 高可用性要求：支持多数节点故障后的自动恢复
• 典型实现：
  • etcd（基于Raft算法）
  • Apache ZooKeeper（基于ZAB协议，类Paxos）

五、四种实现方式对比与选型指南

实现方式	核心优势	核心劣势	典型应用场景
数据库	实现简单，依赖现有设施	性能差，单点风险	并发低、测试环境
Redis	高性能，部署简单	弱一致性，锁丢失风险	缓存、限流、非核心业务
ZooKeeper	强一致性，自动故障恢复	性能低于Redis，部署复杂	订单处理、分布式事务
分布式算法	理论完备，容错性强	实现复杂度极高	分布式系统核心组件

六、总结

1. 优先选择Redis+RedLock：
   大多数业务场景下，Redis的高性能和RedLock算法足以满足需求，推荐使用Redisson框架：

   // Redisson分布式锁最佳实践
   RedissonClient redisson = Redisson.create();
   RLock lock = redisson.getLock("resource_lock");// 带超时的锁获取（10秒等待，30秒持有）
   boolean locked = lock.tryLock(10, 30, TimeUnit.SECONDS);
   if (locked) {try {// 业务逻辑...} finally {lock.unlock();}
   }
   

2. 金融级场景选ZooKeeper：
   对一致性要求极高的场景（如支付系统），推荐使用Curator框架：

   // Curator分布式锁最佳实践
   CuratorFramework client = CuratorFrameworkFactory.builder().connectString("zk1:2181,zk2:2181,zk3:2181").retryPolicy(new RetryNTimes(3, 1000)).build();
   client.start();InterProcessMutex lock = new InterProcessMutex(client, "/payment_lock");
   lock.acquire();
   try {// 支付业务逻辑...
   } finally {lock.release();
   }
   

3. 核心原则：

   • 锁超时时间需大于业务执行时间（建议设置为业务预估时间的1.5倍）
   • 实现锁的幂等释放（通过客户端ID验证）
   • 关键业务添加锁重试机制（如3次重试+指数退避）

结语

分布式锁的实现选择本质上是一致性、可用性、性能的权衡。从简单的数据库锁到复杂的Raft算法锁，每种方案都有其适用场景。在实际开发中，建议优先考虑成熟的开源框架（如Redisson、Curator），避免重复造轮子，同时根据业务特性选择合适的技术方案，在保证系统稳定性的前提下追求最佳性能。