redis - 分布式锁

在⼀个分布式的系统中， 也会涉及到多个节点访问同⼀个公共资源的情况。 此时就需要通过 锁 来做互斥 控制， 避免出现类似于 "线程安全" 的问题。

而 java 的 synchronized 或者 C++ 的 std::mutex， 这样的锁都是只能在当前进程 中生效， 在分布式的这 种多个进程多个主机的场景下就无能为力了。 此时就需要使用到分布式锁。

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

分布式锁基础实现

思路非常简单. 本质上就是通过⼀个键值对来标识锁的状态.

未加分布式锁之前，存在类似"线程安全"的问题。

客户端1先执行查询余票，发现剩余1张。在即将执行 1->0 过程之前，客户端2 也执行查询余票，发现，也是剩余 1张，客户端2 也会执行 1->0过程。就会出现超卖的情况

引入分布式锁。

往 redis 上设置一个特殊的 key -value，完成上述买票操作，再把这个key－value 删除掉。其他服务器也想买票的时候，也去redis上尝试设置key－value，如果发现key－value 已经存在,就认为"加锁失败"，(是放弃/阻塞，就看具体的实现策略了)。

使用setnx 确实可以得到"加锁"效果，针对于解锁，就可以使用del命令完成。

这里的买票场景，使用 mysql 的事务也可以批量执行 查询+修改操作但是分布式系统中，要访问的共享资源不一定是mysql ... 也可能是其他的存储介质并没有事务，也可能是执行一段特定的操作，是通过统一的服务器完成执行动作。

引入过期时间

当 服务器1 加锁之后， 开始处理买票的过程中， 如果 服务器1 意外宕机了， 就会导致解锁操作 (删除该 key) 不能执行。 就可能引起其他服务器始终无法获取到锁的情况。

为了解决这个问题， 可以在设置 key 的同时引⼊过期时间。 即这个锁最多持有多久， 就应该被释放。

可以使用 set ex nx 的方式, 在设置锁的同时把过期时间设置进去。

如果分开多个操作， 比如 setnx 之后， 再来⼀个单独的 expire， 由于 Redis 的多个指令之间不存在关 联， 并且即使使⽤了事务也不能保证这两个操作都⼀定成功， 因此就可能出现 setnx 成功， 但是 expire 失败的情况。 此时仍然会出现⽆法正确释放锁的问题。

引入校验id

对于 Redis 中写⼊的加锁键值对， 其他的节点也是可以删除的。⽐如 服务器1 写⼊⼀个 "001": 1 这样的键值对， 服务器2 是完全可以把 "001" 给删除掉的。 当然， 服务器2 不会进⾏这样的 "恶意删除" 操作， 不过不能保证因为⼀些 bug 导致 服务器2 把锁误删 除。

为了解决上述问题, 我们可以引⼊⼀个校验 id。

比如可以把设置的键值对的值， 不再是简单的设为⼀个 1， 而是设成服务器的编号。 形如 "001": "服务器1"。 这样就可以在删除 key (解锁)的时候， 先校验当前删除 key 的服务器是否是当初加锁的服务器， 如果是， 才能真正删除； 不是， 则不能删除。

引入lua

在解锁的时候，是先查询判定，再进行del。这是两步操作，不是原子的，就可能出现问题。服务器内部可能是多线程的，可能在服务器内部，两个线程都在执行上述解锁操作，而解锁操作又不是原子的，就会导致出错。

在线程 A 执行完 DEL 之后, B 执行 DEL 之前，服务器2 的线程C正好要执行 加锁(set），此时，由于A已经把锁释放了，C 的加锁是能够成功的！但是紧接着，线程 B DEL 就到来了.就把刚刚服务器 2 的加锁操作给解锁了。服务器1和服务器2 进行加锁，key是资源的编号（比如车次)，服务器的id 是value，因为在执行del之前执行了get完成了校验操作，所以执行就能del就能将服务器2新加的锁完成解锁。归根接地都是因为这里的get 和 del 操作， 不是原子操作。

