分布式锁概述

什么是分布式锁

分布式锁是一种在分布式计算环境中用于同步访问共享资源的机制。它的主要目的是在一个分布式系统中，当多个进程或服务需要同时访问同一个资源时，确保任一时刻只有一个进程或服务能够执行涉及该资源的关键操作。这类似于传统单体应用中的线程锁，但是分布式锁适用于多个独立的计算实体。

分布式锁的基础实现

举个例⼦: 考虑买票的场景, 现在⻋站提供了若⼲个⻋次, 每个⻋次的票数都是固定的.
现在存在多个服务器节点, 都可能需要处理这个买票的逻辑: 先查询指定⻋次的余票, 如果余票 > 0, 则设置余票值 -= 1.

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

此时, 如果 买票服务器1 尝试买票, 就需要先访问 Redis, 在 Redis 上设置⼀个键值对. ⽐如 key 就是⻋次, value 随便设置个值 (⽐如 1).
如果这个操作设置成功, 就视为当前没有节点对该 001 ⻋次加锁, 就可以进⾏数据库的读写操作. 操作完成之后, 再把 Redis 上刚才的这个键值对给删除掉.
如果在 买票服务器1 操作数据库的过程中, 买票服务器2 也想买票, 也会尝试给 Redis 上写⼀个键值对,key 同样是⻋次. 但是此时设置的时候发现该⻋次的 key 已经存在了, 则认为已经有其他服务器正在持有锁, 此时 服务器2 就需要等待或者暂时放弃.
当人这里也很多策略。

分布式锁的策略

引入setnx

Redis Setnx（SET if Not eXists） 命令在指定的 key 不存在时，为 key 设置指定的值。
我们可以使用setnx命令，可以实现加锁效果。
至于解锁，就可以用del命令来完成。

引⼊过期时间

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

引⼊校验 id

1.给服务器编号，每个服务器都有一个自己的身份表示。
2.进行加锁的时候，设置key-value。key对应的要针对哪个资源加锁，value就可以存储刚才的服务器的编号，标识出这个锁是哪个服务器加上的。
3.解锁的时候，先查询一下这个锁对应的服务器编号，然后判定一下这个编号是否就是执行解锁的服务器编号，才能真正的执行del，否则就是失败。

引⼊ lua

上述操作在解锁的时候，是先查询，再删除，这个过程不是原子的，存在两个线程都在解锁操作。
为了使解锁操作原⼦, 可以使⽤ Redis 的 Lua 脚本功能.

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

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

引入看门狗

上述⽅案仍然存在⼀个重要问题. 当我们设置了 key 过期时间之后 (⽐如 10s), 仍然存在⼀定的可能性,
当任务还没执⾏完, key 就先过期了. 这就导致锁提前失效.
把这个过期时间设置的⾜够⻓, ⽐如 30s, 是否能解决这个问题呢? 很明显, 设置多⻓时间合适, 是⽆⽌境的. 即使设置再⻓, 也不能完全保证就没有提前失效的情况.
⽽且如果设置的太⻓了, 万⼀对应的服务器挂了, 此时其他服务器也不能及时的获取到锁.

因此相⽐于设置⼀个固定的⻓时间, 不如动态的调整时间更合适.
所谓 watch dog, 本质上是加锁的服务器上的⼀个单独的线程, 通过这个线程来对锁过期时间进⾏ “续
约”.

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 还没有成功, 就视为加锁失败.