面试专栏：分布式锁

分布式锁场景

如果想真正了解分布式锁，需要结合一定场景; 举个例子，某夕夕上抢购 AirPods Pro 的 100 元优惠券。

如果使用下面这段代码当作抢购优惠券的后台程序，我们一起看一下，可能存在什么样的问题。

很明显的就是这段流程在并发场景下并不安全，会导致优惠券发放超过预期，类似电商抢购超卖问题。

想一哈有什么方式可以避免这种分布式下超量问题?

互斥加锁，Java 中互斥锁的语义就是 同一时间，只允许一个客户端对资源进行操作。

比如 Java 中的关键字 Synchronized，以及 JUC Lock 包下的 ReentrantLock 都可以实现互斥锁。

1. JVM 本地锁

如图所示，加入 JVM synchronized 锁确实可以解决单机下并发问题。

但是生产环境为了保证服务高可用，起码要 部署两台服务，这样的话 synchronized 就不起作用了，因为它的 作用域只是单个 JVM。

分布式情况下只能通过 分布式锁 来解决多个服务资源共享的问题了。

2. 分布式锁

分布式锁的定义：保证同一时间只能有一个客户端对共享资源进行操作。

比对刚才举的例子，不论部署多少台优惠券服务，只会有 一台服务能够对优惠券数量进行增删操作。

另外有几点要求也是必须要满足的:

1. 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
2. 具有容错性。只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁。
3. 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

分布式锁实现大致分为三种，Redis、Zookeeper、数据库，文章以 Redis 展开分布式锁的讨论。

分布式锁演进史

先来构思下分布式锁实现思路。

首先我们必须保证同一时间只有一个客户端(部署的优惠券服务)操作数量加减。其次本次 客户端操作完成后，需要让 其它客户端继续执行：

1. 客户端一存放一个标志位，如果添加成功，操作减优惠券数量操作。
2. 客户端二添加标志位失