什么时候你应该使用redis来实现锁

在项目的开发过程中，经常会有以下几种场景：

1. 用户下单，由于点击速度过快，或者页面卡住导致用户又点击了一次，这个时候后台就给用户生成了两笔订单。
2. 消息队列的消费方由于网络抖动导致的超时，或者ack失败，导致消息重发，导致了计算结果重复或者出错。
3. 某些需求需要限制n分钟某个用户只能操作一次。

类似这样的场景还有很多很多，每次面对这样的场景的时候，大部分同学都会说，“那我加个锁吧”，然后，你就会发现大部分的实现方式如下：

我们来看看上面的实现有没有问题。

假设在操作del命令的时候进行了网络抖动导致命令操作失败，这个锁就成了死锁，显然是不能接受的。

那我们改进一下，我们将锁的值设置为锁的有效时间，获取锁失败之后，我们再get一下，判断一下时间是否过期，如果过期了再删除，重新尝试获取锁。

如果没有过期，说明获取锁失败。这样是不是就没问题了？来看一个场景

假设A、B同时获取锁，发现锁被占用，A、B先后get，发现锁过期，A执行del，然后进行了setnx操作，获取锁成功。此时B执行del操作，然后也进行了setnx操作，获取锁成功，问题就来了，A、B同时获取到了锁，如下图：

所以，正确的做法应该是使用getset来替换del，这个命令是原子，如下图

使用getset方法时，如果遇到上面的情况，A执行getset发现过期，执行del。B执行getset，因为getset是原子的，获取到的将是A执行之后的值，此时值将不是过期的，可以有效的避免这个问题。

同时，redis在2.6.12版本后，提供了更强大的set命令

所以我们的加锁过程就变得比较简单，redis官方有详细的介绍，具体如下

这样，即使因为网络抖动，del操作失败，还是有过期时间来保证不会造成死锁。当然，del释放锁操作我们还是要注意两点：1、加锁的value使用线程独有的值；2、使用lua脚本进行del。避免被别的线程将锁释放，造成锁失效的问题。

到这，是不是我们关于redis锁的问题就解决完了？还没有，目前来说，我们都没有关注到redis服务本身上，我们接着往下看。

假设我们的redis是单机，好吧，单机就是个问题，如果redis服务挂了呢，这个锁的实现就出现了问题。

好，那来看看redis主从模式有没有问题，使用主从模式就能避免redis主服务挂了之后造成的单点故障。但是，仔细看redis官方文档

注意红圈圈住的部分，使用redis主从模式并不可靠，因为redis主从的复制是异步的。

好的，接下来，我们看看redis主从复制的实现方式，为什么会造成这种方式实现锁不可靠。主从复制。

从文档中我们看到，redis主从同步默认使用异步模式，如下图

1. ClientA请求redis master，redis master操作后返回成功，因为异步同步到slave，此时还没有将数据同步到redis slave。
2. 在同步到redis slave之前，redis master挂掉了，redis slave中并没有刚刚Client A写入的数据。
3. 此时，redis slave切换成master，Client B请求新的master也就是原来的redis slave，成功。

好吧，这个锁服务还是不可靠。

（具体redis主从复制的细节可以看redis哨兵及集群相关的官方文档）

正因为这个原因，redis的做着提出了RedLock的实现方式，来提高redis锁的可靠性，接下来一起看看什么是RedLock。

假设有多个redis master节点，这些节点是完全独立的

1. clientA获取当前的系统时间(毫秒数)。
2. 使用同一个语句对所有的redis实例进行加锁操作，我们对加锁操作设置超时时间，这个时间要远远小于锁的失效时间。
3. clientA计算加锁消耗了多长时间（当前时间减去第一步获取的时间），只有当在大多数redis上操作成功，并且获取锁的时间小于锁的失效时间，我们认为获取锁成功。
4. 如果锁获取成功，则锁的有效时间为设置的时间减去加锁消耗的时间。
5. 如果锁没有获取成功，则要在所有的节点上操作解锁。

如下图：

我们看到，如果要使用RedLock，需要额外的部署多套redis服务，然后同时在这些服务上去获取锁，然后跟进获取锁的结果，来判断是否获取锁成功。是不是使用RedLock就解决了redis锁不可靠的问题呢？并不是，接着往下看。

Martin Kleppmann这个人，针对RedLock写了一篇文章，指出了RedLock存在的问题：

1. 如果应用发生了长时间的GC，这个GC时间超过了锁的有效时间，这个时候GC完成，接着去执行业务，但是此时，锁其实已经失效了。
2. 因为RedLock算法依赖于机器的时间，如果机器的时间发生了跳跃（比如人为的进行了修改），锁也将变得不可靠。
3. 同样的，长时间的IO等耗时操作，也会造成问题。

当然，redis作者针对Martin Kleppmann的文章也进行了反驳。大家可以搜一搜看看。

说到这里，不得不提一下CAP原则，CAP指的是Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），是说分布式系统只能同时满足这三个原则中的两个，Redis是基于AP模型的。所以如果对一致性有严格要求的系统，不能基于redis来使用redis锁。当然，如果对一致性要求不高，但是对高可用要求比较高的系统，可以选用redis，最最重要的，一定是根据自己的业务来选择合适的技术。