笙亿网络策划

分布式锁原理一图秒懂，附常见实现方案与避坑指南，如何确保分布式锁的可靠性与性能？

约 6 分钟读完 34 阅
文章导读
分布式锁的核心原理是通过共享存储介质（如 Redis、ZooKeeper、数据库）实现跨节点互斥。确保可靠性与性能需遵循三大原则：原子性加锁（如 Redis SET NX PX）、防死锁机制（设置过期时间或看门狗自动续期）、唯一性解锁（验证客户端 ID）。常见方案中，Redis 适合高并发场景，ZooKeeper 适合强一致性场景，数据库适合低并发定时任务。避坑指南包括避免锁误删、处理时钟回拨及选
📋 目录
  1. A 【分布式】分布式核心组件——分布式锁:Redis/ZooKeeper/etcd 实现方案 (附全方位对比表)、优缺点、Redlock、时钟回拨问题
  2. B 分布式锁的各种实现，看完这篇你就懂了!
  3. C 分布式锁原理与实现 (数据库、redis、zookeeper)
  4. D FAQ
A A

分布式锁的核心原理是通过共享存储介质（如 Redis、ZooKeeper、数据库）实现跨节点互斥。确保可靠性与性能需遵循三大原则：原子性加锁（如 Redis SET NX PX）、防死锁机制（设置过期时间或看门狗自动续期）、唯一性解锁（验证客户端 ID）。常见方案中，Redis 适合高并发场景，ZooKeeper 适合强一致性场景，数据库适合低并发定时任务。避坑指南包括避免锁误删、处理时钟回拨及选择合适的一致性模型。

【分布式】分布式核心组件——分布式锁:Redis/ZooKeeper/etcd 实现方案 (附全方位对比表)、优缺点、Redlock、时钟回拨问题

一、分布式锁基础认知 (核心地基) 1.1 核心定义与解决的问题 分布式锁是分布式系统中控制多节点/多进程并发访问共享资源的同步原语，核心解决分布式环境下，跨 JVM/跨主机的进程无法使用本地锁 (如 Synchronized、ReentrantLock) 保证操作原子性、数据一致性的问题，是分布式系统并发控制的核心组件。必备核心特性 (缺一不可) 强互斥性：同一时刻，只有一个客户端能持有锁 (最核心要求) 防死锁能力：即使持有锁的客户端崩溃、网络断开，锁最终可被安全释放，不阻塞后续业务 身份唯一性：只能由加锁的客户端释放锁，禁止其他客户端误释放 容错性：多数节点正常运行时，就能持续提供锁服务，无单点故障风险 可选增强特性 可重入性：同一客户端持有锁期间，可重复加锁不阻塞 公平性：按请求先后顺序分配锁，先到先得 自动续约：业务执行超时前，自动延长锁的有效期，避免锁提前释放 非阻塞能力：支持 tryLock，获取失败立即返回，不无限阻塞 可中断性：持有锁过程中可响应中断，主动释放锁 分布式锁的设计本质是在性能、一致性、可用性三者之间做权衡，对应 CAP 定理：AP 型锁：优先保证可用性和分区容错性，牺牲强一致性 (如 Redis 分布式锁) CP 型锁：优先保证一致性和分区容错性，牺牲部分可用性 (如 ZooKeeper/etcd 分布式锁) Redis 分布式锁是业界高并发场景的首选方案，核心基于 Redis 单线程模型的命令原子性实现。

分布式锁的各种实现，看完这篇你就懂了!

什么是分布式锁 分布式锁是控制分布式系统之间同步访问共享资源的一种方式，通过互斥来保持一致性。了解分布式锁之前先了解下线程锁和进程锁：线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一 JVM 中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如 Synchronized、Lock 等 进程锁：控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过 synchronized 等线程锁实现进程锁 比如 Golang 语言中的 sync 包就提供了基本的同步基元，如互斥锁 但是以上两种适合在单体架构应用，但是分布式系统中多个服务节点，多个进程分散部署在不同节点机器中，此时对于资源的竞争，上诉两种对节点本地资源的锁就无效了。这个时候就需要分布式锁来对分布式系统多进程访问资源进行控制，因此分布式锁是为了解决分布式互斥问题！分布式锁的特性 互斥 互斥性很好理解，这也是最基本功能，就是在任意时刻，只能有一个客户端才能获取锁，不能同时有两个客户端获取到锁。避免死锁 为什么会出现死锁，因为获取锁的客户端因为某些原因 (如 down 机等) 而未能释放锁，其它客户端再也无法获取到该锁，从而导致整个流程无法继续进行。面对这种情况，当然有解决办法啦！引入过期时间：通常情况下我们会设置一个 TTL(Time To Live，存活时间) 来避免死锁，但是这并不能完全避免。

分布式锁原理与实现 (数据库、redis、zookeeper)

二、Redis 实现分布式锁 Redis 实现分布式锁的思路主要是，获取锁的时候在 redis 中存储一个特定的 key-value，释放锁的时候删除这个 key-value。具体实现有多种方式。1、【setnx】命令实现分布式锁 (set if not exist) 一般思路是先用 setnx 命令设置一个指定的 key-value 来获取锁 (同一业务逻辑获取的分布式锁对应的 key 固定，value 随意),释放的时候用 del 命令删除这个 key-value。这样做可能出现一个问题，如果释放锁 (del key) 之前系统挂了，redis 中的这个 key-value 会一直存在，也就是会造成死锁。因此可以用 expire 命令来给这个 key-value 加一个有效期，过一段时间即使不删除也自动失效。但由于加锁的时候，setnx 和 expire 是分成两步来执行的，并没有原子性，如果执行 expire 之前系统挂了，也无法释放锁，造成死锁。当然执行 expire 需要依赖 setnx 的执行结果，如果 setnx 执行不成功 (没抢到锁),是不应该执行 expire 的，所以也无法用 redis 事务的方式来保证这两个命令的原子性 (如果用事务，及时 setnx 执行失败，也会继续执行 expire)。最终方案：可以通过 setnx+getset 命令来完美实现 redis 分布式锁，这种方案可以避免死锁，主要思想就是如果持有锁的线程没有及时释放锁，其他线程可以帮它释放锁。

分布式锁原理一图秒懂，附常见实现方案与避坑指南，如何确保分布式锁的可靠性与性能？

FAQ

分布式锁必须满足哪些核心特性？

必须满足互斥性、防死锁能力、身份唯一性和容错性，可选特性包括可重入性和公平性。

Redis 实现分布式锁如何避免死锁？

分布式锁原理一图秒懂，附常见实现方案与避坑指南，如何确保分布式锁的可靠性与性能？

可以通过设置 key 的过期时间（TTL），或者使用看门狗机制自动续期，确保锁最终能被释放。

为什么 setnx 和 expire 分开执行会有问题？

因为这两步不具备原子性，如果 setnx 成功后系统宕机未执行 expire，会导致锁永久存在造成死锁。