使用事务，能解决上述问题。（redis事务虽然弱但是能够避免插队)，但是实践中往往使用的更好的方案.lua 脚本

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

lua 是一个编程语言，作为 redis 内嵌的脚本MySQL8支持js作为内嵌语言。Vim 支持使用 vimscript / python 作为内嵌语言。lua 语言特别轻量(实现一个 lua 解释器，消耗的体积是非常小的)。可以使用lua 编写一些逻辑，把这个脚本上传到redis服务器上。然后就可以让客户端来控制redis 执行上述脚本了。

redis 执行 lua 脚本的过程，也是原子 的。相当于执行一条命令一样（实际上lua中可以写多个命令），redis 官方文档，也明确说，lua 就属于是事务替代方案。

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

其中ARGV就是调用脚本的参数，这里就可以传入一个服务器的id。

引入watch dog（看门狗）

当我们设置了 key 过期时间之后 (比如 10s)， 仍然存在⼀定的可能性， 当任务还没执⾏完， key 就先过期了。 这就导致锁提前失效。

所谓 watch dog， 本质上是加锁的服务器上的⼀个单独的线程， 通过这个线程来对锁过期时间进行 "续 约"。

注意, 这个线程是业务服务器上的， 不是 Redis 服务器的。

举例说明

初始情况下设置过期时间为 10s， 同时设定看⻔狗线程每隔 3s 检测⼀次， 那么当 3s 时间到的时候, 看门狗就会判定当前任务是否完成。

• 如果任务已经完成， 则直接通过 lua 脚本的放松， 释放锁(删除 key)。

• 如果任务未完成， 则把过期时间重写设置为 10s。 (即 "续约")

引入Redlock算法

实践中的 Redis ⼀般是以集群的⽅式部署的 (⾄少是主从的形式， 而不是单机)。 那么就可能出现以下比 较极端的⼤冤种情况：

服务器1 向 master 节点进⾏加锁操作， 这个写⼊ key 的过程刚刚完成， master 挂了； slave 节 点升级成了新的 master 节点， 但是由于刚才写⼊的这个 key 尚未来得及同步给 slave，此时 就相当于 服务器1 的加锁操作形同虚设了， 服务器2 仍然可以进行加锁 （即给新的 master 写入 key， 因为新的 master 不包含刚才的 key）

为了解决这个问题, Redis 的作者提出了 Redlock 算法。

此处加锁,就是按照一定的顺序，针对这些组 redis 都进行加锁操作！！如果某个节点挂了(某个节点加不上锁，没关系，可能是redis 挂了)，继续给下一个节点加锁即可。如果写入key 成功的节点个数超过总数的一半，就视为 加锁成功。同理，进行解锁的时候，也就会把上述节点都设置一遍解锁。

简而言之， Redlock 算法的核⼼就是， 加锁操作不能只写给⼀个 Redis 节点， 而要写个多个！！ 分布式系统 中任何⼀个节点都是不可靠的， 最终的加锁成功结论是 "少数服从多数的"。 由于⼀个分布式系统不至于大部分节点都同时出现故障，因此这样的可靠性要比单个节点来说靠谱不 少。

分布式锁，只是一个简单的"互斥锁"

锁这里还涉及到一些其他情况

1、读写锁，保证读共享，写互斥的功能

2、公平锁，遵守先来后到的原则。普通锁，当第一个线程拿到锁，完成解锁之后，这把锁给后续哪个线程呢？随机的，主要看系统调度，这是一种非公平锁。而公平锁，维护每个线程加锁的先后顺序的一个队列，保证第一个线程释放锁后，一定是第二个到达的线程拿到锁

3、可重入锁，这对这把锁连续加两次，如果没事，就叫可重入锁。并且在锁内部持有当前是谁去进行的加锁，还需要有一个引用计数来记录当前锁是加了几次，没加一次就+1，每减一次就-1，减至0 的时候就真正释放锁。

基于Redis也能实现这些锁的机制，只不过会更复杂逻辑。