背景
对于锁大家肯定不会陌生，在Java中synchronized关键字和ReentrantLock可重入锁在我们的代码中是经常见的，一般我们用其在多线程环境中控制对资源的并发访问，但是随着分布式的快速发展，本地的加锁往往不能满足我们的需要，在我们的分布式环境中上面加锁的方法就会失去作用。于是人们为了在分布式环境中也能实现本地锁的效果，也是纷纷各出其招，今天让我们来聊一聊一般分布式锁实现的套路。
什么是锁？
在单进程的系统中，当存在多个线程可以同时改变某个变量（可变共享变量）时，就需要对变量或代码块做同步，使其在修改这种变量时能够线性执行消除并发修改变量。
锁本质上是一种同步机制（synchronization）。即为了实现多个线程在一个时刻同一个代码块只能有一个线程可执行，那么需要在某个地方做个标记，这个标记必须每个线程都能看到，当标记不存在时可以设置该标记，其余后续线程发现已经有标记了则等待拥有标记的线程结束同步代码块取消标记后再去尝试设置标记。这个标记可以理解为锁。
不同地方实现锁的方式也不一样，只要能满足所有线程都能看得到标记即可。如 Java 中 synchronize 是在对象头设置标记，Lock 接口的实现类基本上都只是某一个 volitile 修饰的 int 型变量其保证每个线程都能拥有对该 int 的可见性和原子修改，linux 内核中也是利用互斥量或信号量等内存数据做标记。
除了利用内存数据做锁其实任何互斥的都能做锁（只考虑互斥情况），如流水表中流水号与时间结合做幂等校验可以看作是一个不会释放的锁，或者使用某个文件是否存在作为锁等。只需要满足在对标记进行修改能保证原子性和内存可见性即可。
分布式场景
在许多的场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。很多时候我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，通过 Java 提供的并发 API 我们可以解决，但是在分布式环境下，就没有那么简单啦。
- 分布式与单机情况下最大的不同在于其不是多线程而是多进程。
- 多线程由于可以共享堆内存，因此可以简单的采取内存作为标记存储位置。而进程之间甚至可能都不在同一台物理机上，因此需要将标记存储在一个所有进程都能看到的地方。
分布式锁（Distributed Lock）
当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数。
与单机模式下的锁不仅需要保证进程可见，还需要考虑进程与锁之间的网络问题（在分布式情况下，之所以问题变得复杂，主要就是需要考虑到网络的延时和不可靠）。
分布式锁还是可以将标记存在内存，只是该内存不是某个进程分配的内存而是公共内存如 Redis、Memcache。至于利用数据库、文件等做锁与单机的实现是一样的，只要保证标记能互斥就行。
特点
当我们确定了在不同节点上需要分布式锁，那么我们需要了解分布式锁到底应该有哪些特点:
- 互斥性（mutually exclusive）：和我们本地锁一样互斥性是最基本，但是分布式锁需要保证在不同节点的不同线程的互斥。
- 可重入性：同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。
- 锁超时：和本地锁一样支持锁超时，防止死锁。
- 高效，高可用：加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。
- 支持阻塞和非阻塞：和ReentrantLock一样支持lock和trylock以及tryLock(long timeOut)。
- 支持公平锁和非公平锁（可选）：公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的。这个一般来说实现的比较少。
常见的分布式锁
我们了解了一些特点之后，我们一般实现分布式锁有以下几个方式:
- MySQL
- Apache ZooKeeper
- Etcd
- Consul
- Redis
- 自研分布式锁，如谷歌的Chubby。
下面分开介绍一下这些分布式锁的实现原理。
MySQL分布式锁
首先来说一下Mysql分布式锁的实现原理，相对来说这个比较容易理解，毕竟数据库和我们开发人员在平时的开发中息息相关。对于分布式锁我们可以创建一个锁表:
前面我们所说的 lock()、trylock(long timeout) 和 trylock() 这几个方法可以用下面的伪代码实现。
lock()
lock一般是阻塞式的获取锁，意思就是不获取到锁誓不罢休，那么我们可以写一个死循环来执行其操作:
mysqlLock.lock()方法内部会执行一个SQL，为了达到可重入锁的效果那么我们应该先进行查询，如果有值，那么需要比较node_info是否一致，这里的node_info可以用机器IP和线程名字来表示，如果一致那么就加可重入锁count的值，如果不一致那么就返回false。如果没有值那么直接插入一条数据。伪代码如下:
需要注意的是这一段代码需要加事务，必须要保证这一系列操作的原子性。
tryLock()和tryLock(long timeout)
tryLock()是非阻塞获取锁，如果获取不到那么就会马上返回，代码可以如下:
tryLock(long timeout) 实现如下:
mysqlLock.lock和上面一样，但是要注意的是select … for update这个是阻塞的获取行锁，如果同一个资源并发量较大还是有可能会退化成阻塞的获取锁。
unlock()
unlock的话如果这里的count为1那么可以删除，如果大于1那么需要减去1。
锁超时
我们有可能会遇到我们的机器节点挂了，那么这个锁就不会得到释放，我们可以启动一个定时任务，通过计算一般我们处理任务的一般的时间，比如是5ms，那么我们可以稍微扩大一点，当这个锁超过20ms没有被释放我们就可以认定是节点挂了然后将其直接释放。
总结
- 适用场景：MySQL分布式锁一般适用于资源不存在数据库，如果数据库存在比如订单，那么可以直接对这条数据加行锁，不需要我们上面多的繁琐的步骤，比如一个订单，那么我们可以用
select * from order_table where id = 'xxx' for update进行加行锁，那么其他的事务就不能对其进行修改。 - 优点：理解起来简单，不需要维护额外的第三方中间件，比如Redis，ZooKeeper。
- 缺点：虽然容易理解但是实现起来较为繁琐，需要自己考虑锁超时，加事务等等。性能局限于数据库，一般对比缓存来说性能较低。对于高并发的场景并不是很适合。
基于乐观并发控制实现MySQL分布式锁
在我们实际项目中也是经常实现乐观并发控制，因为我们加行锁的性能消耗比较大，通常我们会对于一些竞争不是那么激烈，但是其又需要保证我们并发的顺序执行使用乐观并发控制进行处理，我们可以对我们的表加一个版本号字段。
那么我们查询出来一个版本号之后，update或者delete的时候需要依赖我们查询出来的版本号，判断当前数据库和查询出来的版本号是否相等，如果相等那么就可以执行，如果不等那么就不能执行。这样的一个策略很像我们的CAS（Compare And Swap），比较并交换是一个原子操作。这样我们就能避免加 select * for update 行锁的开销。
ZooKeeper
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
那对于我们初次认识的人，可以理解成ZooKeeper就像是我们的电脑文件系统，我们可以在d盘中创建文件夹a，并且可以继续在文件夹a中创建文件夹a1，a2。
那我们的文件系统有什么特点？那就是同一个目录下文件名称不能重复，同样ZooKeeper也是这样的。
在ZooKeeper所有的节点，也就是文件夹称作Znode，而且这个Znode节点是可以存储数据的。
我们以某个资源为目录，然后这个目录下面的节点就是我们需要获取锁的客户端，未获取到锁的客户端注册需要注册Watcher到上一个客户端，可以用下图表示：
/lock 是我们用于加锁的目录，/resource_name 是我们锁定的资源，其下面的节点按照我们加锁的顺序排列。
Curator
Curator封装了Zookeeper底层的API，使我们更加容易方便的对Zookeeper进行操作，并且它封装了分布式锁的功能，这样我们就不需要再自己实现了。
Curator实现了可重入锁（InterProcessMutex），也实现了不可重入锁（InterProcessSemaphoreMutex）。在可重入锁中还实现了读写锁。
InterProcessMutex
InterProcessMutex是Curator实现的可重入锁，我们可以通过下面的一段代码实现我们的可重入锁:
我们利用acuire进行加锁，release进行解锁。
加锁的流程具体如下：
- 首先进行可重入的判定：这里的可重入锁记录在
ConcurrentMap<Thread, LockData> threadData这个Map里面，如果threadData.get(currentThread)是有值的那么就证明是可重入锁，然后记录就会加1。我们之前的MySQL其实也可以通过这种方法去优化，可以不需要count字段的值，将这个维护在本地可以提高性能。 - 然后在我们的资源目录下创建一个节点:比如这里创建一个/0000000002这个节点，这个节点需要设置为EPHEMERAL_SEQUENTIAL也就是临时节点并且有序。
- 获取当前目录下所有子节点，判断自己的节点是否位于子节点第一个。
- 如果是第一个，则获取到锁，那么可以返回。
- 如果不是第一个，则证明前面已经有人获取到锁了，那么需要获取自己节点的前一个节点。/0000000002的前一个节点是/0000000001，我们获取到这个节点之后，再上面注册Watcher(这里的watcher其实调用的是object.notifyAll(),用来解除阻塞)。
- object.wait(timeout)或object.wait():进行阻塞等待这里和我们第5步的watcher相对应。
解锁的具体流程：
- 首先进行可重入锁的判定:如果有可重入锁只需要次数减1即可，减1之后加锁次数为0的话继续下面步骤，不为0直接返回。
- 删除当前节点。
- 删除threadDataMap里面的可重入锁的数据。
读写锁
Curator提供了读写锁，其实现类是InterProcessReadWriteLock，这里的每个节点都会加上前缀：
private static final String READ_LOCK_NAME = "__READ__";
private static final String WRITE_LOCK_NAME = "__WRIT__";
根据不同的前缀区分是读锁还是写锁，对于读锁，如果发现前面有写锁，那么需要将watcher注册到和自己最近的写锁。写锁的逻辑和我们之前分析的依然保持不变。
锁超时
Zookeeper不需要配置锁超时，由于我们设置节点是临时节点，我们的每个机器维护着一个ZK的session，通过这个session，ZK可以判断机器是否宕机。如果我们的机器挂掉的话，那么这个临时节点对应的就会被删除，所以我们不需要关心锁超时。
ZooKeeper小结
- 优点：ZooKeeper可以不需要关心锁超时时间，实现起来有现成的第三方包，比较方便，并且支持读写锁，ZooKeeper获取锁会按照加锁的顺序，所以其是公平锁。对于高可用利用ZK集群进行保证。
- 缺点：ZooKeeper需要额外维护，增加维护成本，性能和MySQL相差不大，依然比较差。并且需要开发人员了解ZooKeeper是什么。
Redis
https://swsmile.info/post/redis-distributed-lock/
etcd
Reference
- https://en.wikipedia.org/wiki/Distributed_lock_manager
- https://helix.apache.org/1.0.2-docs/recipes/lock_manager.html
- https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
- https://redis.io/docs/manual/patterns/distributed-locks/
- https://davidecerbo.medium.com/everything-i-know-about-distributed-locks-2bf54de2df71
- https://www.alibabacloud.com/help/doc-detail/146758.htm
- https://www.alibabacloud.com/blog/the-technical-practice-of-distributed-locks-in-a-storage-system_597141
- 再有人问你分布式锁，这篇文章扔给他 - https://juejin.im/post/5bbb0d8df265da0abd3533a5
- 分布式锁看这篇就够了 - https://zhuanlan.zhihu.com/p/42056183
- 通俗讲解分布式锁，看完不懂算作者输 - https://zhuanlan.zhihu.com/p/72896771