Redis分布式锁
“孤独被染上童话底色~”
我们谈到“锁”这个概念，你一定会想到这一定是涉及到了线程安全的问题。当一个进程内的不同线程，需要访问同一资源（共享资源）时，如果进行不加锁，就会出现线程安全的问题。在分布式系统中，每个进程都是独立运行于一台独立的机器中的，当它们对共享资源进行访问时，如果不进行限制，也会出现类似的安全问题。但，之前的，仅仅运用于进程内的锁，不会再起任何作用，其次，分布式系统中多个进程间的执行顺序也具有不确定性。
——前言
什么是分布式锁
在分布式系统中，涉及到的多个节点访问共享资源的问题时，也需要“锁” 来做互斥控制，避免类似“线程”安全的问题。但在分布式系统中使用的不再是普通的锁机制，诸如：java 的 synchronized 或者 C++ 的 std::mutex等。这样的锁都是只能在当前进程中⽣效, 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了.
本质上就是使⽤⼀个公共的服务器, 来记录 加锁状态。
这个公共的服务器可以是Redis，可以是Mysql、ZooKeeper等组件，还可以 是我们⾃⼰写的⼀个服务。
分布式锁的实现
本标题同Redis相关，所以咱们使用的公共服务器基于Redis实现。本质上的思路十分简单，就是利用Redis内部的键值对，来识别锁的信息。
(1) 加\解锁
当我们引入分布式锁之后：
设置键值对的逻辑是，不存在就设置，存在就设置失败。
这同Redis中的一个命令十分契合：setnx
使用setnx确实可以得到一种“加锁”的效果，如果想要解锁，就使用Redis中的DEL命令。
(2) 设置过期时间
如果某个服务器完成了setnx，实现了加锁的效果。但突然，该服务器断电，程序崩溃了！也就是说，现目前该服务器无法将这键值对删除，解除对资源的占用，那么其他服务器就无法得到锁。
所以，正常情况下会给key设置过期时间，一旦时间到了，就会被自动删除掉。
我们可以使用例如： set nx ex的命令完成设置。注意，这是一条命令！如果是使用 setnx expire的方式，就算Redis是原子的，它仅仅是保证该命令被执行，至于命令执行正确与否，它是压根不关心的。不同于，Mysql事务翻滚、回溯。
(3) 校验机制
所谓的加锁，就是在公共Redis器中设置键值对，所谓解锁就是在这个Redis上将这个键值对删除。
那有没有一种可能，换句话说失误，服务器1设置的键值对，会被服务器2删除呢 ？答案是肯定的！因为压根没有任何身份标识，到底是谁设置的这个键值对。
所以，为了解决这个问题，一般会引入校验机制。我们可以在键值对的Value设置编号，每一个服务器都有一个编号，设置键值对的时候就将自己的编号写入Value中。
一旦Redis检测到DEL命令时，首先就需要判断发起该操作的服务器id，是否同键值对设置时，填入的Value一致。如果是，才会真正执行，不是就会失败。
(4) 原子性
即：在服务器1中的线程A执行DEL后，线程B执行DEL前，加入一个新的服务器2执行加锁操作，此时因为线程A已经把锁释放了，所以新服务器2加锁是成功的。但紧接着，线程B又执行DEL操作，把服务器2的加锁给释放了。
引入lua脚本
归根到底，出现这个问题的原因就在于GET、DEL不是原子性的，中间被“插队”了。解决这个问题的方法很多：比如说Redis自身提供的事务。但在实际中往往会采用使用lua脚本，这更好的方案。
lua是一个编程语言，作为Redis中内嵌的语言。
使用lua编写的脚本传递到Redis服务器上，可以通过客户端来控制Redis执行该脚本。Redis执行lua脚本的过程，是原子的。就相当于把lua中的所有命令当成一条命令。 下面是一份伪代码：
# 获取KEYS[1]Value
if redis.call('get',KEYS[1]) == ARGV[1] then
return redis.call('del',KEYS[1]) # 执行删除
else
return 0
end;(5) 看门狗机制
在上述方案中，我们给Key设置了一个过期时间。当时间超过设定时间时，即便服务器自身不对该Key进行释放，redis也会对这个键值对进行删除。
但有时也存在一定的可能，当前 任务可能还没有执行完，key 就先过期了。这就导致锁提前失效。所以到底设置多长的时间，作为过期时间是值得考虑的。所以，更好的方式是“动态续约”，初始情况是一个值，根据任务完成度，会在这个值的基础上延长过期时间。
即watch dog, 本质上是加锁的服务器上的⼀个单独的线程, 通过这个线程来对锁过期时间进⾏ "续约"。这是一个广义的概念，在很多场景，针对过期问题都会引入看门狗机制。注意, 这个线程是业务服务器上的, 不是 Redis 服务器的.
(6) 引⼊ Redlock 算法
实践中的 Redis ⼀般是以集群的⽅式部署的 (⾄少是主从的形式, ⽽不是单机). 那么就可能出现以下⽐较极端的⼤冤种情况：
服务器1 向 master 节点进⾏加锁操作. 这个写⼊ key 的过程刚刚完成, master 挂了；
slave 节 点升级成了新的 master 节点. 但是由于刚才写⼊的这个 key 尚未来得及同步给 slave 呢, 此时 就相当于 服务器1 的加锁操作形同虚设了。
为了解决这个问题, Redis 的作者提出了 Redlock 算法：
如果给某个节点加锁失败, 就⽴即再尝试下⼀个节点。当加锁成功的节点数超过总节点数的⼀半, 才视为加锁成功。
所以，当一个Master节点挂了，并且没有将新到的数据同步给从节点时，也不会影响加锁的正确性了。
同理, 释放锁的时候, 也需要把所有节点都进⾏解锁操作。这种“少数服从多数”的策略操作的思想，也同哨兵机制选取leader，集群选取新的主节点相似。
实际开发中, 我们也并不会真的⾃⼰实现⼀个分布式锁. 已经有很多现成的库帮我们封装好了, 我们直接 使⽤即可：⽐如 Java 中的 Redisson, C++ 中的 redis-plus-plus. 当然, 有些⼤⼚也会有⾃⼰版本的分布式锁的实现。
当然以上仅仅是例举了分布式锁的一些实现特性，实际中分布式锁需要考虑的问题复杂、繁多。此处我们不做过多讨论了。
小结：
① 什么时分布式锁？
② 分布式锁的一些特性：如何加\解锁？ 设置过期时间、校验机制、原子性（lua脚本）、看门狗、Redlock算法
本篇到此结束，感谢你的阅读。
祝你好运，向阳而生~
