Redis分布式锁

什么是分布式锁？

分布式系统下，不同的服务/客户端通常运行在独立的 JVM 进程上。如果多个 JVM 进程共享同一份资源的话，使用本地锁就没办法实现资源的互斥访问了。于是，分布式锁 就诞生了。

在单体应用中我们通过锁解决的是控制共享资源访问的问题，而分布式锁，就是解决了分布式系统中控制共享资源访问的问题。与单体应用不同的是，分布式系统中竞争共享资源的最小粒度从线程升级成了进程。

分布式锁应该具备的条件

• 互斥：任意一个时刻，锁只能被一个线程持有。
• 高可用：锁服务是高可用的，当一个锁服务出现问题，能够自动切换到另外一个锁服务。
• 可重入：一个节点获取了锁之后，还可以再次获取锁。
• 具备锁失效机制：即使客户端的释放锁的代码逻辑出现问题，锁最终一定还是会被释放，即自动解锁，防止死锁
• 高性能：获取和释放锁的操作应该快速完成，并且不应该对整个系统的性能造成过大影响。
• 非阻塞：如果获取不到锁，不能无限期等待，避免对系统正常运行造成影响，即没有获取到锁将直接返回获取锁失败。

Redis 分布式锁

1、加锁：使用setnx进行加锁，当该指令返回1时，说明成功获得锁，并设置锁超时时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放。防止线程获取了锁之后，在执行任务的过程中挂掉，来不及显示地执行del命令释放锁，那么竞争该锁的线程都会执行不了，产生死锁的情况。

2、解锁：当得到锁的线程执行完任务之后，使用del命令释放锁，以便其他线程可以继续执行setnx命令来获得锁

（1）存在问题：

1. 假如线程A成功得到了锁，并且设置的超时时间是 30 秒。如果某些原因导致线程 A 执行的很慢，过了 30 秒都没执行完，这时候锁过期自动释放，线程 B 得到了锁。

2. 随后，线程A执行完任务，接着执行del指令来释放锁。但这时候线程 B 还没执行完，线程A实际上删除的是线程B加的锁。

（2）解决方案：

1. 让获得锁的线程开启一个守护线程，用来给快要过期的锁“续期”。

2. 可以在 del 释放锁之前做一个判断，验证当前的锁是不是自己加的锁。在加锁的时候把当前的线程 ID 当做value，并在删除之前验证 key 对应的 value 是不是自己线程的 ID。但是，get操作、判断和释放锁是不是原子操作。对于非原子性的问题，我们可以使用Lua脚本来确保操作的原子性

如果是在单redis实例的情况下，上面的已经完全实现了分布式锁的功能了。

Redisson 分布式锁

前面说了，如果某些原因导致持有锁的线程在锁过期时间内，还没执行完任务，而锁因为还没超时被自动释放了，那么就会导致多个线程同时持有锁的现象出现，而为了解决这个问题，可以进行“锁续期”。其实，在JAVA的Redisson包中有一个"看门狗"机制，已经帮我们实现了这个功能。

Redisson在获取锁之后，会维护一个看门狗线程，当锁即将过期时，不断的延长锁的生存时间。在每一个锁设置的过期时间的1/3处，如果线程还没执行完任务，则不断延长锁的有效期。看门狗的检查锁超时时间默认是30秒，可以通过 lockWactchdogTimeout 参数来改变。如果加锁的业务没有执行完，那么每隔 30 ÷ 3 = 10秒，就会进行一次续期，把锁重置成30秒，保证解锁前锁不会自动失效。

看门狗启动后，对整体性能也会有一定影响，默认情况下看门狗线程是不启动的。如果使用Redisson进行加锁的同时设置了锁的过期时间，也会导致看门狗机制失效。

如果宕机了，那看门狗线程就执行不了了，锁也会自动解开。

Redisson 也封装 可重入锁（Reentrant Lock）、公平锁（Fair Lock）、联锁（MultiLock）、红锁（RedLock）、读写锁（ReadWriteLock）、 信号量（Semaphore）、可过期性信号量（PermitExpirableSemaphore）、 闭锁（CountDownLatch）等，具体使用说明可以参考官方文档：Redisson的分布式锁和同步器

Redis 集群下的分布式锁

为了避免单点故障，生产环境下的 Redis 服务通常是集群化部署的。

Redis 集群下，上面介绍到的分布式锁的实现会存在一些问题。由于 Redis 集群数据同步到各个节点时是异步的，如果在 Redis 主节点获取到锁后，在没有同步到其他节点时，Redis 主节点宕机了，此时新的 Redis 主节点依然可以获取锁，所以多个应用服务就可以同时获取到锁。

Redlock 算法的思想是让客户端向 Redis 集群中的多个独立的 Redis 实例依次请求申请加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁，否则加锁失败。

即使部分 Redis 节点出现问题，只要保证 Redis 集群中有半数以上的 Redis 节点可用，分布式锁服务就是正常的。

Redlock 是直接操作 Redis 节点的，并不是通过 Redis 集群操作的，这样才可以避免 Redis 集群主从切换导致的锁丢失问题。

Redlock 实现比较复杂，性能比较差，发生时钟变迁的情况下还存在安全性隐患。如果在集群情况下有锁丢失的情况，可以在业务上做好兜底操作就可以了，毕竟集群情况下主从切换的场景还是极少的，没有必要为了极少的情况去浪费大量的性能。而且RedLock也是避免不了NPC问题的，依然需要在业务上兜底。实际项目中不建议使用 Redlock 算法，成本和收益不成正比。

如果不是非要实现绝对可靠的分布式锁的话，其实单机版 Redis 就完全够了，实现简单，性能也非常高。如果你必须要实现一个绝对可靠的分布式锁的话，可以基于 ZooKeeper 来做，只是性能会差一些。

如果使用 Redis 来实现分布式锁的话，还是比较推荐直接基于 Redisson 来做的。

至于具体选择 Redis 还是 ZooKeeper 来实现分布式锁，还是要看业务的具体需求。如果对性能要求比较高的话，建议使用 Redis 实现分布式锁。如果对可靠性要求比较高的话，建议使用 ZooKeeper 实现分布式锁。