分布式锁一般都怎样实现？

分布式锁的实现方式

【核心定义】

分布式锁是一种在分布式系统中协调多个节点对共享资源进行互斥访问的同步机制，其本质是通过一个所有节点都能访问的共享存储系统来实现锁状态的集中管理。

【关键要点】

1. 基于数据库实现

   • 利用数据库的唯一约束或乐观锁机制，通过插入或更新特定记录来获取锁
   • 简单易实现，但性能较差，不适合高并发场景

2. 基于Redis实现

   • 使用SETNX（SET if Not eXists）命令或Redlock算法
   • 性能优异，支持高并发，但需要处理锁过期和续约问题

3. 基于ZooKeeper实现

   • 利用临时顺序节点和Watch机制实现公平锁
   • 可靠性高，具备自动释放特性，但性能相对Redis较低

4. 基于etcd实现

   • 使用租约（Lease）机制和Revision版本控制
   • 强一致性保证，适合对一致性要求极高的场景

【深度推导/细节】

Redis分布式锁的核心矛盾与解决方案

Step 1: 基础实现

SET lock_key unique_value NX PX 30000

• NX: 仅当key不存在时设置成功
• PX 30000: 设置30秒过期时间，防止死锁
• unique_value: 客户端唯一标识，确保只能释放自己的锁

Step 2: 锁续约问题

• 问题：业务执行时间可能超过锁过期时间
• 解决方案：启动守护线程定期续约（watchdog机制）
• 临界点：通常设置过期时间为业务预估时间的2-3倍

Step 3: Redlock算法（多节点容错）

1. 获取当前时间T1
2. 依次向N个Redis实例请求加锁（使用相同的key和value）
3. 计算获取锁花费的时间 = 当前时间T2 - T1
4. 成功条件：
   • 从大多数（N/2+1）节点获取锁成功
   • 总耗时小于锁有效时间

【关联/对比】

版本差异关注点：

• Redis 2.6.12+：支持SET NX EX原子命令，避免竞态条件
• Redis 2.8+：支持Lua脚本，确保解锁操作的原子性
• ZooKeeper 3.5+：支持容器节点，优化临时节点清理

『面试官追问』

1. Redis分布式锁在集群模式下有什么问题？如何解决？

   • 问题：主从异步复制导致锁丢失（主节点宕机，锁未同步到从节点）
   • 解决方案：使用Redlock算法或Redis红锁（多个独立Redis实例）

2. 如何实现可重入的分布式锁？

   • Redis方案：使用Hash结构存储锁计数和线程标识
   • ZooKeeper方案：在同一临时节点下记录重入次数

3. 锁过期时间和业务执行时间如何平衡？

   • 设置合理的超时时间（业务平均时间的2-3倍）
   • 实现锁续约机制（watchdog）
   • 监控告警：锁持有时间异常时及时报警

4. 分布式锁的公平性问题如何解决？

   • ZooKeeper：天然支持公平锁（顺序节点+FIFO）
   • Redis：可通过队列或时间戳实现近似公平

5. CAP理论在分布式锁选择中的应用？

   • CP系统（ZooKeeper、etcd）：优先保证一致性，适合金融、交易
   • AP系统（Redis）：优先保证可用性，适合电商、社交

直击痛点：

• Redlock的5个节点设计：基于故障容忍度计算（N=2F+1），允许最多2个节点故障
• 锁过期时间30秒：平衡GC暂停时间（通常10-30秒）和业务执行时间
• 时钟漂移处理：在Redlock中引入时钟偏差容错，通常设置几毫秒的余量

最佳实践建议

1. 选择合适的实现：根据业务对一致性、性能、可靠性的要求权衡选择
2. 设置合理的超时：避免设置过短导致误释放，过长导致资源长时间不可用
3. 实现锁监控：监控锁等待时间、持有时间、获取失败率等关键指标
4. 降级方案：分布式锁失败时应有本地锁或排队机制作为降级
5. 测试验证：模拟网络分区、节点宕机等异常场景，验证锁的可靠性