• 21.Redis之分布式锁


    1.什么是分布式锁

    • 在⼀个分布式的系统中, 也会涉及到多个节点访问同⼀个公共资源的情况. 此时就需要通过 锁 来做互斥控制, 避免出现类似于 "线程安全" 的问题.
    • ⽽ java 的 synchronized 或者 C++ 的 std::mutex, 这样的锁都是只能在当前进程中⽣效, 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了.
    • 此时就需要使⽤到分布式锁
    • 在分布式系统中,是有很多进程的(每个服务器,都是独立的进程)因此,之前的锁,就难以对现在分布式系统中的多个进程之间产生制约.....分布式系统中,多个进程之间的执行顺序也是不确定的 =>随机性
    • 引入"分布式锁"来解决上述问题
    • 不存在就设置
    • 存在就出错(失败)
    • setnx

    2.引入setnx

    3.引入过期时间

    • 当 服务器1 加锁之后, 开始处理买票的过程中, 如果 服务器1 意外宕机了, 就会导致解锁操作 (删除该 key) 不能执⾏. 就可能引起其他服务器始终⽆法获取到锁的情况
    • 为了解决这个问题, 可以在设置 key 的同时引⼊过期时间. 即这个锁最多持有多久, 就应该被释放.
    • 可以使⽤ set ex nx 的⽅式, 在设置锁的同时把过期时间设置进去
    • 注意! 此处的过期时间只能使⽤⼀个命令的⽅式设置.
    • 如果分开多个操作, ⽐如 setnx 之后, 再来⼀个单独的 expire, 由于 Redis 的多个指令之间不存在关
    • 联, 并且即使使⽤了事务也不能保证这两个操作都⼀定成功, 因此就可能出现 setnx 成功, 但是 expire失败的情况.
    • 此时仍然会出现⽆法正确释放锁的问题.

    4.引入校验id

    • 对于 Redis 中写⼊的加锁键值对, 其他的节点也是可以删除的.
    • ⽐如 服务器1 写⼊⼀个 "001": 1 这样的键值对, 服务器2 是完全可以把 "001" 给删除掉的.
    • 当然, 服务器2 不会进⾏这样的 "恶意删除" 操作, 不过不能保证因为⼀些 bug 导致 服务器2 把锁误删除.
    • 为了解决上述问题, 我们可以引⼊⼀个校验 id.
    • ⽐如可以把设置的键值对的值, 不再是简单的设为⼀个 1, ⽽是设成服务器的编号. 形如 "001": "服务器1".
    • 这样就可以在删除 key (解锁)的时候, 先校验当前删除 key 的服务器是否是当初加锁的服务器, 如果是, 才能真正删除; 不是, 则不能删除

    5.引入lua脚本

    • 为了使解锁操作原⼦, 可以使⽤ Redis 的 Lua 脚本功能
    • Lua 也是⼀个编程语⾔. 读作 "撸啊". 是葡萄⽛语中的 "⽉亮" 的意思. (出⾃于 Lua 官⽅⽂档 https://www.lua.org/about.html)
    • Lua 的语法类似于 JS, 是⼀个动态弱类型的语⾔. Lua 的解释器⼀般使⽤ C 语⾔实现. Lua 语法简单精炼, 执⾏速度快, 解释器也⽐较轻量(Lua 解释器的可执⾏程序体积只有 200KB 左右).
    • 因此 Lua 经常作为其他程序内部嵌⼊的脚本语⾔. Redis 本⾝就⽀持 Lua 作为内嵌脚本.
    • 很多程序都⽀持内嵌脚本, ⽐如 MySQL 8 ⽀持 JS 作为内嵌脚本, ⽐如 Vim ⽀持 VimScript 和 Python 作为内嵌脚本.... 通过内嵌脚本来实现更复杂的功能, 提供更强的扩展性.
      Lua 除了和 Redis 搭伙之外, 在很多场景也会作为内嵌脚本. ⽐如在游戏开发领域常常作为编写逻辑的语⾔. (⽐如魔兽世界, ⼤话西游等)
    • 使⽤ Lua 脚本完成上述解锁功能
      1. if redis.call('get',KEYS[1]) == ARGV[1] then
      2. return redis.call('del',KEYS[1])
      3. else
      4. return 0
      5. end;
      • 上述代码可以编写成⼀个 .lua 后缀的⽂件, 由 redis-cli 或者 redis-plus-plus 或者
      • jedis 等客⼾端加载, 并发送给 Redis 服务器, 由 Redis 服务器来执⾏这段逻辑.
      • ⼀个 lua 脚本会被 Redis 服务器以原⼦的⽅式来执⾏.

    6.引入看门狗(过期时间的续约问题)

    • 上述⽅案仍然存在⼀个重要问题. 当我们设置了 key 过期时间之后 (⽐如 10s), 仍然存在⼀定的可能性, 当任务还没执⾏完, key 就先过期了. 这就导致锁提前失效.
    • 把这个过期时间设置的⾜够⻓, ⽐如 30s, 是否能解决这个问题呢? 很明显, 设置多⻓时间合适, 是⽆⽌境的.
    • 即使设置再⻓, 也不能完全保证就没有提前失效的情况.
    • ⽽且如果设置的太⻓了, 万⼀对应的服务器挂了, 此时其他服务器也不能及时的获取到锁.
    • 因此相⽐于设置⼀个固定的⻓时间, 不如动态的调整时间更合适
    • 所谓 watch dog, 本质上是加锁的服务器上的⼀个单独的线程, 通过这个线程来对锁过期时间进⾏ "续约".
      注意, 这个线程是业务服务器上的, 不是 Redis 服务器的.
      举个具体的例⼦:
      初始情况下设置过期时间为 10s. 同时设定看⻔狗线程每隔 3s 检测⼀次.
      那么当 3s 时间到的时候, 看⻔狗就会判定当前任务是否完成.
      如果任务已经完成, 则直接通过 lua 脚本的⽅式, 释放锁(删除 key).
      如果任务未完成, 则把过期时间重写设置为 10s. (即 "续约")
    • 这样就不担⼼锁提前失效的问题了. ⽽且另⼀⽅⾯, 如果该服务器挂了, 看⻔狗线程也就随之挂了, 此时⽆⼈续约, 这个 key ⾃然就可以迅速过期, 让其他服务器能够获取到锁了

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

  • 相关阅读:
    【Golang之路】——slice总结
    微软不再允许Windows 11通过1@1.com绕过登录 但还有其他办法可以继续用
    计数排序(Counting Sort)
    火山引擎 ByteHouse:如何提升 18000 节点的 ClickHouse 可用性?
    Docker - 镜像
    codeforces:F. Kirei and the Linear Function【暴力优化 + 避开大数运算 + 避开str切片转int】
    迎战秋招计划
    FFmpeg开发笔记(二十二)FFmpeg中SAR与DAR的显示宽高比
    nfs 网络文件系统
    【计算机网络】交换机工作原理
  • 原文地址:https://blog.csdn.net/m0_47017197/article/details/139361283