⭐ 题目日期：

美团 - 2024/12/23

📝 题解：

分布式锁是在分布式系统中协调多个节点对共享资源访问的重要机制。以下是常见的实现方式及其详细分析：

---

1. 基于数据库的分布式锁

实现方式

• 唯一索引：通过插入唯一键（如资源ID）获取锁，成功插入则获取锁，释放时删除记录。
• 乐观锁：使用版本号或时间戳，更新时检查版本是否一致。
• 悲观锁：使用SELECT ... FOR UPDATE行锁（需事务支持）。

优缺点

• 优点：实现简单，依赖现有数据库。
• 缺点：
  • 性能低，高并发下数据库压力大。
  • 死锁风险（需设置超时自动删除）。
  • 可靠性依赖数据库高可用。

---

2. 基于Redis的分布式锁

实现方式

• SETNX + EXPIRE：

  SET lock_key unique_value NX EX 30  # 原子操作设置键和过期时间

• RedLock算法：
  • 向多个独立Redis实例申请锁，半数以上成功则视为获取锁。
  • 需处理时钟漂移和网络延迟。

优缺点

• 优点：性能高，适合高并发场景。
• 缺点：
  • 网络分区（脑裂）可能导致锁失效。
  • 需处理锁续期（如WatchDog机制）。
  • RedLock实现复杂，存在争议。

---

3. 基于ZooKeeper的分布式锁

实现方式

• 临时顺序节点：
  1. 客户端在锁路径下创建临时顺序节点。
  2. 判断是否为最小节点，若是则获锁；否则监听前一个节点删除事件。
  3. 释放锁时删除节点。

优缺点

• 优点：
  • 强一致性，可靠性高。
  • 自动处理锁释放（会话失效删除节点）。
• 缺点：
  • 性能低于Redis，写操作较多。
  • 需要维护ZooKeeper集群，复杂度高。

---

4. 基于etcd的分布式锁

实现方式

• 事务 + Lease：
  1. 使用事务（TXN）原子比较并设置键值。
  2. 绑定Lease（租约），自动过期释放锁。
  3. 支持续租（KeepAlive）防止处理超时。

优缺点

• 优点：
  • 强一致性，API设计友好。
  • 支持公平锁和可重入锁。
• 缺点：
  • 依赖etcd集群，运维成本较高。
  • 性能略低于Redis。

---

5. 基于Consul的分布式锁

实现方式

• Session机制：
  1. 创建Session并绑定到键。
  2. 获取锁时尝试创建键，成功则持有锁。
  3. Session失效（节点故障）时自动释放锁。

优缺点

• 优点：
  • 与Consul服务发现集成，适合微服务架构。
  • 自动释放锁，避免死锁。
• 缺点：
  • 性能一般，依赖Consul集群。
  • 社区支持不如ZooKeeper/etcd。

---

对比总结

实现方式	一致性	性能	复杂度	适用场景
数据库	低	低	低	低并发、简单场景
Redis	最终一致	高	中	高并发，容忍短暂不一致
ZooKeeper	强一致	中	高	高可靠，强一致性要求
etcd	强一致	中	高	Kubernetes生态，现代化API需求
Consul	强一致	中	中	微服务集成，服务发现协同

---

选择建议

1. 高并发 & 最终一致：Redis（单实例或RedLock）。
2. 强一致 & 高可靠：ZooKeeper或etcd。
3. 简单实现 & 低负载：数据库唯一索引。
4. 微服务集成：Consul。

---

高级特性考量

• 可重入性：允许同一节点多次获取锁（需记录持有者及计数器）。
• 公平性：按请求顺序分配锁（如ZooKeeper顺序节点）。
• 锁续期：防止处理时间过长导致锁过期（如Redis的WatchDog）。
• 容灾：集群故障时的降级策略（如Redis哨兵/集群模式）。

通过综合业务需求（一致性、性能、复杂度）选择合适的分布式锁方案，并结合监控和测试确保可靠性。