【Redis】Redis典型应用-分布式锁

目录

什么是分布式锁?

分布式锁的基础实现

引入过期事件

引入校验ID

引入lua

[引入watch dog(看门狗)](#引入watch dog(看门狗))

[引⼊ Redlock 算法](#引⼊ Redlock 算法)


什么是分布式锁?

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

⽽C++ 的 std::mutex, 这样的锁针对的是当前进程中的多个线程, 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了.此时就需要使⽤到分布式锁.

本质上就是使⽤⼀个公共的服务器, 来记录 加锁状态.

这个公共的服务器可以是 Redis, 也可以是其他组件(⽐如 MySQL 或者 ZooKeeper 等), 还可以

是我们⾃⼰写的⼀个服务.

分布式锁的基础实现

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

举个例⼦: 考虑买票的场景, 现在⻋站提供了若⼲个⻋次, 每个⻋次的票数都是固定的.

现在存在多个服务器节点, 都可能需要处理这个买票的逻辑: 先查询指定⻋次的余票, 如果余票 > 0, 则设置余票值 -= 1.

显然上述的场景是存在 "线程安全" 问题的, 需要使⽤锁来控制.否则就可能出现 "超卖" 的情况.

此时如何进⾏加锁呢? 我们可以在上述架构中引⼊⼀个 Redis , 作为分布式锁的管理器.

此时, 如果 买票服务器1 尝试买票, 就需要先访问 Redis, 在 Redis 上设置⼀个键值对. ⽐如 key 就是⻋次, value 随便设置个值 (⽐如 1).

如果这个操作设置成功, 就视为当前没有节点对该 001 ⻋次加锁, 就可以进⾏数据库的读写操作. 操作完成之后, 再把 Redis 上刚才的这个键值对给删除掉.

如果在 买票服务器1 操作数据库的过程中, 买票服务器2 也想买票, 也会尝试给 Redis 上写⼀个键值对,key 同样是⻋次. 但是此时设置的时候发现该⻋次的 key 已经存在了, 则认为已经有其他服务器正在持有锁, 此时 服务器2 就需要等待或者暂时放弃.

Redis 中提供了 setnx 操作, 正好适合这个场景. 即: key 不存在就设置, 存在则直接失败.

引入过期事件

上述⽅案并不完整.

当 服务器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 的服务器是否是当初加锁的服务器, 如果是,才能真正删除; 不是, 则不能删除.想要获得校验ID和进行删除就要使用"get"和"del"这两个逻辑操作,但是很明显, 解锁逻辑是两步操作 "get" 和 "del", 这样做并⾮是原⼦的.

引入lua

为了使解锁操作原⼦, 可以使⽤ Redis 的 Lua 脚本功能.Lua 也是⼀个编程语⾔. 读作 "撸啊". 是葡萄⽛语中的 "⽉亮" 的意思. ⼀个 lua 脚本会被 Redis 服务器以原⼦的⽅式来执⾏.

引入watch dog(看门狗)

述⽅案仍然存在⼀个重要问题. 当我们设置了 key 过期时间之后 (⽐如 10s), 仍然存在⼀定的可能性,当任务还没执⾏完, key 就先过期了. 这就导致锁提前失效.

把这个过期时间设置的⾜够⻓, ⽐如 30s, 是否能解决这个问题呢? 很明显, 设置多⻓时间合适, 是⽆⽌

境的. 即使设置再⻓, 也不能完全保证就没有提前失效的情况.

⽽且如果设置的太⻓了, 万⼀对应的服务器挂了, 此时其他服务器也不能及时的获取到锁.

因此相⽐于设置⼀个固定的⻓时间, 不如动态的调整时间更合适.

所谓 watch dog, 本质上是加锁的服务器上的⼀个单独的线程, 通过这个线程来对锁过期时间进⾏ "续约".这个线程是业务服务器上的, 不是 Redis 服务器的.

初始情况下设置过期时间为 10s. 同时设定看⻔狗线程每隔 3s 检测⼀次.

那么当 3s 时间到的时候, 看⻔狗就会判定当前任务是否完成.

  • 如果任务已经完成, 则直接通过 lua 脚本的⽅式, 释放锁(删除 key).
  • 如果任务未完成, 则把过期时间重写设置为 10s. (即 "续约")

这样就不担⼼锁提前失效的问题了. ⽽且另⼀⽅⾯, 如果该服务器挂了, 看⻔狗线程也就随之挂了, 此时⽆⼈续约, 这个 key ⾃然就可以迅速过期, 让其他服务器能够获取到锁了.

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

如果给某个节点加锁失败, 就⽴即再尝试下⼀个节点.当加锁成功的节点数超过总节点数的⼀半, 才视为加锁成功.如上图, ⼀共五个节点, 三个加锁成功, 两个失败, 此时视为加锁成功.这样的话, 即使有某些节点挂了, 也不影响锁的正确性.

同理, 释放锁的时候, 也需要把所有节点都进⾏解锁操作. (即使是之前超时的节点, 也要尝试解锁, 尽量保证逻辑严密).

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


今天对Redis作为分布式锁的分享到这就结束了,希望大家读完后有很大的收获,也可以在评论区点评文章中的内容和分享自己的看法;个人主页还有很多精彩的内容。您三连的支持就是我前进的动力,感谢大家的支持!!!

相关推荐
秃头佛爷35 分钟前
Python学习大纲总结及注意事项
开发语言·python·学习
奶糖趣多多35 分钟前
Redis知识点
数据库·redis·缓存
CoderIsArt2 小时前
Redis的三种模式:主从模式,哨兵与集群模式
数据库·redis·缓存
dayouziei3 小时前
java的类加载机制的学习
java·学习
师太,答应老衲吧4 小时前
SQL实战训练之,力扣:2020. 无流量的帐户数(递归)
数据库·sql·leetcode
捕鲸叉4 小时前
创建线程时传递参数给线程
开发语言·c++·算法
A charmer4 小时前
【C++】vector 类深度解析:探索动态数组的奥秘
开发语言·c++·算法
Peter_chq4 小时前
【操作系统】基于环形队列的生产消费模型
linux·c语言·开发语言·c++·后端
P.H. Infinity5 小时前
【RabbitMQ】03-交换机
分布式·rabbitmq
Channing Lewis5 小时前
salesforce case可以新建一个roll up 字段,统计出这个case下的email数量吗
数据库·salesforce