分布式锁的几种实现方式

分布式锁的几种实现方式

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们
“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”
所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，
只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。
在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。

针对分布式锁的实现，目前比较常用的有以下几种方案：

基于数据库表实现分布式锁 
基于缓存（redis，memcached，tair）实现分布式锁 
基于Zookeeper实现分布式锁

分布式锁应该具备哪些条件：

1、互斥性。在分布式系统环境下，只有一个客户端能持有锁； 
2、具有容错性，高可用的获取锁与释放锁。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。； 
3、高性能的获取锁与释放锁； 
4、具备可重入特性，同一线程在未释放锁时如果再次申请锁资源不需要走申请流程，只需要将已经获取的锁继续返回并且记录上已经重入的次数即可； 
5、具备锁失效机制，防止死锁，即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁； 
6、这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条），阻塞锁即没有获取到锁，则继续等待获取锁；非阻塞锁即没有获取到锁后，不继续等待，直接返回锁失败
7. 判断是否获得锁必须是原子性的，否则可能导致多个请求都获取到锁
8.加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

设计的时候需要考虑以下几点：
1.锁的时效设置。避免单点故障造成死锁，影响其他客户端获取锁。但是也要保证一旦一个客户端持锁，在客户端可用时不会被其他客户端解锁。
2.持锁期间的check,尽量在关键节点检查锁的状态，所以要设计成可重入锁，但在客户端使用时要做好吞吐量的权衡。
3.减少获取锁的操作，尽量减少redis压力。所以需要让客户端的申请锁有一个等待时间，而不是所有申请锁的请求要循环申请锁。
4.加锁的事务或者操作尽量粒度小，减少其他客户端申请锁的等待时间，提高处理效率和并发性。
5.持锁的客户端解锁后，要能通知到其他等待锁的节点，否则其他节点只能一直等待一个预计的时间再触发申请锁。类似线程的notifyAll,要能同步锁状态给其他客户端，并且是分布式消息。
6.考虑任何执行句柄中可能出现的异常，状态的正确流转和处理。比如，不能因为一个节点解锁失败，或者锁查询失败（redis 超时或者其他运行时异常），影响整个等待的任务队列，或者任务池。

基于数据库表的实现方式
依靠数据库唯一索引来实现，当想要获得锁时，即向数据库中插入一条记录，释放锁时就删除这条记录。
实现原理：       
       多个请求同时插入一条记录，只有一条可以插入成功，拿到锁的请求处理完则删掉数据， 没有拿到锁的则返回或者选择轮询尝试。

还可以借助数据中自带的排他锁来实现分布式的锁，基于MySql的InnoDB引擎，在查询语句后面增加for update如果成功则立刻返回，如果失败则会等待，

这种方法可以有效的解决上面提到的无法释放锁和非阻塞锁的问题，重入锁则不行。
优点
直接借助数据库，容易理解。
缺点
1. 非阻塞锁，立刻返回， 只能轮询或者返回失败
2. 没有锁失效机制，，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据
3. 不具备可重入的特性，，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息
4.可用性差，单点问题依然存在，数据库需要双机部署、数据同步、主备切换
5.性能开销大
会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。

操作数据库需要一定的开销，性能问题需要考虑。

使用数据库的行级锁并不一定靠谱，尤其是当我们的锁表并不大的时候。

基于缓存实现分布式锁
redis实现思想：
使用redis的setnx()、get()、getset()方法，用于分布式锁，解决死锁问题:
 1. setnx(lockkey, 当前时间+过期超时时间) ，如果返回1，则获取锁成功；如果返回0则没有获取到锁，转向2。

 2. get(lockkey)获取值oldExpireTime ，并将这个value值与当前的系统时间进行比较，如果小于当前系统时间，则认为这个锁已经超时，可以允许别的请求重新获取，转向3。

 3. 计算newExpireTime=当前时间+过期超时时间，然后getset(lockkey, newExpireTime) 会返回当前lockkey的值currentExpireTime。

 4. 判断currentExpireTime与oldExpireTime 是否相等，如果相等，说明当前getset设置成功，获取到了锁。如果不相等，说明这个锁又被别的请求获取走了，那么当前请求可以直接返回失败，或者继续重试。

 5. 在获取到锁之后，当前线程可以开始自己的业务处理，当处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行delete释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理。
