面试官：你真的了解Redis分布式锁吗？

什么是分布式锁

说到Redis，咱们第一想到的功能就是能够缓存数据，除此以外，Redis由于单进程、性能高的特色，它还常常被用于作分布式锁。

锁咱们都知道，在程序中的做用就是同步工具，保证共享资源在同一时刻只能被一个线程访问，Java中的锁咱们都很熟悉了，像synchronized 、Lock都是咱们常用的，可是Java的锁只能保证单机的时候有效，分布式集群环境就无能为力了，这个时候咱们就须要用到分布式锁。

分布式锁，顾名思义，就是分布式项目开发中用到的锁，能够用来控制分布式系统之间同步访问共享资源，通常来讲，分布式锁须要知足的特性有这么几点：

一、互斥性：在任什么时候刻，对于同一条数据，只有一台应用能够获取到分布式锁；

二、高可用性：在分布式场景下，一小部分服务器宕机不影响正常使用，这种状况就须要将提供分布式锁的服务以集群的方式部署；

三、防止锁超时：若是客户端没有主动释放锁，服务器会在一段时间以后自动释放锁，防止客户端宕机或者网络不可达时产生死锁；

四、独占性：加锁解锁必须由同一台服务器进行，也就是锁的持有者才能够释放锁，不能出现你加的锁，别人给你解锁了；

业界里能够实现分布式锁效果的工具不少，但操做无非这么几个：加锁、解锁、防止锁超时。

既然本文说的是Redis分布式锁，那咱们理所固然就以Redis的知识点来延伸。

实现锁的命令

先介绍下Redis的几个命令，

一、SETNX，用法是SETNX key value

SETNX是『 SET if Not eXists』(若是不存在，则 SET)的简写，设置成功就返回1，不然返回0。

setnx用法

能够看出，当把key为lock的值设置为"Java"后，再设置成别的值就会失败，看上去很简单，也好像独占了锁，但有个致命的问题，就是key没有过时时间，这样一来，除非手动删除key或者获取锁后设置过时时间，否则其余线程永远拿不到锁。

既然这样，咱们给key加个过时时间总能够吧，直接让线程获取锁的时候执行两步操做：

`SETNX Key 1`
`EXPIRE Key Seconds`

这个方案也有问题，由于获取锁和设置过时时间分红两步了，不是原子性操做，有可能获取锁成功但设置时间失败，那样不就白干了吗。

不过也不用急，这种事情Redis官方早为咱们考虑到了，因此就引出了下面这个命令

二、SETEX，用法SETEX key seconds value

将值 value 关联到 key ，并将 key 的生存时间设为 seconds (以秒为单位)。若是 key 已经存在，SETEX 命令将覆写旧值。

这个命令相似于如下两个命令：

`SET key value`
`EXPIRE key seconds  # 设置生存时间`

这两步动做是原子性的，会在同一时间完成。

setex用法

三、PSETEX ，用法PSETEX key milliseconds value

这个命令和SETEX命令类似，但它以毫秒为单位设置 key 的生存时间，而不是像SETEX命令那样，以秒为单位。

不过，从Redis 2.6.12 版本开始，SET命令能够经过参数来实现和SETNX、SETEX、PSETEX 三个命令相同的效果。

就好比这条命令

`SET key value NX EX seconds`

加上NX、EX参数后，效果就至关于SETEX，这也是Redis获取锁写法里面最多见的。

怎么释放锁

释放锁的命令就简单了，直接删除key就行，但咱们前面说了，由于分布式锁必须由锁的持有者本身释放，因此咱们必须先确保当前释放锁的线程是持有者，没问题了再删除，这样一来，就变成两个步骤了，彷佛又违背了原子性了，怎么办呢？

不慌，咱们能够用lua脚本把两步操做作拼装，就好像这样：

`if redis.call("get",KEYS[1]) == ARGV[1]`
`then`
 `return redis.call("del",KEYS[1])`
`else`
 `return 0`
`end`

KEYS[1]是当前key的名称，ARGV[1]能够是当前线程的ID(或者其余不固定的值，能识别所属线程便可)，这样就能够防止持有过时锁的线程，或者其余线程误删现有锁的状况出现。

代码实现

知道了原理后，咱们就能够手写代码来实现Redis分布式锁的功能了，由于本文的目的主要是为了讲解原理，不是为了教你们怎么写分布式锁，因此我就用伪代码实现了。

首先是redis锁的工具类，包含了加锁和解锁的基础方法：

