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

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

这篇文章从同一个服务部署多个实例的场景出发，介绍本地锁的作用范围、分布式锁解决的问题，以及使用时需要注意的边界。

为什么需要分布式锁？

当多个进程需要互斥地操作同一份外部共享资源时，本地锁无法协调这些进程，分布式锁可以提供跨进程的互斥能力。

这里的“共享资源”可以是数据库中同一件商品的库存记录、Redis 中同一个缓存条目等。不同 JVM 通常不共享 Java 堆内存，但可以通过网络访问同一份外部数据。 需要协调的是这些进程对外部数据的操作。

本地锁为什么管不住多个服务实例？

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

适合谁看

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