存在几个问题：

1、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在tair中，其他线程无法再获得到锁，需要传入失效时间，到达时间之后数据会自动删除。。

2、这把锁只能是非阻塞的，无论成功还是失败都直接返回，需要while重复执行。

3、这把锁是非重入的，一个线程获得锁之后，在释放锁之前，无法再次获得该锁，需要在一个线程获取到锁之后，把当前主机信息和线程信息保存起来，下次再获取之前先检查自己是不是当前锁的拥有者。
优点：
性能好，实现起来较为方便
很多缓存服务都是集群部署的，可以避免单点问题
缺点：
不支持锁持久化。
通过超时时间来控制锁的失效时间并不是十分的靠谱。
SETNX会存在锁竞争，如果在执行过程中客户端宕机，也会引起死锁问题，即锁资源无法释放。并且当一个资源解锁的时候，释放锁之后，其他之前等待的锁没有办法再次自动重试申请锁。
通过超时时间来控制锁的失效时间并不是十分的靠谱，当线程获得锁后，处理时间过长导致锁超时，就失效了锁的作用。
通过key的时间戳来判断是否需要强制解锁。但是强制解锁也存在问题，一个就是时间差问题，不同的机器的本地时间可能也存在时间差，在很小事务粒度的高并发场景下还是会存在问题，
比如删除锁的时候，在判断时间戳已经超过时效，有可能删除了其他已经获取锁的客户端的锁。另外，如果设置了一个超时时间，但是确实执行时间超过了超时时间，那么锁会被自动释放，原来持锁的客户端再次解锁的时候会出现问题，
setnx需要配合getset以及事务来完成，这样才能比较好的避免死锁问题

分布式可重入锁RLock支持可重入机制
由于高版本的redis支持lua脚本，所以redisson也对其进行了支持，采用了脚本模式
redisson加锁的流程：
判断lock键是否存在，不存在直接调用hset存储当前线程信息并且设置过期时间,返回nil，告诉客户端直接获取到锁。
判断lock键是否存在，存在则将重入次数加1，并重新设置过期时间，返回nil，告诉客户端直接获取到锁。
被其它线程已经锁定，返回锁有效期的剩余时间，告诉客户端需要等待。

解锁的流程看起来复杂些：
如果lock键不存在，发消息说锁已经可用
如果锁不是被当前线程锁定，则返回nil
由于支持可重入，在解锁时将重入次数需要减1
如果计算后的重入次数>0，则重新设置过期时间
如果计算后的重入次数<=0，则发消息说锁已经可用

基于ZooKeeper的实现方式
基于zookeeper临时有序节点和watch机制可以实现的分布式锁：
1. 创建一个锁目录lock
1.在zookeeper指定节点（locks）下创建临时顺序节点node_n
2.获取locks下所有子节点children
3.对子节点按节点自增序号从小到大排序
4.判断本节点是不是第一个子节点，若是，则获取锁；若不是，则监听比该节点小的那个节点的删除事件，进入等待。
5.若监听事件生效，则回到第二步重新进行判断，直到获取到锁如果是则获得锁。
可以直接使用zookeeper第三方库Curator客户端，这个客户端中封装了一个可重入的锁服务。
Curator提供的InterProcessMutex是分布式锁的实现。acquire方法用户获取锁，release方法用于释放锁。
优点：不依靠超时时间释放锁，具备高可用、可重入、阻塞锁特性，可解决不可重入问题，非阻塞问题，失效死锁，单点故障问题，支持锁持久化。

缺点：因为需要频繁的创建和删除节点，ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上，性能上不如Redis方式。

三种方案的比较
从理解的难易程度角度（从低到高）

数据库 > 缓存 > Zookeeper

从实现的复杂性角度（从低到高）

Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）

缓存 > Zookeeper >= 数据库

从可靠性角度（从高到低）

Zookeeper > 缓存 > 数据库