`public class RedisLockUtil {`
 `private String LOCK_KEY = "redis_lock";`
 `// key的持有时间，5ms`
 `private long EXPIRE_TIME = 5;`
 `// 等待超时时间，1s`
 `private long TIME_OUT = 1000;`
 `// redis命令参数，至关于nx和px的命令合集`
 `private SetParams params = SetParams.setParams().nx().px(EXPIRE_TIME);`
 `// redis链接池，连的是本地的redis客户端`
 `JedisPool jedisPool = new JedisPool("127.0.0.1", 6379);`
 `/**`
 `* 加锁`
 `*`
 `* @param id`
 `*            线程的id，或者其余可识别当前线程且不重复的字段`
 `* @return`
 `*/`
 `public boolean lock(String id) {`
 `Long start = System.currentTimeMillis();`
 `Jedis jedis = jedisPool.getResource();`
 `try {`
 `for (;;) {`
 `// SET命令返回OK ，则证实获取锁成功`
 `String lock = jedis.set(LOCK_KEY, id, params);`
 `if ("OK".equals(lock)) {`
 `return true;`
 `}`
 `// 不然循环等待，在TIME_OUT时间内仍未获取到锁，则获取失败`
 `long l = System.currentTimeMillis() - start;`
 `if (l >= TIME_OUT) {`
 `return false;`
 `}`
 `try {`
 `// 休眠一会，否则反复执行循环会一直失败`
 `Thread.sleep(100);`
 `} catch (InterruptedException e) {`
 `e.printStackTrace();`
 `}`
 `}`
 `} finally {`
 `jedis.close();`
 `}`
 `}`
 `/**`
 `* 解锁`
 `*`
 `* @param id`
 `*            线程的id，或者其余可识别当前线程且不重复的字段`
 `* @return`
 `*/`
 `public boolean unlock(String id) {`
 `Jedis jedis = jedisPool.getResource();`
 `// 删除key的lua脚本`
 `String script = "if redis.call('get',KEYS[1]) == ARGV[1] then" + "   return redis.call('del',KEYS[1]) " + "else"`
 `+ "   return 0 " + "end";`
 `try {`
 `String result =`
 `jedis.eval(script, Collections.singletonList(LOCK_KEY), Collections.singletonList(id)).toString();`
 `return "1".equals(result);`
 `} finally {`
 `jedis.close();`
 `}`
 `}`
`}`

具体的代码做用注释已经写得很清楚了，而后咱们就能够写一个demo类来测试一下效果：

`public class RedisLockTest {`
 `private static RedisLockUtil demo = new RedisLockUtil();`
 `private static Integer NUM = 101;`
 `public static void main(String[] args) {`
 `for (int i = 0; i < 100; i++) {`
 `new Thread(() -> {`
 `String id = Thread.currentThread().getId() + "";`
 `boolean isLock = demo.lock(id);`
 `try {`
 `// 拿到锁的话，就对共享参数减一`
 `if (isLock) {`
 `NUM--;`
 `System.out.println(NUM);`
 `}`
 `} finally {`
 `// 释放锁必定要注意放在finally`
 `demo.unlock(id);`
 `}`
 `}).start();`
 `}`
 `}`
`}`

咱们建立100个线程来模拟并发的状况，执行后的结果是这样的：

代码执行结果

能够看出，锁的效果达到了，线程安全是能够保证的。

固然，上面的代码只是简单的实现了效果，功能确定是不完整的，一个健全的分布式锁要考虑的方面还有不少，实际设计起来不是那么容易的。

咱们的目的只是为了学习和了解原理，手写一个工业级的分布式锁工具不现实，也不必，相似的开源工具一大堆（Redisson），原理都差很少，并且早已通过业界同行的检验，直接拿来用就行。

虽然功能是实现了，但其实从设计上来讲，这样的分布式锁存在着很大的缺陷，这也是本篇文章想重点探讨的内容。

分布式锁的缺陷

1、客户端长时间阻塞致使锁失效问题

客户端1获得了锁，由于网络问题或者GC等缘由致使长时间阻塞，而后业务程序还没执行完锁就过时了，这时候客户端2也能正常拿到锁，可能会致使线程安全的问题。

客户端长时间阻塞

那么该如何防止这样的异常呢？咱们先不说解决方案，介绍完其余的缺陷后再来讨论。

2、redis服务器时钟漂移问题

若是redis服务器的机器时钟发生了向前跳跃，就会致使这个key过早超时失效，好比说客户端1拿到锁后，key的过时时间是12:02分，但redis服务器自己的时钟比客户端快了2分钟，致使key在12:00的时候就失效了，这时候，若是客户端1尚未释放锁的话，就可能致使多个客户端同时持有同一把锁的问题。

3、单点实例安全问题

