八股整理:说一下红锁RedLock的实现原理?

RedLock 是一种分布式锁的实现算法,由 Redis 的作者 Salvatore Sanfilippo(也称为 Antirez)提出,主要用于解决在分布式系统中实现可靠锁的问题。在 Redis 单独节点的基础上,RedLock 使用了多个独立的 Redis 实例(通常建议是奇数个,比如 5 个),共同协作来提供更强健的分布式锁服务

RedLock 算法旨在解决单个 Redis 实例作为分布式锁时可能出现的单点故障问题,通过在多个独立运行的 Redis 实例上同时获取锁的方式来提高锁服务的可用性和安全性。

RedLock 具备以下主要特性:

  1. 互斥性:在任何时间,只有一个客户端可以获得锁,确保了资源的互斥访问。
  2. 避免死锁:通过为锁设置一个较短的过期时间,即使客户端在获得锁后由于网络故障等原因未能按时释放锁,锁也会因为过期而自动释放,避免了死锁的发生。
  3. 容错性:即使一部分 Redis 节点宕机,只要大多数节点(即过半数以上的节点)仍在线,RedLock 算法就能继续提供服务,并确保锁的正确性。

1.RedLock 实现思路

RedLock 是对集群的每个节点进行加锁,如果大多数节点(N/2+1)加锁成功,则才会认为加锁成功。

这样即使集群中有某个节点挂掉了,因为大部分集群节点都加锁成功了,所以分布式锁还是可以继续使用的。

2.工作流程

RedLock 算法的工作流程大致如下:

  • 客户端向多个独立的 Redis 实例尝试获取锁,设置锁的过期时间非常短。
  • 如果客户端能在大部分节点上成功获取锁,并且所花费的时间小于锁的过期时间的一半,那么认为客户端成功获取到了分布式锁。
  • 当客户端完成对受保护资源的操作后,它需要向所有曾获取锁的 Redis 实例释放锁。
  • 若在释放锁的过程中,客户端因故无法完成,由于设置了锁的过期时间,锁最终会自动过期释放,避免了死锁。

3.基本使用

在 Java 开发中,可以使用 Redisson 框架很方便的实现 RedLock,具体操作代码如下:

import org.redisson.Redisson;
import org.redisson.api.RedisClient;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.redisson.redisson.RedissonRedLock;

public class RedLockDemo {

    public static void main(String[] args) {
        // 创建 Redisson 客户端配置
        Config config = new Config();
        config.useClusterServers()
        .addNodeAddress("redis://127.0.0.1:6379",
                        "redis://127.0.0.1:6380",
                        "redis://127.0.0.1:6381"); // 假设有三个 Redis 节点
        // 创建 Redisson 客户端实例
        RedissonClient redissonClient = Redisson.create(config);
        // 创建 RedLock 对象
        RedissonRedLock redLock = redissonClient.getRedLock("resource");
        try {
            // 尝试获取分布式锁,最多尝试 5 秒获取锁,并且锁的有效期为 5000 毫秒
            boolean lockAcquired = redLock.tryLock(5, 5000, TimeUnit.MILLISECONDS); 
            if (lockAcquired) {
                // 加锁成功,执行业务代码...
            } else {
                System.out.println("Failed to acquire the lock!");
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            System.err.println("Interrupted while acquiring the lock");
        } finally {
            // 无论是否成功获取到锁,在业务逻辑结束后都要释放锁
            if (redLock.isLocked()) {
                redLock.unlock();
            }
            // 关闭 Redisson 客户端连接
            redissonClient.shutdown();
        }
    }
}

4.实现原理

Redisson 中的 RedLock 是基于 RedissonMultiLock(联锁)实现的。

RedissonMultiLock 是 Redisson 提供的一种分布式锁类型,它可以同时操作多个锁,以达到对多个锁进行统一管理的目的。联锁的操作是原子性的,即要么全部锁住,要么全部解锁。这样可以保证多个锁的一致性。

RedissonMultiLock 使用示例如下:

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.redisson.multi.MultiLock;

public class RedissonMultiLockDemo {

    public static void main(String[] args) throws InterruptedException {
        // 创建 Redisson 客户端
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        RedissonClient redisson = Redisson.create(config);

        // 创建多个分布式锁实例
        RLock lock1 = redisson.getLock("lock1");
        RLock lock2 = redisson.getLock("lock2");
        RLock lock3 = redisson.getLock("lock3");

        // 创建 RedissonMultiLock 对象
        MultiLock multiLock = new MultiLock(lock1, lock2, lock3);

        // 加锁
        multiLock.lock();
        try {
            // 执行任务
            System.out.println("Lock acquired. Task started.");
            Thread.sleep(3000);
            System.out.println("Task finished. Releasing the lock.");
        } finally {
            // 释放锁
            multiLock.unlock();
        }
        // 关闭客户端连接
        redisson.shutdown();
    }
}

在示例中,我们首先创建了一个 Redisson 客户端并连接到 Redis 服务器。然后,我们使用 redisson.getLock 方法创建了多个分布式锁实例。接下来,我们通过传入这些锁实例来创建了 RedissonMultiLock 对象。

说回正题,RedissonRedLock 是基于 RedissonMultiLock 实现的这点,可以从继承关系看出。

RedissonRedLock 继承自 RedissonMultiLock,核心实现源码如下:

public class RedissonRedLock extends RedissonMultiLock {
    public RedissonRedLock(RLock... locks) {
        super(locks);
    }

