Bendi新闻
>
Redission 分布式锁原理分析

Redission 分布式锁原理分析

7月前

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑,欢迎加入芋道快速开发平台知识星球。下面是星球提供的部分资料: 

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目,前端包括管理后台 + 微信小程序,后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能:

  • Boot 仓库:https://gitee.com/zhijiantianya/ruoyi-vue-pro
  • Cloud 仓库:https://gitee.com/zhijiantianya/yudao-cloud
  • 视频教程:https://doc.iocoder.cn
【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本 

来源:老周聊架构


一、前言

我们先来说说分布式锁,为啥要有分布式锁呢? 像 JDK 提供的 synchronized、Lock 等实现锁不香吗?这是因为在单进程情况下,多个线程访问同一资源,可以使用 synchronized 和 Lock 实现;在多进程情况下,也就是分布式情况,对同一资源的并发请求,需要使用分布式锁实现。而 Redisson 组件可以实现 Redis 的分布式锁,同样 Redisson 也是 Redis 官方推荐分布式锁实现方案,封装好了让用户实现分布式锁更加的方便与简洁。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/ruoyi-vue-pro
  • 视频教程:https://doc.iocoder.cn/video/

二、分布式锁的特性

  • 互斥性

    任意时刻,只能有一个客户端获取锁,不能同时有两个客户端获取到锁。

  • 同一性

    锁只能被持有该锁的客户端删除,不能由其它客户端删除。

  • 可重入性

    持有某个锁的客户端可继续对该锁加锁,实现锁的续租。

  • 容错性

    锁失效后(超过生命周期)自动释放锁(key失效),其他客户端可以继续获得该锁,防止死锁。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/yudao-cloud
  • 视频教程:https://doc.iocoder.cn/video/

三、Redisson 分布式锁原理

下面我们从加锁机制、锁互斥机制、锁续期机制、可重入加锁机制、锁释放机制等五个方面对 Redisson 分布式锁原理进行分析。

3.0 整体分析

注:redisson 版本 3.24.4-SNAPSHOT

public class RedissonLockTest {
    public static void main(String[] args) {
        Config config = new Config();
        config.useSingleServer()
            .setPassword("admin")
            .setAddress("redis://127.0.0.1:6379");

        RedissonClient redisson = Redisson.create(config);
        RLock lock = redisson.getLock("myLock");

        try {
            lock.lock();
            // 业务逻辑
        } finally {
            lock.unlock();
        }
    }
}

初始化 RedissonLock

/**
 * 加锁方法
 *
 * @param leaseTime 加锁到期时间(-1:使用默认值 30 秒)
 * @param unit 时间单位
 * @param interruptibly 是否可被中断标识
 * @throws InterruptedException
 */

private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
    // 获取当前线程ID
    long threadId = Thread.currentThread().getId();
    // 尝试获取锁(重点)
    Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
    // lock acquired
    // 成功获取锁, 过期时间为空。
    if (ttl == null) {
        return;
    }

    // 订阅分布式锁, 解锁时进行通知。
    CompletableFuture<RedissonLockEntry> future = subscribe(threadId);
    pubSub.timeout(future);
    RedissonLockEntry entry;
    if (interruptibly) {
        entry = commandExecutor.getInterrupted(future);
    } else {
        entry = commandExecutor.get(future);
    }

    try {
        while (true) {
            // 再次尝试获取锁
            ttl = tryAcquire(-1, leaseTime, unit, threadId);
            // lock acquired
            // 成功获取锁, 过期时间为空, 成功返回。
            if (ttl == null) {
                break;
            }

            // waiting for message
            // 锁过期时间如果大于零, 则进行带过期时间的阻塞获取。
            if (ttl >= 0) {
                try {
                    // 获取不到锁会在这里进行阻塞, Semaphore, 解锁时释放信号量通知。
                    entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                } catch (InterruptedException e) {
                    if (interruptibly) {
                        throw e;
                    }
                    entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                }
            } else {
                // 锁过期时间小于零, 则死等, 区分可中断及不可中断。
                if (interruptibly) {
                    entry.getLatch().acquire();
                } else {
                    entry.getLatch().acquireUninterruptibly();
                }
            }
        }
    } finally {
        // 取消订阅
        unsubscribe(entry, threadId);
    }
}

当锁超时时间为 -1 时,而且获取锁成功时,会启动看门狗定时任务自动续锁:

每次续锁都要判断锁是否已经被释放,如果锁续期成功,自己再次调度自己,持续续锁操作。

为了保证原子性,用 lua 实现的原子性加锁操作,见 3.1 加锁机制。

3.1 加锁机制