若是redis是单master模式的，当这台机宕机的时候，那么全部的客户端都获取不到锁了，为了提升可用性，可能就会给这个master加一个slave，可是由于redis的主从同步是异步进行的，可能会出现客户端1设置完锁后，master挂掉，slave提高为master，由于异步复制的特性，客户端1设置的锁丢失了，这时候客户端2设置锁也可以成功，致使客户端1和客户端2同时拥有锁。

为了解决Redis单点问题，redis的做者提出了RedLock算法。

RedLock算法

该算法的实现前提在于Redis必须是多节点部署的，能够有效防止单点故障，具体的实现思路是这样的：

一、获取当前时间戳（ms）；

二、先设定key的有效时长（TTL），超出这个时间就会自动释放，而后client（客户端）尝试使用相同的key和value对全部redis实例进行设置，每次连接redis实例时设置一个比TTL短不少的超时时间，这是为了避免要过长时间等待已经关闭的redis服务。而且试着获取下一个redis实例。

好比：TTL（也就是过时时间）为5s，那获取锁的超时时间就能够设置成50ms，因此若是50ms内没法获取锁，就放弃获取这个锁，从而尝试获取下个锁；

三、client经过获取全部能获取的锁后的时间减去第一步的时间，还有redis服务器的时钟漂移偏差，而后这个时间差要小于TTL时间而且成功设置锁的实例数>= N/2 + 1（N为Redis实例的数量），那么加锁成功

好比TTL是5s，链接redis获取全部锁用了2s，而后再减去时钟漂移（假设偏差是1s左右），那么锁的真正有效时长就只有2s了；

四、若是客户端因为某些缘由获取锁失败，便会开始解锁全部redis实例。

根据这样的算法，咱们假设有5个Redis实例的话，那么client只要获取其中3台以上的锁就算是成功了，用流程图演示大概就像这样： 

key有效时长

好了，算法也介绍完了，从设计上看，毫无疑问，RedLock算法的思想主要是为了有效防止Redis单点故障的问题，并且在设计TTL的时候也考虑到了服务器时钟漂移的偏差，让分布式锁的安全性提升了很多。

但事实真的是这样吗？反正我我的的话感受效果通常般，

首先第一点，咱们能够看到，在RedLock算法中，锁的有效时间会减去链接Redis实例的时长，若是这个过程由于网络问题致使耗时太长的话，那么最终留给锁的有效时长就会大大减小，客户端访问共享资源的时间很短，极可能程序处理的过程当中锁就到期了。并且，锁的有效时间还须要减去服务器的时钟漂移，可是应该减多少合适呢，要是这个值设置很差，很容易出现问题。

而后第二点，这样的算法虽然考虑到用多节点来防止Redis单点故障的问题，但但若是有节点发生崩溃重启的话，仍是有可能出现多个客户端同时获取锁的状况。

假设一共有5个Redis节点：A、B、C、D、E，客户端1和2分别加锁

1. 客户端1成功锁住了A，B，C，获取锁成功（但D和E没有锁住）。
2. 节点C的master挂了，而后锁还没同步到slave，slave升级为master后丢失了客户端1加的锁。
3. 客户端2这个时候获取锁，锁住了C，D，E，获取锁成功。

这样，客户端1和客户端2就同时拿到了锁，程序安全的隐患依然存在。除此以外，若是这些节点里面某个节点发生了时间漂移的话，也有可能致使锁的安全问题。

因此说，虽然经过多实例的部署提升了可用性和可靠性，但RedLock并无彻底解决Redis单点故障存在的隐患，也没有解决时钟漂移以及客户端长时间阻塞而致使的锁超时失效存在的问题，锁的安全性隐患依然存在。

结论

有人可能要进一步问了，那该怎么作才能保证锁的绝对安全呢？

对此我只能说，鱼和熊掌不可兼得，咱们之因此用Redis做为分布式锁的工具，很大程度上是由于Redis自己效率高且单进程的特色，即便在高并发的状况下也能很好的保证性能，但不少时候，性能和安全不能彻底兼顾，若是你必定要保证锁的安全性的话，能够用其余的中间件如db、zookeeper来作控制，这些工具能很好的保证锁的安全，但性能方面只能说是差强人意，不然你们早就用上了。

通常来讲，用Redis控制共享资源而且还要求数据安全要求较高的话，最终的保底方案是对业务数据作幂等控制，这样一来，即便出现多个客户端得到锁的状况也不会影响数据的一致性。固然，也不是全部的场景都适合这么作，具体怎么取舍就须要各位看官本身处理啦，毕竟，没有完美的技术，只有适合的才是最好的。

---

做者：鄙人薛某，一个不拘于技术的互联网人，想看更多精彩文章能够关注个人公众号，扫描下方二维码或者微信搜索鄙人薛某便可，回复【电子书】还能获取学习资料哦~~~咱们下期再见！