    /**
     * 锁可以失败的次数,锁的数量-锁成功客户端最小的数量
     */
    @Override
    protected int failedLocksLimit() {
        return locks.size() - minLocksAmount(locks);
    }

    /**
     * 锁的数量 / 2 + 1,例如有3个客户端加锁,那么最少需要2个客户端加锁成功
     */
    protected int minLocksAmount(final List<RLock> locks) {
        return locks.size()/2 + 1;
    }

    /** 
     * 计算多个客户端一起加锁的超时时间,每个客户端的等待时间
     */
    @Override
    protected long calcLockWaitTime(long remainTime) {
        return Math.max(remainTime / locks.size(), 1);
    }

    @Override
    public void unlock() {
        unlockInner(locks);
    }
}

从上述源码可以看出,Redisson 中的 RedLock 是基于 RedissonMultiLock(联锁)实现的,当 RedLock 是对集群的每个节点进行加锁,如果大多数节点,也就是 N/2+1 个节点加锁成功,则认为 RedLock 加锁成功。

5.存在问题

RedLock 主要存在以下两个问题:

  1. 性能问题:RedLock 要等待大多数节点返回之后,才能加锁成功,而这个过程中可能会因为网络问题,或节点超时的问题,影响加锁的性能。
  2. 并发安全性问题:当客户端加锁时,如果遇到 GC 可能会导致加锁失效,但 GC 后误认为加锁成功的安全事故,例如以下流程:
    1. 客户端 A 请求 3 个节点进行加锁。
    2. 在节点回复处理之前,客户端 A 进入 GC 阶段(存在 STW,全局停顿)。
    3. 之后因为加锁时间的原因,锁已经失效了。
    4. 客户端 B 请求加锁(和客户端 A 是同一把锁),加锁成功。
    5. 客户端 A GC 完成,继续处理前面节点的消息,误以为加锁成功。
    6. 此时客户端 B 和客户端 A 同时加锁成功,出现并发安全性问题。

6.已废弃的 RedLock

因为 RedLock 存在的问题争议较大,且没有完美的解决方案,所以 Redisson 中已经废弃了 RedLock,这一点在 Redisson 官方文档中能找到,如下图所示:

课后思考

既然 RedLock 已经被废弃,那么想要实现分布式锁,同时又想避免 Redis 单点故障问题,应该使用哪种解决方案呢?

参考 & 鸣谢

javacn.site

#八股文##java#
Java面试精讲 文章被收录于专栏

Java常见面试题、场景题、企业真题精讲。

全部评论

相关推荐

问题1:为什么会使用分库分表,到达了什么样的数据级别才会去加设计,是否对数据量有一个统计我的理解:看星哥之前写过&nbsp;单表行数超&nbsp;500&nbsp;万行或者单表容量超过&nbsp;2GB,推荐分库分表,但是面试的过程中怕被问自己写的项目会有这么大的数据量吗不要这么硬背,具体情况具体分析,有的表字段少,经常是条件等值查询,这样加个索引,一个亿也不用分表,有的字段多,还是范围查询,可能5000万就得分表,面试官问你你说是自己在学习分库分表应用到项目中,自己造了几千万的数据量问题2:基因法需要分表的一个数量和确定的一个东西(我的理解是分表的依据,例如大麦中是订单编号和用户id),但是正常的生产环境中是可能动态改变的,比如说需要动态扩容的话,怎么解决呢(例如当前有4个分表,但是现在需要扩充到8个分表),是使用双写吗?这个在扩容前就要考虑好能维持多少年内不需要再扩容。转转架构师在分库分表前,通过之前记录的数据增长量,做了256张表,能在7年内不需要再扩容,如果需要扩容的话,可以使用双写,新扩容表写的过程中,用新的分库分表算法问题3:如果在防止超卖的过程中,Redis不可用了,怎么解决我的理解:使用Redis集群和主从复制吗?因为Redis宕机的话数据库的数据也不能保证是最新的版本,所以得尽量保证Redis不宕机?肯定要使用redis集群模式,但可能会有主从延迟,导致从节点数据不是最新的,但关系不大。可以在用户生成订单后,修改数据库的座位和库存,然后用户支付后,再改数据库的座位和库存,每一步都做好验证。这样从节点的数据问题会降到最低。问题4:如果在当前的幂等验证逻辑中,有一个消息所对应的幂等标识符是不存在的,按照现有的逻辑是可以执行的,但是幂等验证之后的业务系统异常了,这个时候应该怎么处理呢(即通过了幂等的验证,但是后面的服务down掉了,比如说下游抛了一个异常出来)【没太明白应该回答什么,是指需要将幂等标识符重新进行设置吗】异常了就异常了呗,把这个请求的标识从redis中删除了,就像分布式锁时,业务异常也要执行解锁一样,让下一个请求进来正常执行,然后设置好标识位问题5:本地缓存为什么使用Caffine呢,为啥不用Guava因为caffine的性能要远高于Guava,没有其他复杂原因我的理解:查了下Caffine就是Guava改进而来的,可以这么说吗-&nbsp;Caffine在读写操作方面的性能更高,是基于异步的操作,将淘汰过期操作与读写进行分离-&nbsp;Caffine采用了一种结合&nbsp;LRU、LFU的算法W-TinyLFU+,具有高命中率,低内存占用的特点
查看5道真题和解析
点赞 评论 收藏
分享
评论
点赞
4
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务