分布式锁的介绍及使用方案

一、分布式锁

当应用服务器数量超过1台，对相同数据的访问可能造成访问冲突（特别是写冲突）。单纯使用关系数据库比如MYSQL的应用可以借助于事务来实现锁，也可以使用版本号等实现乐观锁，最大的缺陷就是可用性降低（性能差）。对于GLEASY这种满足大规模并发访问请求的应用来说，使用数据库事务来实现数据库就有些捉襟见肘了。另外对于一些不依赖数据库的应用，比如分布式文件系统，为了保证同一文件在大量读写操作情况下的正确性，必须引入分布式锁来约束对同一文件的并发操作。

二、对分布式锁的要求
1.高性能（分布式锁不能成为系统的性能瓶颈）
2.避免死锁（拿到锁的结点挂掉不会导致其它结点永远无法继续）
3.支持锁重入

三、分布式锁的解决方式

1、是否可以考虑采用ReentrantLock来实现，但是实际上去实现的时候是有问题的，ReentrantLock的lock和unlock要求必须是在同一线程进行，而分布式应用中，lock和unlock是两次不相关的请求，因此肯定不是同一线程，因此导致无法使用ReentrantLock。

2、基于数据库表做乐观锁，用于分布式锁。

3、使用memcached的add()方法，用于分布式锁。

4、使用memcached的cas()方法，用于分布式锁。(不常用) 

5、使用redis的setnx()、expire()方法，用于分布式锁。

6、使用redis的setnx()、get()、getset()方法，用于分布式锁。

7、使用redis的watch、multi、exec命令，用于分布式锁。(不常用) 

8、使用zookeeper，用于分布式锁。(不常用) 

 

1）基于数据库资源表做乐观锁，用于分布式锁

大多数是基于数据版本(version)的记录机制实现的。何谓数据版本号？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个 “version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。在更新过程中，会对版本号进行比较，如果是一致的，没有发生改变，则会成功执行本次操作；如果版本号不一致，则会更新失败。

ABA问题：

假设我们有一张资源表，如下图所示: t_resource , 其中有6个字段id, resoource,  state, add_time, update_time, version,分别表示表主键、资源、分配状态(1未分配  2已分配)、资源创建时间、资源更新时间、资源数据版本号。

假设我们现在我们对id=5780这条数据进行分配，那么非分布式场景的情况下，我们一般先查询出来state=1(未分配)的数据，然后从其中选取一条数据可以通过以下语句进行，如果可以更新成功，那么就说明已经占用了这个资源。 

update t_resource set state=2 wherestate=1 and id=5780。（类似于CAS操作）返回影响行数0即失败，1即成功。

如果在分布式场景中，由于数据库的update操作是原子是原子的，其实上边这条语句理论上也没有问题，但是这条语句如果在典型的“ABA”情况下，我们是无法感知的。比如银行账户存款或者扣款的过程中，这种情况是比较恐怖的。

乐观锁解决：

a. 先执行select操作查询当前数据的数据版本号,比如当前数据版本号是26：

 select id, resource, state,version from t_resource  where state=1 and id=5780;

 b. 执行更新操作：

 update t_resoure set state=2, version=27, update_time=now() where resource=xxxxxx and state=1 andversion=26

 c. 如果上述update语句真正更新影响到了一行数据，那就说明占位成功。如果没有更新影响到一行数据，则说明这个资源已经被别人占位了。

 乐观锁的缺点：

(1). 这种操作方式，使原本一次的update操作，必须变为2次操作: select版本号一次；update一次。增加了数据库操作的次数。

(2). 如果业务场景中的一次业务流程中，多个资源都需要用保证数据一致性，那么如果全部使用基于数据库资源表的乐观锁，就要让每个资源都有一张资源表，这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作，在高并发的要求下，对数据库连接的开销一定是无法忍受的。

 (3)乐观锁机制往往基于系统中的数据存储逻辑，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整，如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开。

