一、分布式锁的核心概念

分布式锁是一种在分布式系统环境下，用于保证多个进程/节点对共享资源实现互斥访问的机制。其本质是通过某种中间件（如Redis、ZooKeeper等）实现跨节点的锁控制，确保在分布式环境中，同一时刻只有一个客户端能获取锁并执行关键操作，避免出现并发冲突。

二、分布式锁应用场景

场景1：分布式定时任务重复执行

• 业务背景：多个服务器节点部署相同的定时任务（如每日生成报表），需避免重复执行。
• 无分布式锁的问题：
  1. 节点A和节点B在同一时间触发任务；
  2. 两个节点同时生成报表，导致数据重复写入或资源浪费。
• 分布式锁的作用：
  任务执行前先获取锁，只有获取锁的节点能执行任务，其他节点等待或跳过，避免重复操作。

场景2：微服务接口幂等性保障

• 业务背景：支付接口可能因网络重试导致多次调用，需保证同一笔支付只扣款一次。
• 无分布式锁的问题：
  1. 用户点击支付后，因网络延迟导致客户端重试；
  2. 多个支付请求同时到达服务器，可能多次扣除余额。
• 分布式锁的作用：
  以订单ID为键获取分布式锁，确保同一订单的支付请求仅能被处理一次，实现幂等性。

三、分布式锁核心特性与需求

分布式锁需满足以下关键特性：

1. 互斥性：同一时刻仅一个节点持有锁；
2. 安全性：锁只能由持有者释放，避免误释放（如用唯一标识校验）；
3. 容错性：节点崩溃时锁需自动失效（如超时机制）；
4. 可用性：中间件集群故障时，锁服务仍能正常工作（如ZooKeeper的选举机制）。

四、分布式锁常见的实现方式

（一）基于关系型数据库（如MySQL）的实现

1. 实现原理

• 唯一索引方案：通过插入唯一索引记录标识锁状态，插入成功即获取锁
• 排他锁方案：使用SELECT ... FOR UPDATE语句加行锁

2. 核心问题

问题类型	具体表现
性能瓶颈	数据库IO操作耗时高，并发场景下频繁加锁导致吞吐量骤降（TPS通常<1000）
锁失效缺失	无自动过期机制，客户端崩溃会导致锁永久占用，需额外实现定时任务清理死锁
可靠性不足	主从切换时可能出现锁丢失（如MySQL半同步复制延迟）
集群复杂	需处理数据库连接池管理、事务一致性等问题，实现复杂度高

3. 适用场景

• 小规模系统（QPS<100）
• 对性能要求极低的测试环境
• 无高可用需求的简单场景

（二）基于Redis的分布式锁

1. 实现演进

• 基础方案：使用SET NX key value加锁，DEL key释放锁（存在误删风险）
• 安全方案：SET key value NX PX 30000（加锁时设置唯一标识+过期时间）
• Redlock算法（多实例方案）：
  1. 依次向N个Redis实例申请锁
  2. 超过半数实例成功则认为获取锁
  3. 释放锁时向所有实例发送释放请求

2. 核心优缺点

• 优势：
  • 高性能：单实例TPS可达10万+，适合高并发场景
  • 轻量级：纯内存操作，实现简单
  • 灵活扩展：支持主从/集群模式
• 风险点：
  • 主从切换时可能丢锁（异步复制导致）
  • 需严格控制过期时间（过短易误释放，过长导致死锁）

3. Redlock算法实战参数

参数	推荐值	说明
实例数N	5	保证半数以上节点可用（3节点需2成功，5节点需3成功）
锁过期时间	5-10s	需大于网络RTT+业务处理时间，建议为业务耗时的1.5倍
重试间隔	50-100ms	失败后随机延迟重试，避免惊群效应

（三）基于ZooKeeper的分布式锁

1. 实现原理

• 利用ZooKeeper的临时顺序节点特性：
  1. 客户端在/locks路径下创建临时顺序节点
  2. 检查是否为最小序号节点，是则获取锁
  3. 非最小节点监听前一节点删除事件
  4. 释放锁时删除临时节点，触发后续节点获取锁

2. 核心优势

• 自动失效机制：客户端崩溃时临时节点自动删除，避免死锁
• 强一致性：基于ZAB协议保证分布式事务一致性
• 高可靠性：节点故障时通过选举机制快速恢复
• 可重入性：可通过节点路径记录客户端标识实现重入逻辑

3. 性能表现

• 单次锁操作耗时约10-50ms（含网络往返）
• 集群模式下吞吐量可达5000-10000TPS
• 适合对可靠性要求高于性能的场景