redis分布式锁

1.什么是分布式锁

在一个分布式的系统中，也会涉及到多个节点访问同一个公共资源的情况.此时就需要通过锁来做互斥控制，避免出现类似于"线程安全"的问题.
而java的synchronized或者C++的std::mutex,这样的锁都是只能在当前进程中生效,在分布式的这
种多个进程多个主机的场景下就无能为力了.
此时就需要使用到分布式锁.

本质上就是使用一个公共的服务器，来记录加锁状态.
这个公共的服务器可以是Redis,也可以是其他组件(比如MySQL或者ZooKeeper等)，还可以是我们自己写的一个服务.

2.分布式锁的基础实现

思路非常简单.本质上就是通过一个键值对来标识锁的状态.
举个例子:考虑买票的场景,现在车站提供了若干个车次，每个车次的票数都是固定的.
现在存在多个服务器节点,都可能需要处理这个买票的逻辑:先查询指定车次的余票,如果余票>0,则设置余票值-= 1.

显然上述的场景是存在"线程安全"问题的,需要使用锁来控制.
否则就可能出现"超卖"的情况.
此时如何进行加锁呢?我们可以在上述架构中引入一个Redis ,作为分布式锁的管理器.

此时，如果买票服务器1尝试买票,就需要先访问Redis,在Redis.上设置一个键值对. 比如key就是车
次, value随便设置个值(比如1).
如果这个操作设置成功，就视为当前没有节点对该001车次加锁,就可以进行数据库的读写操作.操作完成之后,再把Redis 上刚才的这个键值对给删除掉.
如果在买票服务器1操作数据库的过程中，买票服务器2也想买票，也会尝试给Redis上写一个键值对,key同样是车次.但是此时设置的时候发现该车次的key已经存在了,则认为已经有其他服务器正在持有锁，此时服务器2就需要等待或者暂时放弃.
Redis中提供了setnx操作，正好适合这个场景.即: key不存在就设置,存在则直接失败.

3.引入过期时间

当服务器1加锁之后，开始处理买票的过程中，如果服务器1意外宕机了,就会导致解锁操作(删除该
key)不能执行.就可能弓|起其他服务器始终无法获取到锁的情况.
为了解决这个问题,可以在设置key的同时引入过期时间.即这个锁最多持有多久,就应该被释放.
可以使用 set ex nx的方式，在设置锁的同时把过期时间设置进去.

注意!此处的过期时间只能使用一个命令的方式设置.
如果分开多个操作，比如setnx之后，再来一个单独的expire,由于Redis的多个指令之间不存在关
联,并且即使使用了事务也不能保证这两个操作都一定成功,因此就可能出现setnx成功,但是expire
失败的情况.
此时仍然会出现无法正确释放锁的问题.

4.引入校验id

对于Redis中写入的加锁键值对，其他的节点也是可以删除的.
比如服务器1写入一个"001": 1这样的键值对，服务器2是完全可以把"001"给删除掉的.
当然，服务器2不会进行这样的"恶意删除"操作,不过不能保证因为一些bug导致服务器2把锁误删
为了解决上述问题,我们可以引入-个校验id.
比如可以把设置的键值对的值,不再是简单的设为一个1,而是设成服务器的编号.形如"001":"服务器1".
这样就可以在删除key(解锁)的时候，先校验当前删除key的服务器是否是当初加锁的服务器，如果是,才能真正删除;不是,则不能删除.

逻辑用伪代码描述如下:

String key = [要加锁的资源 id];
String serverId = [服务器的编号];
// 加锁, 设置过期时间为 10s
redis.set(key, serverId, "NX", "EX", "10s");
// 执⾏各种业务逻辑, ⽐如修改数据库数据.
doSomeThing();
// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配.
if (redis.get(key) == serverId) {
redis.del(key);
}

但是很明显，解锁逻辑是两步操作"get"和"del",这样做并非是原子的.

5.引入lua

为了使解锁操作原子，可以使用Redis的Lua脚本功能.

