## 一、什么是分布式锁 ### 1.1 分布式锁介绍分布式锁是控制不同系统之间访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来保证一致性。 ### 1.2 为什么需要分布式锁在单机部署的系统中，使用线程锁来解决高并发的问题，多线程访问共享变量的问题达到数据一致性，如使用synchornized、ReentrantLock等。但是在后端集群部署的系统中，程序在不同的JVM虚拟机中运行，且因为synchronized或ReentrantLock都只能保证同一个JVM进程中保证有效，所以这时就需要使用分布式锁了。这里就不再赘述synchornized锁的原理。 ### 1.3 分布式锁需要具备的条件分布式锁需要具备互斥性、不会死锁和容错等。互斥性，在于不管任何时候，应该只能有一个线程持有一把锁；不会死锁在于即使是持有锁的客户端意外宕机或发生进程被kill等情况时也能释放锁，不至于导致整个服务死锁。容错性指的是只要大多数节点正常工作，客户端应该都能获取和释放锁。 ## 二、分布式锁的实现方式目前主流的分布式锁的实现方式，基于数据库实现分布式锁、基于Redis实现分布式锁、基于ZooKeeper实现分布式锁，本篇文章主要介绍了Redis实现的分布式锁。 ### 2.1 由单机部署到集群部署锁的演变一开始在redis设置一个默认值key：ticket 对应的值为20，并搭建一个Spring Boot服务，用来模拟多窗口卖票现象，配置类的代码就不一一列出了。 #### 2.1.1 单机模式解决并发问题一开始的时候在redis预设置的门票值ticket=20，那么当一个请求进来之后，会判断是否余票是否是大于0，若大于0那么就将余票减一，再重新写入Redis中，倘若库存小于0，那么就会打印错误日志。 ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } return "end"; } } ``` **代码运行分析：** 这里明显有一个问题，就是当前若有两个线程同时请求进来，那么两个线程同时请求这段代码时，如图thread 1 和thread 2同时，两个线程从Redis拿到的数据都是20，那么执行完成后thread 1 和thread 2又将减完后的库存ticket=19重新写入Redis，那么数据就会产生问题，实际上两个线程各减去了一张票数，然而实际写进就减了一次票数，就出现了数据不一致的现象。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/50649c760cc041e39defb4ae69236f40~tplv-k3u1fbpfcp-zoom-1.image) 这种问题很好解决，上述问题的产生其实就是从Redis中拿数据和减余票不是原子操作，那么此时只需要将按下图代码给这俩操作加上synchronized同步代码快就能解决这个问题。 ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; synchronized (this) { int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } } return "end"; } } ``` **代码运行分析：** 此时当多个线程执行到第14行的位置时，只会有一个线程能够获取锁，进入synchronized代码块中执行，当该线程执行完成后才会释放锁，等下个线程进来之后就会重新给这段代码上锁再执行。说简单些就是让每个线程排队执行代码块中的代码，从而保证了线程的安全。上述的这种做法如果后端服务只有一台机器，那毫无疑问是没问题的，但是现在互联网公司或者是一般软件公司，后端服务都不可能只用一台机器，最少都是2台服务器组成的后端服务集群架构，那么synchronized加锁就显然没有任何作用了。如下图所示，若后端是两个微服务构成的服务集群，由nginx将多个的请求负载均衡转发到不同的后端服务上，由于synchronize代码块只能在同一个JVM进程中生效，两个请求能够同时进两个服务，所以上面代码中的synchronized就一点作用没有了。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b3287bea5dfc4d988a1e583740cd2aea~tplv-k3u1fbpfcp-zoom-1.image) 用JMeter工具随便测试一下，就很简单能发现上述代码的bug。实际上synchronized和juc包下个那些锁都是只能用于JVM进程维度的锁，并不能运用在集群或分布式部署的环境中。 #### 2.1.2 集群模式解决并发问题通过上面的实验很容易就发现了synchronized等JVM进程级别的锁并不能解决分布式场景中的并发问题，就是为了应对这种场景产生了分布式锁。本篇文章介绍了Redis实现的分布式锁，可以通过Redis的setnx（只在键key不存在的情况下, 将键key的值设置为value。若键key已经存在, 则SETNX命令不做任何动作。）的指令来解决的，这样就可以解决上面集群环境的锁不唯一的情况。 ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; // redis setnx 操作 Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "dewu"); if (Boolean.FALSE.equals(result)) { return "error"; } int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } stringRedisTemplate.delete(lockKey); return "end"; } } ``` **代码运行分析：** 代码是有问题的，就是当执行扣减余票操作时，若业务代码报了异常，那么就会导致后面的删除Redis的key代码没有执行到，就会使Redis的key没有删掉的情况，那么Redis的这个key就会一直存在Redis中，后面的线程再进来执行下面这行代码都是执行不成功的，就会导致线程死锁，那么问题就会很严重了。为了解决上述问题其实很简单，只要加上一个try...finally即可，这样业务代码即使抛了异常也可以正常的释放锁。**setnx + try ... finally解决**，具体代码如下： ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; // redis setnx 操作 try { Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "dewu"); if (Boolean.FALSE.equals(result)) { return "error"; } int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } } finally { stringRedisTemplate.delete(lockKey); } return "end"; } } ``` **代码运行分析**：上述业务代码执行报错的问题解决了，但是又会有新的问题，当程序执行到try代码块中某个位置服务宕机或者服务重新发布，这样就还是会有上述的Redis的key没有删掉导致死锁的情况。这样可以使用Redis的过期时间来进行设置key，**setnx + 过期时间解决**，如下代码所示： ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; // redis setnx 操作 try { Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "dewu"); //程序执行到这 stringRedisTemplate.expire(lockKey, 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(result)) { return "error"; } int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } } finally { stringRedisTemplate.delete(lockKey); } return "end"; } } ``` **代码运行分析**：上述代码解决了因为程序执行过程中宕机导致的锁没有释放导致的死锁问题，但是如果代码像上述的这种写法仍然还是会有问题，当程序执行到第18行时，程序宕机了，此时Redis的过期时间并没有设置，也会导致线程死锁的现象。可以用了Redis设置的原子命设置过期时间的命令，**原子性过期时间的setnx命令**，如下代码所示： ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; // redis setnx 操作 try { Boolean result = stringRedisTemplate.opsForValue().setIfPresent(lockKey, "dewu", 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(result)) { return "error"; } int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } } finally { stringRedisTemplate.delete(lockKey); } return "end"; } } ``` **代码运行分析**：通过设置原子性过期时间命令可以很好的解决上述这种程序执行过程中突然宕机的情况。这种Redis分布式锁的实现看似已经没有问题了，但在高并发场景下任会存在问题，一般软件公司并发量不是很高的情况下，这种实现分布式锁的方式已经够用了，即使出了些小的数据不一致的问题，也是能够接受的，但是如果是在高并发的场景下，上述的这种实现方式还是会存在很大问题。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8c0630c34450453fbfa8dfab98b7feea~tplv-k3u1fbpfcp-zoom-1.image) 如上面代码所示，该分布式锁的过期时间是10s，假如thread 1执行完成时间需要15s，且当thread 1线程执行到10s时，Redis的key恰好就是过期就直接释放锁了，此时thread 2就可以获得锁执行代码了，假如thread 2线程执行完成时间需要8s，那么当thread 2线程执行到第5s时，恰好thread 1线程执行了释放锁的代码————**stringRedisTemplate**.delete(lockKey); 此时，就会发现thread 1线程删除的锁并不是其自己的加锁，而是thread 2加的锁；那么thread 3就又可以进来了，那么假如一共执行5s，那么当thread 3执行到第3s时，thread 2又会恰好执行到释放锁的代码，那么thread 2又删除了thread 3 加的锁。在高并发场景下，倘若遇到上述问题，那将是灾难性的bug，只要高并发存在，那么这个分布式锁就会时而加锁成功时而加锁失败。解决上述问题其实也很简单，让每个线程加的锁时给Redis设置一个唯一id的value，每次释放锁的时候先判断一下线程的唯一id与Redis 存的值是否相同，若相同即可释放锁。**设置线程id的原子性过期时间的setnx命令，** 具体代码如下： ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { String lockKey = "ticket"; String threadUniqueKey = UUID.randomUUID().toString(); // redis setnx 操作 try { Boolean result = stringRedisTemplate.opsForValue().setIfPresent(lockKey, threadUniqueKey, 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(result)) { return "error"; } int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } } finally { if (Objects.equals(stringRedisTemplate.opsForValue().get(lockKey), threadUniqueKey)) { stringRedisTemplate.delete(lockKey); } } return "end"; } } ``` **代码运行分析**：上述实现的Redis分布式锁已经能够满足大部分应用场景了，但是还是略有不足，比如当线程进来需要的执行时间超过了Redis key的过期时间，那么此时已经释放了，你其他线程就可以立马获得锁执行代码，就又会产生bug了。分布式锁Redis key的过期时间不管设置成多少都不合适，比如将过期时间设置为30s，那么如果业务代码出现了类似慢SQL、查询数据量很大那么过期时间就不好设置了。那么这里有没有什么更好的方案呢？答案是有的——锁续命。那么锁续命方案的原来就在于当线程加锁成功时，会开一个分线程，取锁过期时间的1/3时间点定时执行任务，如上图的锁为例，每10s判断一次锁是否存在(即Redis的key)，若锁还存在那么就直接重新设置锁的过期时间，若锁已经不存在了那么就直接结束当前的分线程。 ### 2.2 Redison框架实现Redis分布式锁上述“锁续命”方案说起来简单，但是实现起来还是挺复杂的，于是市面上有很多开源框架已经帮我们实现好了，所以就不需要自己再去重复造轮子再去写一个分布式锁了，所以本次就拿Redison框架来举例，主要是可以学习这种设计分布式锁的思想。 #### 2.2.1 Redison分布式锁的使用 Redison实现的分布式锁，使用起来还是非常简单的，具体代码如下： ``` @RestController @Slf4j public class RedisLockController { @Resource private Redisson redisson; @Resource private StringRedisTemplate stringRedisTemplate; @RequestMapping("/lock") public String deductTicket() throws InterruptedException { //传入Redis的key String lockKey = "ticket"; // redis setnx 操作 RLock lock = redisson.getLock(lockKey); try { //加锁并且实现锁续命 lock.lock(); int ticketCount = Integer.parseInt(stringRedisTemplate.opsForValue().get(lockKey)); if (ticketCount > 0) { int realTicketCount = ticketCount - 1; log.info("扣减成功，剩余票数：" + realTicketCount + ""); stringRedisTemplate.opsForValue().set(lockKey, realTicketCount + ""); } else { log.error("扣减失败，余票不足"); } } finally { //释放锁 lock.unlock(); } return "end"; } } ``` #### 2.2.2 Redison分布式锁的原理 Redison实现分布式锁的原理流程如下图所示，当线程1加锁成功，并开始执行业务代码时，Redison框架会开启一个后台线程，每隔锁过期时间的1/3时间定时判断一次是否还持有锁(Redis中的key是否还存在)，若不持有那么就直接结束当前的后台线程，若还持有锁，那么就重新设置锁的过期时间。当线程1加锁成功后，那么线程2就会加锁失败，此时线程2就会就会做类似于CAS的自旋操作，一直等待线程1释放了之后线程2才能加锁成功。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/654186f0cdda409f9ff3734b3cefb89d~tplv-k3u1fbpfcp-zoom-1.image) #### 2.2.3 Redison分布式锁的源码分析 Redison底层实现分布式锁时使用了大量的lua脚本保证了其加锁操作的各种原子性。Redison实现分布式锁使用lua脚本的好处主要是能保证Redis的操作是原子性的，Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。 **Redisson核心使用lua脚本加锁源码分析：** 方法名为tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command)： ``` //使用lua脚本加锁方法 RFuture tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command) { internalLockLeaseTime = unit.toMillis(leaseTime); return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command, //当第一个线程进来会直接执行这段逻辑 //判断传入的Redis的key是否存在，即String lockKey = "ticket"; "if (redis.call('exists', KEYS[1]) == 0) then " + //如果不存在那么就设置这个key为传入值、当前线程id 即参数ARGV[2]值(即getLockName(threadId)),并且将线程id的value值设置为1 "redis.call('hset', KEYS[1], ARGV[2], 1); " + //再给这个key设置超时时间，超时时间即参数ARGV[1](即internalLockLeaseTime的值)的时间 "redis.call('pexpire', KEYS[1], ARGV[1]); " + "return nil; " + "end; " + //当第二个线程进来，Redis中的key已经存在(锁已经存在)，那么直接进这段逻辑 //判断这个Redis key是否存在且当前的这个key是否是当前线程设置的 "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " + //如果是的话，那么就进入重入锁的逻辑，利用hincrby指令将第一个线程进来将线程id的value值设置为1再加1 //然后每次释放锁的时候就会减1，直到这个值为0，这把锁就释放了，这点与juc的可重锁类似 //“hincrby”指令为Redis hash结构的加法 "redis.call('hincrby', KEYS[1], ARGV[2], 1); " + "redis.call('pexpire', KEYS[1], ARGV[1]); " + "return nil; " + "end; " + //倘若不是本线程加的锁，而是其他线程加的锁,由于上述lua脚本都是有线程id的校验，那么上面的两段lua脚本都不会执行 //那么此时这里就会将当前这个key的过期时间返回 "return redis.call('pttl', KEYS[1]);", Collections.