2）使用memcached的add()方法

对于使用memcached的add()方法做分布式锁，这个在互联网公司是一种比较常见的方式，而且基本上可以解决自己手头上的大部分应用场景。在使用这个方法之前，只要能搞明白memcached的add()和set()的区别，并且知道为什么能用add()方法做分布式锁就好。如果key是已经存在的set是更新原来的数据，而add则不会。

memcache::add 方法：add方法用于向memcache服务器添加一个要缓存的数据。

memcache::set 方法：set方法用于设置一个指定key的缓存内容，set方法是add方法和replace方法的集合体

mmecache::replace方法： replace方法用于替换一个指定key的缓存内容，如果key不存在则返回false

比较：

方法	当key存在	当key不存在
add	false	true
replace	替换（true）	false
set	替换（true）	true

避免死锁问题：

如果使用memcached的add()命令对资源占位成功了我们需要在add()的使用指定当前添加的这个key的有效时间，如果不指定有效时间，正常情况下，你可以在执行完自己的业务后，使用delete方法将这个key删除掉，也就是释放了占用的资源。但是，如果在占位成功后，memecached或者自己的业务服务器发生宕机了，那么这个资源将无法得到释放。所以通过对key设置超时时间，即便发生了宕机的情况，也不会将资源一直占用，可以避免死锁的问题。

其缺点：

memcached采用列入LRU置换策略，所以如果内存不够，可能导致缓存中的锁信息丢失。

memcached无法持久化，一旦重启，将导致信息丢失。

 

3）用redis的setnx()、expire()方法

对于使用redis的setnx()、expire()来实现分布式锁，这个方案相对于memcached()的add()方案，redis占优势的是，其支持的数据类型更多，而memcached只支持String一种数据类型。

 首先说明一下setnx()命令，setnx的含义就是SET if Not Exists，其主要有两个参数 setnx(key, value)。该方法是原子的，如果key不存在，则设置当前key成功，返回1；如果当前key已经存在，则设置当前key失败，返回0。但是要注意的是setnx命令不能设置key的超时时间，只能通过expire()来对key设置。

 具体的使用步骤如下: 

1、setnx(lockkey, 1)  如果返回0，则说明占位失败；如果返回1，则说明占位成功

2、expire()命令对lockkey设置超时时间，为的是避免死锁问题。

3、执行完业务代码后，可以通过delete命令删除key。

 这个方案其实是可以解决日常工作中的需求的，但从技术方案的探讨上来说，可能还有一些可以完善的地方。比如，如果在第一步setnx执行成功后，在expire()命令执行成功前，发生了宕机的现象，那么就依然会出现死锁的问题，所以如果要对其进行完善的话，可以使用redis的setnx()、get()和getset()方法来实现分布式锁。   

 

4）使用redis的setnx()、get()、getset()方法

这个方案的背景主要是在setnx()和expire()的方案上针对可能存在的死锁问题，做了一版优化。

getset()命令？这个命令主要有两个参数 getset(key，newValue)。该方法是原子的，对key设置newValue这个值，并且返回key原来的旧值。假设key原来是不存在的，那么多次执行这个命令，会出现下边的效果：

1、getset(key, "value1")  返回nil   此时key的值会被设置为value1

2. getset(key, "value2")  返回value1   此时key的值会被设置为value2

3. 依次类推！

 介绍完要使用的命令后，具体的使用步骤如下：

 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释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理。

6、也可以使用Redis的jedis客户端实现。

6）zookeeper

1、实现原理：

基于zookeeper瞬时有序节点实现的分布式锁，其主要逻辑如下（该图来自于IBM网站）。大致思想即为：每个客户端对某个功能加锁时，在zookeeper上的与该功能对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

2、优点

锁安全性高，zk可持久化

3、缺点

性能开销比较高。因为其需要动态产生、销毁瞬时节点来实现锁功能。

4、实现

可以直接采用zookeeper第三方库curator即可方便地实现分布式锁。