加锁机制的核心就是这段,将 Lua 脚本被 Redisoon 包装最后通过 Netty 进行传输。

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    /**
     * // 1
     * KEYS[1] 代表上面的 myLock
     * 判断 KEYS[1] 是否存在, 存在返回 1, 不存在返回 0。
     * 当 KEYS[1] == 0 时代表当前没有锁
     * // 2
     * 查找 KEYS[1] 中 key ARGV[2] 是否存在, 存在回返回 1
     * // 3
     * 使用 hincrby 命令发现 KEYS[1] 不存在并新建一个 hash
     * ARGV[2] 就作为 hash 的第一个key, val 为 1
     * 相当于执行了 hincrby myLock 91089b45... 1
     * // 4
     * 设置 KEYS[1] 过期时间, 单位毫秒
     * // 5
     * 返回 KEYS[1] 过期时间, 单位毫秒
     */

    return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
            "if ((redis.call('exists', KEYS[1]) == 0) " + // 1
                        "or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) then " + // 2
                    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " + // 3
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " + // 4
                    "return nil; " +
                "end; " +
                "return redis.call('pttl', KEYS[1]);"// 5
            Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
}

断点走一波就很清晰了:

KEYS[1]) :加锁的key ARGV[1] :key的生存时间,默认为30秒 ARGV[2] :加锁的客户端ID (UUID.randomUUID()) + “:” + threadId)

上面这一段加锁的 lua 脚本的作用是:第一段 if 判断语句,就是用 exists myLock 命令判断一下,如果你要加锁的那个锁 key 不存在的话(第一次加锁)或者该 key 的 field 存在(可重入锁),你就进行加锁。如何加锁呢?使用 hincrby 命令设置一个 hash 结构,类似于在 Redis 中使用下面的操作:

整个 Lua 脚本加锁的流程画图如下:

可以看出,最新版本的逻辑比之前的版本更简单清晰了。

3.2 锁互斥机制

此时,如果客户端 2 来尝试加锁,会如何呢?首先,第一个 if 判断会执行 exists myLock,发现 myLock 这个锁 key 已经存在了。接着第二个 if 判断,判断一下,myLock 锁 key 的 hash 数据结构中,是否包含客户端 2 的 ID,这里明显不是,因为那里包含的是客户端 1 的 ID。所以,客户端 2 会执行:

return redis.call('pttl', KEYS[1]);

返回的一个数字,这个数字代表了 myLock 这个锁 key 的剩余生存时间。

锁互斥机制主流程其实在 3.0 整体分析 里有讲,具体可以看这个 org.redisson.RedissonLock#lock(long, java.util.concurrent.TimeUnit, boolean) 方法。

3.3 锁续期机制

客户端 1 加锁的锁 key 默认生存时间是 30 秒,如果超过了 30 秒,客户端 1 还想一直持有这把锁,怎么办呢?

Redisson 提供了一个续期机制, 只要客户端 1 一旦加锁成功,就会启动一个 Watch Dog。

3.4 可重入加锁机制

Watch Dog 机制其实就是一个后台定时任务线程,获取锁成功之后,会将持有锁的线程放入到一个 RedissonBaseLock.EXPIRATION_RENEWAL_MAP 里面,然后每隔 10 秒 (internalLockLeaseTime / 3) 检查一下,如果客户端 1 还持有锁 key(判断客户端是否还持有 key,其实就是遍历 EXPIRATION_RENEWAL_MAP 里面线程 id 然后根据线程 id 去 Redis 中查,如果存在就会延长 key 的时间),那么就会不断的延长锁 key 的生存时间。

注:

  1. 如果服务宕机了,Watch Dog 机制线程也就没有了,此时就不会延长 key 的过期时间,到了 30s 之后就会自动过期了,其他线程就可以获取到锁。
  2. 如果调用带过期时间的 lock 方法,则不会启动看门狗任务去自动续期。

3.5 锁释放机制

// 判断 KEYS[1] 中是否存在 ARGV[3]
"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
    "return nil;" +
"end; " +
// 将 KEYS[1] 中 ARGV[3] Val - 1
"local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
// 如果返回大于0 证明是一把重入锁
"if (counter > 0) then " +
    // 重置过期时间
    "redis.call('pexpire', KEYS[1], ARGV[2]); " +
    "return 0; " +
"else " +
    // 删除 KEYS[1]
    "redis.call('del', KEYS[1]); " +
    // 通知阻塞等待线程或进程资源可用
    "redis.call('publish', KEYS[2], ARGV[1]); " +
    "return 1; " +
"end; " +
"return nil;"

KEYS[1]: myLock KEYS[2]: redisson_lock_channel:{myLock} ARGV[1]: 0 ARGV[2]: 30000 (过期时间) ARGV[3]: 66a84a47-3960-4f3e-8ed7-ea2c1061e4cf:1 (Hash 中的锁 field)

同理,锁释放断点走一波:

锁释放机制小结一下:

  • 删除锁(这里注意可重入锁)
  • 广播释放锁的消息,通知阻塞等待的进程(向通道名为 redisson_lock__channel:{myLock} publish 一条 UNLOCK_MESSAGE 信息)
  • 取消 Watch Dog 机制,即将 RedissonLock.EXPIRATION_RENEWAL_MAP 里面的线程 id 删除,并且 cancel 掉 Netty 的那个定时任务线程。

