通常情况下，我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁，Redis 用的要更多一点，我这里也先以 Redis 为例介绍分布式锁的实现。

这篇文章默认你已经知道为什么需要分布式锁。如果你还没搞清楚锁粒度、owner token、锁超时和业务临界区，建议先看 分布式锁入门。如果你想把锁过期、旧客户端恢复、Fencing Token 放到更大的协调模型里理解，可以结合 分布式协调详解。

网上有很多分布式锁相关的文章，这里写了一个相对简洁易懂的版本。面向面试和日常工作场景，先把最常见的概念和边界讲清楚。

这篇文章我们先介绍一下分布式锁的基本概念。

为什么需要分布式锁？

在多线程环境中，如果多个线程同时访问并修改同一份共享资源（例如商品库存、外卖订单），且没有互斥、原子更新、乐观锁或唯一约束等保护，就可能出现数据不一致、重复处理、超卖等问题，影响程序的正确性和稳定性。

举个例子，假设现在有 100 个用户参与某个限时秒杀活动，每位用户限购 1 件商品，且商品的数量只有 3 个。如果不对共享资源进行互斥访问，就可能出现以下情况：

ZooKeeper 是经典的分布式协调组件，常用于注册中心、配置管理、分布式锁、Leader 选举和集群元数据管理。学习 ZooKeeper 时，可以先掌握数据模型和 Watcher，再理解 ZAB 协议、Leader 选举和工程实践。

适合谁看

• 想系统学习 ZooKeeper 的后端开发者。
• 准备 ZooKeeper、注册中心、分布式锁、分布式协调相关面试题的同学。
• 用过 ZooKeeper 或 Curator，但对 ZNode、Watcher、ZAB、Leader 选举不够熟的读者。
• 需要对比 ZooKeeper、Eureka、Nacos 等注册中心和协调组件的工程师。