分布式锁的实现原理与常见方案

问题描述
在分布式系统中，多个节点可能同时竞争同一个共享资源（如数据库某行数据的修改权、一个任务的执行权等）。为了避免数据不一致或资源冲突，需要一种机制保证在同一时间只有一个节点能访问该资源，这种机制就是分布式锁。

1. 分布式锁的核心要求
在深入实现方案前，需先明确一个合格的分布式锁应满足的条件：

• 互斥性：任意时刻只有一个客户端能持有锁。
• 避免死锁：即使获取锁的客户端崩溃或网络分区，锁最终也能被释放。
• 容错性：只要分布式系统的大部分节点存活，锁服务就能正常运作。
• 高性能：加锁和解锁的延迟不能成为系统瓶颈。

2. 基于数据库的实现（悲观锁）
方案举例：利用数据库的唯一索引或排他锁。

• 步骤：
  1. 创建一张锁表，包含资源名（唯一索引）、持有者标识、过期时间等字段。
  2. 加锁时插入一条记录（如 INSERT INTO lock_table(resource, owner, expire_time) VALUES(...)），利用唯一索引保证互斥性。
  3. 插入成功则获锁；失败则重试或放弃。
  4. 解锁时删除对应记录。

缺点：

• 数据库单点可能成为性能瓶颈。
• 若客户端崩溃后未删除记录，需依赖过期时间机制避免死锁，但过期时间难以精确设定。

3. 基于Redis的实现（内存型）
方案举例：使用Redis的 SET key value NX PX timeout 命令。

• NX：仅当key不存在时才设置，保证互斥性。
• PX：设置key的过期时间（毫秒），避免死锁。
• 示例：

  SET lock:resource1 client_id NX PX 30000  # 30秒后自动过期  
  

• 解锁时需验证持有者：

  -- 使用Lua脚本保证原子性  
  if redis.call("GET", KEYS[1]) == ARGV[1] then  
      return redis.call("DEL", KEYS[1])  
  else  
      return 0  
  end  
  

潜在问题：

• 时钟漂移可能导致锁过早释放。
• 主从切换时可能丢失锁（Redis异步复制）。

4. 基于ZooKeeper的实现（强一致性）
方案核心：利用ZooKeeper的临时有序节点和Watch机制。

• 步骤：
  1. 在ZooKeeper的锁目录下创建临时有序节点（如 /lock/resource1_00000001）。
  2. 检查自己是否为序号最小的节点：若是，则获锁。
  3. 若不是，则监听前一个节点的删除事件（避免羊群效应）。
  4. 解锁时直接删除节点，ZooKeeper会自动通知后续节点。

优势：

• 通过会话机制自动清理崩溃客户端的节点，避免死锁。
• 强一致性保证锁的可靠性。

缺点：

• 频繁的节点创建和监听可能带来性能开销。

5. 对比与选型建议

• 数据库锁：适用于并发量低、已有数据库依赖的场景，但性能差。
• Redis锁：性能高，但在极端场景下可能互斥性被破坏（需权衡一致性与性能）。
• ZooKeeper锁：强一致性要求高的场景（如金融交易），但复杂度较高。

进阶思考：

• 如何实现可重入锁？
• 红锁（RedLock）算法能否真正解决Redis锁的可靠性问题？