• Redis 分布式锁


    与分布式锁相对应的是「单机锁」,我们在写多线程程序时,避免同时操作一个共享变量产生数据问题,通常会使用一把锁来「互斥」,以保证共享变量的正确性,其使用范围是在「同一个进程」中。

    想要实现分布式锁,必须借助一个外部系统,所有进程都去这个系统上申请「加锁」。

    而这个外部系统,必须要实现「互斥」的能力,即两个请求同时进来,只会给一个进程返回成功,另一个返回失败(或等待)。

    这个外部系统,可以是 MySQL,也可以是 Redis 或 Zookeeper。但为了追求更好的性能,我们通常会选择使用 Redis 或 Zookeeper 来做。

     

    想要实现分布式锁,必须要求 Redis 有「互斥」的能力,我们可以使用 SETNX 命令,这个命令表示SET if Not eXists,即如果 key 不存在,才会设置它的值,否则什么也不做。

    两个客户端进程可以执行这个命令,达到互斥,就可以实现一个分布式锁。

    客户端 1 申请加锁,加锁成功===========>127.0.0.1:6379> SETNX lock 1
                                                                            (integer) 1     // 客户端1,加锁成功

    操作完成后,还要及时释放锁,给后来者让出操作共享资源的机会。========>127.0.0.1:6379> DEL lock // 释放锁
                                                                                                                                   (integer) 1

     

    它存在一个很大的问题,当客户端 1 拿到锁后,如果发生下面的场景,就会造成「死锁」:

    1. 程序处理业务逻辑异常,没及时释放锁
    2. 进程挂了,没机会释放锁

    这时,这个客户端就会一直占用这个锁,而其它客户端就「永远」拿不到这把锁了

     

    避免死锁

    在 Redis 中实现时,就是给这个 key 设置一个「过期时间」

    127.0.0.1:6379> SETNX lock 1    // 加锁
    (integer) 1
    127.0.0.1:6379> EXPIRE lock 10  // 10s后自动过期
    (integer) 1

    // 一条命令保证原子性执行
    127.0.0.1:6379> SET lock 1 EX 10 NX

    锁被别人释放

    客户端在加锁时,设置一个只有自己知道的「唯一标识」进去。

    // 锁的VALUE设置为UUID
    127.0.0.1:6379> SET lock $uuid EX 20 NX
    OK

    在释放锁时,要先判断这把锁是否还归自己持有

    // 锁是自己的,才释放
    if redis.get("lock") == $uuid:
        redis.del("lock")

  • 相关阅读:
    MD5
    第一阶段冲刺(十)
    团队作业进度报告
    第一阶段冲刺(九)
    团队作业进度报告
    第一阶段冲刺(八)
    第一阶段冲刺(七)
    团队作业进度报告
    第一阶段冲刺(六)
    团队作业进度报告
  • 原文地址:https://www.cnblogs.com/KL2016/p/14898207.html
Copyright © 2020-2023  润新知