前言

以前在学校做小项目的时候，用到Redis，基本也只是用来当作缓存。可阿粉在工作中发现，Redis在生产中并不只是当作缓存这么简单。在阿粉接触到的项目中，Redis起到了一个分布式锁的作用，具体情况是这样的：

该项目在某金融平台中负责某块业务，是一个分布式系统，线上大概跑着10个左右的实例。其中有一个步骤需要用户支付一定的费用，Redis分布式锁在其中大概处于这么一个位置：

 

可以看到在上分布式锁之后，系统做了两个查询校验，然后向数据库中插入了一条订单记录，接着才解锁进入支付流程。

从业务的角度考虑分布式锁是好理解的，它保证了查询及插入数据整个流程的原子性，防止查询校验的时候查到脏数据，使得支付前订单信息落表的操作串行化执行。

尽管从业务上来说很好理解，但使用Redis作为分布式锁对我来说是个新知识，阿粉打算结合项目中的代码，深挖一下这个知识点。  

正文

1. 为什么要使用分布式锁

在实际项目中见过分布式锁后，就不难理解为什么要使用分布式锁了：总结来说就是分布式系统要访问共享资源，为了避免并发访问资源带来错误，我们为共享资源添加一把锁，让各个访问互斥，保证并发访问的安全性，这就是使用分布式锁的原因。

2. Redis中分布式锁的实现

redis中使用分布式锁很简单，只要使用setnx指令对某个key上锁就行：

setnx lock test //上锁
del lock test   //解锁

当某个key没有被占用的时候，setnx指令会返回1，否则返回0，这就是Redis中分布式锁的使用原理。

当然我们还可以在上锁之后使用expire指令给锁设置过期时间。

看到这里你可能会有疑问，如果我们的程序流程不使用指令解锁，靠redis设置时间过期来解锁，貌似会出问题。假如我们的服务进程在执行setnx之后和执行expire指令之前挂掉了，那这个锁岂不是永远都不能被释放？

没错，这确实是个问题，当时人们在Redis的开源社区提出了一堆解决方案专门来解决这个问题，可实现方式都极为复杂。后来Redis的作者在Redis 2.8版本中加入了set指令的扩展参数，使得setnx指令和expire指令能够同时执行，具体使用像下面这个样子：

set lock test ex 5 nx
ex：设置键的过期时间
nx：只在键不存在时，才对键进行设置操作

从此以后，Redis成为了分布式锁的宠儿。

3. 分布式锁在Redis集群中遇到的麻烦

在学习了Redis中分布式锁的使用后，很快我们便发现了新的问题。在企业中，Redis基本上都是集群部署的，集群部署避免不了要面对某个节点宕机的问题。

我们考虑这么一种情况：假设我们在redis的主节点上添加了一把分布式锁，不幸的是主节点挂掉了，而且主节点上的锁还没有同步到从节点上，如果此时有客户端来请求获得同一把锁，那么它将顺利地获得锁，之前那把锁会被无情地忽视掉，这就是分布式锁在Redis集群中遇到的麻烦。

Redis的作者为了解决这个问题提出了一个叫Redlock的算法，它的原理是这样的：当上锁的时候，把set指令发送给过半的节点，只要过半的锁set成功，就认为这次加锁成功；当解锁的时候，会向所有的节点发送del指令。

从这个算法的原理可以看出，由于Redlock需要同时对多个节点进行读写，因此使用Redlock加分布式锁的性能要比单机Redis低很多。因为主从复制出纰漏的概率极低，所以如果对分布式加锁过程有一定的容错率的话，可以考虑直接使用set指令；如果追求高可用性，可以考虑使用Redlock算法。

当然，高可用性的分布式锁不只有Redis的Redlock，我们还可以用zookeeper或者支持事务的数据库做分布式锁。

❝

简述zookeeper的分布式锁原理：假设zk用某个节点作为分布式锁，当不同的客户端到zk竞争这把锁的时候，zk会按顺序给不同的客户端创建一个子节点，挂在作为分布式锁的节点下面。假设第一个来到的客户端为A，第二个来到的是B，分布式节点下挂的第一个节点就是A，B紧跟着A，且B会监听着A的生命状态，当A释放锁后A会被删除，这时B监听到A被删除，B接能上位获得分布式锁了。

❞  

在公司的项目中，虽然Redis是以集群的方式部署的，但还是使用最基本的set指令获取分布式锁，因为这种方式的性能远远高于Redlock算法，也高于zk，数据库等分布式锁实现方式。

虽然在高性能与低概率的错误中选择了高性能，但项目中还是做了其他工作对错误情况进行兜底的，比如在公司的项目中对主从复制时的错误情况会抛出异常，然后根据异常会进行一些重试的操作。