什么是分布式锁?
分布式系统下, 会涉及到多个 进程 同时访问同一个公共资源的情况, 此时就需要通过 锁 来做互斥操作, 这个锁就被称为 分布式锁
分布式锁的本质: 使用 一个或一组服务器 来记录 加锁状态
以 Redis 做分布式锁为例:
- 把 Redis 中存储的 一个键值对, 当作 锁.
- 当其他进程使用公共资源前, 都需要尝试往Redis 中存储该键值对, 视为 加锁操作 , 如果该键值对已存在, 则加锁失败, 不能使用公共资源
- 当占用公共资源的进程结束使用后, 由该进程把 Redis 中的 “锁” 删除掉, 视为 解锁操作
Redis 可用作分布式锁的原因 :
- 单线程模型, 同一时刻只能由一个进程的一个线程进行加锁和解锁操作
- 加锁 :
setnx不存在就设置, 存在就设置失败- 解锁 :
del
设置过期时间 (set ex nx)
error : 加锁后, 还未解锁, 该进程就挂了 (相当于锁资源不会再被释放了 …)
tips : 此处只能使用 set ex nx , 而不能使用多个命令 setnx + expire (两个命令如果有一个没有执行成功, 就会出现不符合预期的情况)
设置校验 Id
error : 服务器 A 加锁, 但是服务器 B 进行了误操作, 给解锁了 (Redis 中锁就是一个键值对, 理论上谁都能删除)
solve :
- 给每个服务器加唯一的身份标识
- 作为锁的键值对中, value 值存储加锁对象的 身份标识
- 每次解锁前进行校验是否是你给我加的锁
- 校验成功就解锁, 校验失败则解锁失败
事务 / lua 脚本
error : 解锁过程中的原子性问题
以上图为例, 原本一个进程中有两个线程尝试进行解锁, 因为 进程是同一个, 因此都可以进行解锁, 并且第二次解锁虽然不成功但是不会产生其他影响
如果在两次 del 之间有其他进程尝试加锁, 由于第一个进程已解锁, 所以加锁进行可以通过校验并成功加锁, 但是第二次解锁操作会让中间进程的加锁操作无效掉
Redis 事务保证在事务执行过程中, 不会有其他进程命令的 插队
Redis 服务器以原子的方式来执行 lua 脚本 (即使该脚本中存在多条命令)
因此可以解决上述问题
看门口 “watch dog”
error : 针对过期时间设置过长 (过期时间设定太长了,导致占用公共资源进程早就使用完毕, 但是公共资源还是没有被释放) 或者 锁提前失效 (业务提前结束)
solve : 引入看门狗思想, 用 业务服务器上的 一个线程对 “锁” 进行持续 续约
eg:
- 锁的初始过期时间设置为 1s , 当还剩余 300ms 时, 重新设置过期时间为 1s …
- 当该进程使用公共资源完毕时, 看门口就不再给 锁 续时间, 锁就会很快被释放掉
- 当业务服务器挂了, 看门狗线程也就不存在了, 也就不会继续续约, 公共资源很快就会被释放
redlock 算法 – 引入冗余
error : 当一个进程给 master 加锁成功, 但是 master 还未同步给它的 slave 时, master 就挂了, 经过哨兵的重建主从结构后, 该结构会认为, 我此时处于 无锁 状态
solve : 每次加锁不是针对一个 Redis 对象, 而是针对一组 redis master 对象加锁, 当加锁成功个数大于总数的一半, 我们就认为本次加锁成功, 解锁时对所有 master 进行解锁.
