分布式锁有几种实现方式？

面试记录 2026-10-08

题目：分布式锁有几种实现方式？

难度：medium

标签：arch/distributed/lock, distributed/lock, difficulty/medium

评分：⭐⭐⭐☆☆（3/5）

我的回答

分布式锁常见的几种方式的话，包括 Redis 实现的、ZooKeeper 实现的，还可以用本地消息。还可以用数据库去实现。核心就是确保这个事务整个状态的记录。这个线程过来，其他线程等待，拿到了的就拿，没拿到的就等待。锁的意义无非就是控制外部线程的进入。分布式锁也是这个概念。控制多线程的进入，同时只有一个线程。然后做个标识，一个线程在执行，其他线程不可进，就完事。分布式锁就是找不同的介质去干这个事。要么用 Redis，要么用 Zookeeper，数据库也可以。反正有个外部介质去在多个服务之间去同时的能感知到这个东，这个线程这个锁被持有着，然后管控其他线程不被调用，就可以了。

点评

优点：抓住分布式锁本质（互斥）；列举主流实现（Redis/ZK/DB）；"找不同介质做同一件事"抽象到位。

不足："本地消息"不是分布式锁实现方式（应为本地锁或混淆了 MQ 概念）；遗漏 etcd/Consul/RedLock；未做选型对比（AP vs CP、性能、死锁友好度）；未提具体机制（SETNX/watches/事务）。

补充：主流选型——Redis（AP，高性能，watchdog 防死锁）/ZK（CP，强一致，临时节点自动释放）/etcd（CP，Raft，K8s 生态）/DB（事务，低频场景）；核心区别是一致性模型和死锁处理机制。

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对分布式锁介质的全面掌握 + 各方案的一致性/性能/死锁权衡 + 落地能力。

知识点拆解：

1. 四大类介质：

• Redis：SET key value NX PX 30000，靠过期时间 + watchdog 续期防死锁；主从切换可能丢锁（AP 弱一致）；生产用 Redisson 封装
• ZooKeeper：创建临时顺序节点（/lock/0001, /lock/0002），拿到最小节点者持锁，watch 前一个节点等释放；临时节点进程崩溃自动删除天然防死锁；CP 强一致
• etcd：基于 Raft，通过租约 (Lease) + Watch 实现，K8s 用它做 Leader Election
• 数据库：INSERT + 唯一约束（乐观方式）或 SELECT ... FOR UPDATE（悲观行锁）；性能差但零依赖

1. 核心权衡三角：一致性 / 性能 / 死锁友好度

• Redis：性能最高、一致性最弱、需要 watchdog 兜底
• ZK：一致性最强、性能中等、天然防死锁
• DB：性能最低、一致性最强、事务保证

1. 争议点——RedLock：Antirez 提出的"多 Redis 节点同时加锁，多数派成功才算"方案，Marko Elezi 论证过其安全性问题，主流社区已不推荐（Redisson 也弃用了 RedLock）

按「介质分类 → 权衡矩阵 → 争议方案」递进。

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否说清 Redis 主从切换丢锁的具体场景、ZK 临时节点的实现细节
• 广度：对比 Redis/ZK/etcd/DB/RedLock 的差异，理解一致性模型（CP vs AP）对锁的影响
• 应用：业务场景选型——高并发秒杀用 Redis、Leader 选举用 ZK/etcd、低频用 DB

延伸递进面试题：

1. Redis 分布式锁在主从切换时会发生什么？如何解决？

• 解答要点：主库加锁后崩溃、从库升主但没同步到锁 key，第二个客户端能拿到锁，出现双持锁；RedLock 方案存在争议（客户端时钟偏移）；生产实践是接受 AP 弱一致性、业务侧做幂等兜底

1. ZooKeeper 实现分布式锁的完整流程是什么？为什么不用持久节点？

• 解答要点：临时顺序节点 + watch 前一个节点；持久节点进程崩溃不会释放导致死锁；顺序节点解决惊群问题

1. 分布式锁加了锁，业务执行超时怎么办？看门狗机制怎么工作？

• 解答要点：Redisson watchdog 每 (TTL/3) 检查持锁线程是否存活，存活就续期；业务线程崩溃 watchdog 停止续期，锁自然过期；防止"业务卡住但锁持有"的死锁

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，分布式锁常见实现主要有四大类介质：

1. Redis 实现：SET key value NX PX 30000 原子加锁，value 存请求者标识防误删，PX 设过期时间防死锁。生产用 Redisson 客户端，带 watchdog 机制——加锁线程每 TTL/3 检查自己是否存活，存活就续期，业务卡住或崩溃时锁自然过期。性能高（毫秒级），但主从切换可能丢锁（AP 弱一致），所以业务侧要做幂等兜底。

2. ZooKeeper 实现：每个客户端创建临时顺序节点（/lock/0000000001, /lock/0000000002），序号最小的持锁，其他 watch 前一个节点。进程崩溃临时节点自动删除，天然防死锁。CP 强一致，但性能中等，适合 Leader 选举等对一致性要求高的场景。

3. etcd 实现：基于 Raft，用租约 (Lease) + Watch 做锁。K8s 用它做 Leader Election 就是典型场景，云原生生态友好。

4. 数据库实现：INSERT 到锁表 + 唯一约束（乐观），或 SELECT ... FOR UPDATE 行级锁（悲观）。零外部依赖但性能最差，适合低频场景。

选型建议：高并发业务锁（秒杀、库存扣减）用 Redis + Redisson；Leader 选举、强一致场景用 ZK 或 etcd；低频、已有 DB 直接用 DB。RedLock（Antirez 的多节点方案）因为安全性有争议，主流社区已经不推荐用了。

选型的本质是权衡：一致性 vs 性能 vs 死锁友好度，没有银弹。