Lua也是一个编程语言.读作"撸啊".是葡萄牙语中的"月亮"的意思. (出自于Lua官方文档
https://www.lua.org/about.html)
Lua的语法类似于JS,是一个动态弱类型的语言. Lua的解释器一般使用C语言实现. Lua语法
简单精炼，执行速度快，解释器也比较轻量(Lua解释器的可执行程序体积只有200KB左右).
因此Lua经常作为其他程序内部嵌入的脚本语言. Redis本身就支持Lua作为内嵌脚本.
很多程序都支持内嵌脚本，比如MySQL 8支持JS作为内嵌脚本，比如Vim支持VimScript
和Python作为内嵌脚...通过内嵌脚本来实现更复杂的功能，提供更强的扩展性.
Lua除了和Redis搭伙之外，在很多场景也会作为内嵌脚本.比如在游戏开发领域常常作为
编写逻辑的语言. (比如魔兽世界，大话西游等)

使用Lua脚本完成上述解锁功能

if redis.call('get',KEYS[1]) == ARGV[1] then
    return redis.call('del',KEYS[1])
else
    return 0
end;

上述代码可以编写成一-个.lua后缀的文件,由redis-cli或者redis-plus-plus 或者
jedis 等客户端加载,并发送给Redis服务器,由Redis服务器来执行这段逻辑.
一个lua脚本会被Redis服务器以原子的方式来执行.

6.引入watch dog (看门狗)

上述方案仍然存在一个重要问题.当我们设置了key过期时间之后(比如10s),仍然存在一-定的可 能性,当任务还没执行完，key就先过期了.这就导致锁提前失效.
把这个过期时间设置的足够长,比如30s,是否能解决这个问题呢?很明显，设置多长时间合适，是无止境的.即使设置再长,也不能完全保证就没有提前失效的情况.
而且如果设置的太长了,万一对应的服务器挂了,此时其他服务器也不能及时的获取到锁.
因此相比于设置一个固定的长时间,不如动态的调整时间更合适.
所谓watch dog,本质上是加锁的服务器.上的一个单独的线程，通过这个线程来对锁过期时间进行"续约".
注意,这个线程是业务服务器上的,不是Redis服务器的.

初始情况下设置过期时间为10s.同时设定看个门]狗线程每隔3s检测一次.
那么当3s时间到的时候，看i门狗就会判定当前任务是否完成.
●如果任务已经完成，则直接通过lua脚本的方式，释放锁(删除key).
●如果任务未完成，则把过期时间重写设置为10s. (即"续约")

这样就不担心锁提前失效的问题了.而且另一方面，如果该服务器挂了，看门]狗线程也就随之挂了,此时无人续约,这个key自然就可以迅速过期,让其他服务器能够获取到锁了.

7.引入Redlock算法

实践中的Redis 一般是以集群的方式部署的(至少是主从的形式，而不是单机).那么就可能出现以下比较极端的大冤种情况:
服务器1向master节点进行加锁操作. 这个写入key的过程刚刚完成， master挂了;slave 节点升级成了新的master节点.但是由于刚才写入的这个key尚未来得及同步给slave呢，此时就相当于服务器1的加锁操作形同虚设了,服务器2仍然可以进行加锁(即给新的master写
入key.因为新的master不包含刚才的key).
为了解决这个问题, Redis的作者提出了Redlock算法.

我们引入一组Redis节点.其中每一组Redis节点都包含一个主节点和若干从节点.并且组和组之间存
储的数据都是一致的, 相互之间是"备份"关系(而并非是数据集合的一部分, 这点有别于Redis cluster).
加锁的时候,按照一定的顺序，写多个master节点.在写锁的时候需要设定操作的"超时时间".比如
50ms.即如果setnx操作超过了50ms还没有成功,就视为加锁失败.

如果给某个节点加锁失败,就立即再尝试下一个节点.
当加锁成功的节点数超过总节点数的一半，才视为加锁成功.
如上图,一 共五个节点，三个加锁成功,两个失败,此时视为加锁成功.
这样的话,即使有某些节点挂了,也不影响锁的正确性.

同理,释放锁的时候,也需要把所有节点都进行解锁操作.(即使是之前超时的节点，也要尝试解锁，尽量保证逻辑严密).
简而言之, Redlock算法的核心就是,加锁操作不能只写给一-个Redis节点,而要写个多个!!分布式系统中任何一个节点都是不可靠的.最终的加锁成功结论是"少数服从多数的".
由于一个分布式系统不至于大部分节点都同时出现故障,因此这样的可靠性要比单个节点来说靠谱不少.