Redis的分布式锁

分布式锁为何可以用Redis实现？

我们都已经知道redis可以被称为经典的key-value数据库，而在分布式系统中，当有多个客户端需要获取锁时，我们需要分布式锁。此时，锁是保存在一个共享存储系统中的，可以被多个客户端共享访问和获取。同时Redis 本身可以被多个客户端共享访问，正好就是一个共享存储系统，可以用来保存分布式锁。而且 Redis 的读写性能高，可以应对高并发的锁操作场景。

我们所说的分布式锁到底是什么？

锁其实就是变量，变量名我们可以自己定义，而变量的值就是锁的状态，比如0代表没有线程获取到锁，而1代表线程获取到了锁。不过不一定一定要用0和1标识，这样可能会出现错误，比如客户端A加锁后，假设客户端 B 执行了 DEL 命令释放锁，此时，客户端 A 的锁就被误释放了。如果客户端 C 正好也在申请加锁，就可以成功获得锁，进而开始操作共享数据。这样一来，客户端 A 和 C 同时在对共享数据进行操作，数据就会被修改错误，这也是不能接受的。所以可以将锁的value，设置为自身客户端的标识。同时给与锁设置过期时间，以免客户端在这期间发生异常而无法释放锁

如何实现分布式锁

单机版分布式锁

分布式场景下，锁变量需要由一个共享存储系统来维护，而我们获取锁的过程在面的并发的情况下，需要分为下面几个步骤。
1：读取锁
2：判断锁状态
3：设置锁变量的值
4：执行操作
5: 删除锁变量
这三个操作可以由setnx这一个命令来执行，键不存在，则设置。因为没有支持释放锁（读锁，判断客户端，删除）的原子命令，所以需要利用lua脚本实现。
而为了保证线程获取锁的安全性与正确性保证，需要有下面一些要求：
1：分布式锁的加锁和释放锁的过程，涉及多个操作。所以，在实现分布式锁时，我们需要保证这些锁操作的原子性
2：实现分布式锁时，我们需要考虑保证共享存储系统的可靠性，进而保证锁的可用性。

基于多个redis节点实现分布式锁：

当我们要实现高可靠的分布式锁时，就不能只依赖单个的命令操作了（单机实现分布式锁因为命令由主线程串行执行，所以不会有并发的问题），我们需要按照一定的步骤和规则进行加解锁操作。
为了避免 Redis 实例故障而导致的锁无法工作的问题，Redis提出了分布式锁算法 Redlock。
Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败。这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失.

加锁操作：

1：客户端获取当前时间。
2：客户端按顺序依次向 N 个 Redis 实例执行加锁操作。
执行SETNX，EX/PX（超时） 选项，带上客户端的唯一标识。当然，如果某个 Redis 实例发生故障了，为了保证在这种情况下，Redlock 算法能够继续运行，我们需要给加锁操作设置一个超时时间。如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间。
3：一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。客户端只有在满足下面的这两个条件时，才能认为是加锁成功。
3.1：客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；
3.2：客户端获取锁的总耗时没有超过锁的有效时间。
在满足了这两个条件后，就需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，我们可以释放锁，以免出现还没完成数据操作，锁就过期了的情况。
如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那么，客户端向所有 Redis 节点发起释放锁的操作。（这步操作是为了判断是否有足够有效的时间来进行操作）