Redis做分布式锁

（一）为什么要有分布式锁以及本质

  在一个分布式的系统中，会涉及到多个客户端访问同一个公共资源的问题，这时候我们就需要通过锁来做互斥控制，来避免类似于线程安全的问题

  因为我们学过的sychronized只能对线程加锁，在分布式系统中无法对进程进行加锁，此时我们就需要用分布式锁

 那分布式锁的本质我们可以理解为一个公共服务器，来记录加锁的状态，那我们这里使用redis来作为这个公共服务器

（二）分布式锁的基本实现

1.基础实现

  我们说分布式锁的本质是服务器，来记录加锁状态，那这个加锁的本质就是通过一个键值对的方式来标识锁的状态

  就用我们常见的购票场景，我们现在有多个服务器节点来提供购票需求，那购票的流程：先查询指定车的余票，如果余票>0，就-=1，很明显，这个操作不是原子的，就会导致有其他服务器节点插到中间执行，这就会导致超卖的情况（这种情况在单机上，我们可以通过对线程加锁的方式来处理，但是加锁对于多进程来说，是无能为力的）

  如果我们最终存储数据的服务器是mysql，我们可以使用事务来解决，但是如果不是，我们还是需要之后的步骤

 那我们这里想要加锁，我们就需要引入一个公共服务器，作为分布式锁的管理者

我们服务器节点会先访问redis，在redis设置一个键值对，比如key是车次

   如果这个操作设置成功，就视为有服务器节点对这个车次进行加锁了，其他的服务器节点想要购票时，就也需要写一个键值对，但是我们会发现这个key已经存在了此时就需要进行阻塞等待，等到我们加锁的这个服务器节点在进行完数据库的读写操作后，就要把redis刚才的键值对给删除掉，这个删除操作就相当于释放锁，然后我们其他的服务器节点才可以再次购票进行加锁解锁操作

 注：我们redis本来就是key-value结构，并且提供了setnx操作，当我们key不存在的时候就设置成功，存在就设置失败，所以使用redis很合适

2.引入过期时间

 当服务器1加锁后解锁前，如果服务器1挂了，就会导致我们这个解锁操作不能执行，那么其他的服务器程序就一直无法获取到锁

 那我们之前讲多线程的时候，使用了finally，来保证最后一定会解决，那这个能不能在分布式锁中使用呢？    是不可以的，因为我们加锁不是在自己进程中加的，而是在一个公共服务器中加的，程序异常退出，是不会给公共服务器上的锁解锁的

 那我们如果挂了，为了解决无法解锁的问题，不如我们未雨绸缪，我们在设置key的同时引入过期时间来保证这个key存在多久就自动销毁（这个锁加锁多久后自动解锁）

 那我们可以使用redis中的set ex nx的方式，在设置锁的同时设置过期时间

 注意：如果我们使用setnx 后使用expire，因为是两个指令，不是原子的，即使使用事务也不能保证都执行正确，就导致可能会出现无法正确释放锁的问题

3.引入校验id

   对于redis中的数据，我们其他服务器节点也是可以删除的，上述情况下，我们一个服务器对他加锁后，另一个服务器也可以进行解锁操作，虽然我们不会故意让另一个服务区程序去解锁，但是我们还是要保证不能因为一些bug导致服务器2把key误删了

  为了解决这个问题，我们可以把我们的服务器程序的编号给放到value中，因为我们上述说是写key然后校验key是否存在来判断是否加锁的，这个value的值就可以任我们发挥，那我们value放服务器编号，然后我们想要解锁时，先判断这个key对应的value是不是我们当前的服务器，如果是就进行删除，不是就不可以删除

那我们伪代码如下

 我们发现，这里的get和del不是原子的，那就可能会出现错误

  如果在多线程的情况下就会导致重复删除一个key，那有人会有疑问，重复删就删了呗，那如果此时正好有一个set key在最后一个del之前执行呢？这就会导致我们新设置的key被直接删除了

 那这里的问题我们可以使用redis事务来解决，也可以使用lua脚本

4.lua脚本

  lua是redis的一个内嵌语言，语法简单并且执行速度快，且轻量，并且redis官方文档说，我们可以使用lua来实现redis的事务

 因为redis执行lua脚本是相当于一个操作也就是原子的，但是lua脚本中可以有很多操作

如果使用lua脚本，那代码可以写为

5.引入watch dog

  上述方案还有一个问题，也就是我们过期时间的设置，我们设置了key过期时间后，可能会导致我们任务没执行完，key就过期了，或者当我们key过期时间很长，就会导致其他服务器无法及时加锁，那么针对这个问题，我们就引入了一个watch dog，本质上是加锁服务器上的一个单独线程，来针对这个加锁时间进行“续约”

 就比如，我们先设置过期时间1s，当还剩300ms我们任务没执行完，我们这个watch dog线程就会把过期时间重新设置，也就是续约过程，这样就不用担心过期时间设置的过长或者过短了，因为过期时间变成了动态的

 而且当我们服务器挂了，这个线程也就挂了，过期时间就不会改变，就可以正常的释放锁

6.引入redlock

我们上述都是在讨论服务器节点的问题，那假如我们redis服务器挂了呢？这时有人会说，主从结构和哨兵可以帮我们解决啊，我们一直会有主节点的，虽然是这样，但是会存在我们之前的主节点中有一些加锁操作没来得及同步数据给从节点，导致数据丢失，这样就相当于没有加锁，其他服务器就可以进行加锁

 那为了解决这种问题，redis作者提出了redlock算法

也就是引入了一组redis节点，每一组都是相同的主从结构，并且数据也相同，加锁的时候，我们按照一定顺序，写多个master节点，写操作时要设定操作的超时时间，当set key的操作超过超时时间没有成功，就视为加锁失败

  如果给某个节点加锁失败，就尝试下一个节点，当加锁成功的节点数超过总数一半，就视为加锁成功

 这个算法就是通过空间换取准确度