Redis (分布式锁)

什么是分布式锁?

分布式系统下, 会涉及到多个 进程 同时访问同一个公共资源的情况, 此时就需要通过 锁 来做互斥操作, 这个锁就被称为 分布式锁

分布式锁的本质: 使用 一个或一组服务器 来记录 加锁状态

以 Redis 做分布式锁为例:

• 把 Redis 中存储的 一个键值对, 当作 锁.
• 当其他进程使用公共资源前, 都需要尝试往 Redis 中存储该键值对, 视为 加锁操作 , 如果该键值对已存在, 则加锁失败, 不能使用公共资源
• 当占用公共资源的进程结束使用后, 由该进程把 Redis 中的 “锁” 删除掉, 视为 解锁操作

Redis 可用作分布式锁的原因 :

1. 单线程模型, 同一时刻只能由一个进程的一个线程进行加锁和解锁操作
2. 加锁 : setnx 不存在就设置, 存在就设置失败
3. 解锁 : del

---

设置过期时间 (set ex nx)

error : 加锁后, 还未解锁, 该进程就挂了 (相当于锁资源不会再被释放了 …)
tips : 此处只能使用 set ex nx , 而不能使用多个命令 setnx + expire (两个命令如果有一个没有执行成功, 就会出现不符合预期的情况)

---

设置校验 Id

error : 服务器 A 加锁, 但是服务器 B 进行了误操作, 给解锁了 (Redis 中锁就是一个键值对, 理论上谁都能删除)
solve :

1. 给每个服务器加唯一的身份标识
2. 作为锁的键值对中, value 值存储加锁对象的 身份标识
3. 每次解锁前进行校验是否是你给我加的锁
4. 校验成功就解锁, 校验失败则解锁失败

---

事务 / lua 脚本

error : 解锁过程中的原子性问题

以上图为例, 原本一个进程中有两个线程尝试进行解锁, 因为 进程是同一个, 因此都可以进行解锁, 并且第二次解锁虽然不成功但是不会产生其他影响
如果在两次 del 之间有其他进程尝试加锁, 由于第一个进程已解锁, 所以加锁进行可以通过校验并成功加锁, 但是第二次解锁操作会让中间进程的加锁操作无效掉

Redis 事务保证在事务执行过程中, 不会有其他进程命令的 插队
Redis 服务器以原子的方式来执行 lua 脚本 (即使该脚本中存在多条命令)
因此可以解决上述问题

---

看门口 “watch dog”

error : 针对过期时间设置过长 (过期时间设定太长了,导致占用公共资源进程早就使用完毕, 但是公共资源还是没有被释放) 或者 锁提前失效 (业务提前结束)
solve : 引入看门狗思想, 用 业务服务器上的 一个线程对 “锁” 进行持续 续约

eg:

• 锁的初始过期时间设置为 1s , 当还剩余 300ms 时, 重新设置过期时间为 1s …
• 1. 当该进程使用公共资源完毕时, 看门口就不再给 锁 续时间, 锁就会很快被释放掉
• 2. 当业务服务器挂了, 看门狗线程也就不存在了, 也就不会继续续约, 公共资源很快就会被释放

---

redlock 算法 – 引入冗余

error : 当一个进程给 master 加锁成功, 但是 master 还未同步给它的 slave 时, master 就挂了, 经过哨兵的重建主从结构后, 该结构会认为, 我此时处于 无锁 状态
solve : 每次加锁不是针对一个 Redis 对象, 而是针对一组 redis master 对象加锁, 当加锁成功个数大于总数的一半, 我们就认为本次加锁成功, 解锁时对所有 master 进行解锁.