四、主从 Redis 架构中分布式锁存在的问题

  • 线程A从主redis中请求一个分布式锁,获取锁成功;
  • 从redis准备从主redis同步锁相关信息时,主redis突然发生宕机,锁丢失了;
  • 触发从redis升级为新的主redis;
  • 线程B从继任主redis的从redis上申请一个分布式锁,此时也能获取锁成功;
  • 导致,同一个分布式锁,被两个客户端同时获取,没有保证独占使用特性;

为了解决这个问题,redis引入了红锁的概念。

需要准备多台redis实例,这些redis实例指的是完全互相独立的Redis节点,这些节点之间既没有主从,也没有集群关系。客户端申请分布式锁的时候,需要向所有的redis实例发出申请,只有超过半数的redis实例报告获取锁成功,才能算真正获取到锁。跟大多数保证一致性的算法类似,就是多数原理。

public static void main(String[] args) {
    String lockKey = "myLock";
    Config config = new Config();
    config.useSingleServer().setPassword("123456").setAddress("redis://127.0.0.1:6379");
    Config config2 = new Config();
    config.useSingleServer().setPassword("123456").setAddress("redis://127.0.0.1:6380");
    Config config3 = new Config();
    config.useSingleServer().setPassword("123456").setAddress("redis://127.0.0.1:6381");

    RLock lock = Redisson.create(config).getLock(lockKey);
    RLock lock2 = Redisson.create(config2).getLock(lockKey);
    RLock lock3 = Redisson.create(config3).getLock(lockKey);

    RedissonRedLock redLock = new RedissonRedLock(lock, lock2, lock3);

    try {
        redLock.lock();
    } finally {
        redLock.unlock();
    }
}

当然, 对于 Redlock 算法不是没有质疑声,两位大神前几年吵的沸沸腾腾,大家感兴趣的可以去 Redis 官网查看Martin Kleppmann 与 Redis 作者Antirez 的辩论。

额,想收一收了,再讲下去感觉要绕不开分布式经典问题 CAP了。

五、分布式锁选型

鱼和熊掌不可兼得,如果你想强一致性的话可以选择 ZK 的分布式锁,但 ZK 的话性能就会有一定的下降,如果项目没有用到 ZK 的话,那就选择 Redis 的分布式锁吧,比较你为了那极小的概率而丢去性能以及引入一个组件很不划算,如果无法忍受 Redis 的红锁缺陷,那自己在业务中自己保证吧。

下面是常见的几种分布式锁选型对比:


欢迎加入我的知识星球,全面提升技术能力。

👉 加入方式,长按”或“扫描”下方二维码噢

星球的内容包括:项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话,在看,转发吧。

谢谢支持哟 (*^__^*)

微信扫码关注该文公众号作者

来源:芋道源码

相关新闻

清华提出时间序列大模型:面向通用时序分析的生成式Transformer | ICML 2024僵人综合征患者,唱响奥运会开幕式!大数据分析展示太多无奈和希望。开启自免&过敏检测新纪元,邦器生物推出全自动流式荧光发光免疫分析仪彭博投资组合分析工具月报 | 开放式API对接技术与应用如何解决推进中国式现代化中的难题?这个蓝皮书这样分析玻色量子发布量子计算“超强大脑”;OceanBase 4.3推出列式存储引擎,可实现秒级实时分析丨AIGC日报爆发式增长后,这一万亿级赛道开启淘汰赛|焦点分析马上抢位|《数据/商业分析求职实战营》即将开课!结合当下岗位需求、面试热点,一站式提升简历、面试、行业知识及技能!即将截止|《数据/商业分析求职实战营·基础班》明日开课,把握最后机会,解锁大厂真实项目经验!视频号拉动腾讯Q2毛利,游戏终于回归增长|焦点分析【免费讲座】文献计量分析的选题与投稿:没有实验数据,也能表系列SCI论文!叮!请查收高甘油三酯血症的AI大数据分析报告北大汇丰商学院:2024中国同中东地区经贸往来分析报告拉美电商巨头净利润翻倍,新大陆市场激战正酣 | 36氪分析不满足于让ChatGPT做实习生,对冲基金希望聊天机器人能当分析师​文美集团万博士:2025年美国大学申请表重点分析布朗大学录取趋势分析及2024-25申请季文书题目今日实习|小摩2025暑期分析师项目开启,要求25-26年间毕业!IF63.1分!简单做做分析就能发JAMA上!谁说综述不能发高分!(附综述写作套路)俄乌战争结果将由中国决定?高盛发布对中国七大行业产能分析,5个行业产能超过全球需求之和……用户分析5大法则,互联网大厂都在用!A16Z分析:游戏Demo又火了,但我们能回到Demo时代吗?猛卷卖家、扶持红人,TikTok狠推直播电商|焦点分析猛卷卖家、扶持红人,TikTok狠推直播电商|36氪分析
logo
联系我们隐私协议©2024 bendi.news
Bendi新闻
Bendi.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Bendi.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。