Redisson分布式锁学习总结:RedissonRedLock 是如何实现 RedLock 算法的?

1、RedLock 算法

1.1、RedLock 算法是什么?

Redis 作者对于分布式锁提出的一种加锁算法,其实核心非常简单:假设redis集群中有N个redis节点,只有当客户端成功在 N/2+1 个实例中成功加锁成功,才算成功持有分布式锁。当然了,这算法里面还有很多其他的小细节,如果大家感兴趣,可以看看 redis 官网关于 RedLock 算法的介绍,是非常详细的。RedLock算法

那么,Redisson 有对应的实现么?

那是必须有的,各种锁都提供了,难道还会缺这个么?同时,我们可以在官网看到,官网对于 RedLock 算法的Java客户端实现,首推 Redisson。
在这里插入图片描述

1.2、为什么需要 RedLock 算法?

回头想想,为什么需要 RedLock 算法?

我们知道,之前提到的分布式锁有:可重入锁、公平锁、读写锁,他们其实底层都是根据key计算出一个槽(slot),这个槽可以对应到某个 Redis 集群的一个节点;那么就是说,这些分布式锁仅仅是在一个节点上加锁,那么下面的情况就会出现不同客户端持有锁:

  • Redis 集群是多主多从架构,假设客户端1在MasterNode1上成功持有锁[myLock],但不幸的是,MasterNode1突然宕机了,并且此时还未将数据完全同步给SlaveNode1(包括客户端1的加锁信息),那么当 SlaveNode1 被选举为新的 MasterNode1 后,其他客户端就可以在新的 MasterNode1成功持有锁[myLock]。

其实这个场景,redis 官网在介绍 RedLock 算法的时候也提到了~
在这里插入图片描述

正是因为可能出现上面的场景,导致不同客户端可同时持有同一把锁,所以才推出 RedLock 算法。

但是我们上篇文章不是介绍了可以同时持有N个资源的 RedissonMultiLock 么,感觉它的实现原理可以完成这个 RedLock 算法。确实,在 Redisson 中,RedissonRedLock 就是基于 RedissonMultiLock 上面做的扩展,并且仅仅重写了三方法,下面我们将简单介绍一下。

2、RedissonRedLock

2.1、使用demo:

public class RedissonRedLockDemo {

    public static void main(String[] args) {
        RedissonClient redissonClient = RedissonClientUtil.getClient("");
        RLock rLock1 = redissonClient.getLock("lock1");
        RLock rLock2 = redissonClient.getLock("lock2");
        RLock rLock3 = redissonClient.getLock("lock3");
        RedissonRedLock redLock = new RedissonRedLock(rLock1, rLock2, rLock3);
        redLock.lock();
        redLock.unlock();

        int result1 = CRC16.crc16("lock1".getBytes()) % 16384;
        int result2 = CRC16.crc16("lock2".getBytes()) % 16384;
        int result3 = CRC16.crc16("lock3".getBytes()) % 16384;
        System.out.println("========测试一=========");
        System.out.println(result1);
        System.out.println(result2);
        System.out.println(result3);

        int result11 = CRC16.crc16("lockone".getBytes()) % 16384;
        int result21 = CRC16.crc16("locktwo".getBytes()) % 16384;
        int result31 = CRC16.crc16("lockthree".getBytes()) % 16384;
        System.out.println("========测试二=========");
        System.out.println(result11);
        System.out.println(result21);
        System.out.println(result31);

        System.out.println("redis cluster 三个节点,平均 slot:"+16384/3);
    }

}

我们可以看到,RedissonRedLock 不愧是基于 RedissonMultiLock 做的简单扩展,确实连使用都是基本一致的;只需要配置好 N 个锁,一般数量就是对应集群中主节点的数量,然后创建一个 RedissonRedLock 对象,接着就是调用获取锁和释放锁的方法即可。

2.2、使用 RedissonRedLock 时需要注意 key 的使用

那下面的那些计算slot是怎么回事?

在 RedLock 算法中提到的是,获取锁其实就是在所有 Rediss 实例节点使用同一个 key 进行加锁操作。

但在 Redisson 中,执行lua脚本前是需要根据 Key 来定位 slot 的,然后 slot 能对应一个 Redis 节点。那么,如果我们在使用 RedissonRedLock 时,如果所有 RLock 都指定同一个key,都等同于当前客户端在重复获取同一把锁,那么最终就达不到 RedLock 算法的效果了。

那么应该怎么指定 RedissonRedLock 中锁的 key 呢?

我们先看一下上面关于slot计算的两个测试结果:

========测试一=========
11346
7217
3088
========测试二=========
10453
998
6216

redis cluster 三个节点,平均 slot:5461

Process finished with exit code 0

redis 集群中,slot 的总数为 16394,如果集群中有三个主节点,那么第一个主节点的slot槽有:[1,5461]、第二个主节点的slot槽有:[5462,10923]、第三个主节点的slot槽有:[10924,16384]。当然了,不一定就是这些数,但是大概也差不了多少了。

我们可以发现,测试一中的key都分别分布在三个节点中了,而测试二中的key,一个在节点1中,两个在节点2中;这么一看,明显测试一中的key使用更符合 RedLock 算法。那么,我们可以认为测试一的key在RedissonRedLock 中使用是符合 RedLock 算法的。

其实,想保证 key 一定是使用正确的话,最稳健的就是研究 CRC16 算法是如何利用 key 定位 slot 的,当你分析透彻了,怎么使用也不在话下了。

2.3、源码分析:

好了,上面关于 key 在 RedissonRedLock 应该如何使用,也简单地分析完了,下面继续 RedissonRedLock 的源码分析。

因为 RedissonRedLock 是基于 RedissonMultiLock 做的简单扩展,而且只是重写了三方法,那么源码是非常的简单的,我们直接上源码。

RedissonRedLock 源码:

public class RedissonRedLock extends RedissonMultiLock {

    /**
     * Creates instance with multiple {@link RLock} objects.
     * Each RLock object could be created by own Redisson instance.
     *
     * @param locks - array of locks
     */
    public RedissonRedLock(RLock... locks) {
        super(locks);
    }

    @Override
    protected int failedLocksLimit() {
        return locks.size() - minLocksAmount(locks);
    }
    
    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);
    }

}

重写failedLocksLimit():

重写这个方法是因为,在 RedissonMultiLock 中,是要保证所有子锁都获取成功,连锁才算获取成功,所以 RedissonMultiLock 的 failedLocksLimit() 方法返回的是0。

而 RedissonRedLock 重写后,失败上限就是locks.size()/2 + 1,即 RedLock 算法中,大多数节点成功获取锁即可。

重写calcLockWaitTime(long remainTime):

RedissonMultiLock 遍历锁列表获取锁时,每个锁调用 tryLock 的等待时间都是同样的,即[baseTime/2,baseTime]之间的随机数。其中 baseWaitTime = locks.size() * 1500。因为 RedissonMultiLock 的 calcLockWaitTime 方法就是传入什么返回什么。

而 RedissonRedLock 重写后,是每个锁平分这个等待时间,如果均分后小于1,那就是1。我觉得这个重写,最大的意义在于能快速到下一个redis节点获取锁,因为 RedLock 算法只需保证大多数节点成功获取锁即可,避免等待多余的时间。

重写unlock():

直接调用 RedissonMultiLock 的 unlockInner() 方法。

3、最后

到此,关于 RedissonRedLock 锁的分析就完毕了;但其实 RedLock 算法不只这么一点东西,如果大家对这个算法感兴趣,可以到官网上面看看作者的介绍哈~

大家如果对此系列的文章感兴趣的话,可以直接关注专栏:<<分布式锁系列文章>>

<think>好的,用户想了解如何使用Redisson分布式锁实现高并发环境下的库存管理系统,确保多库并发控制的正确性和效率。我需要结合他们提供的引用内容来构建一个全面的回答。 首先,根据引用[1]和[2],Redisson分布式锁的推荐方案,因为它解决了数据库和缓存不一致的问题,并且符合CAP原理。用户可能关心Redisson的基本原理和如何集成到库存系统中。我需要解释Redisson的锁机制,比如可重入锁、锁续期等。 然后,库存管理通常涉及扣减库存的操作,必须保证原子性。这里需要提到使用Redis的原子操作,比如Lua脚本,或者结合Redisson的RLock。引用[3]提到了锁等待时间,这可能和锁的超时设置有关,需要说明如何合理配置锁的过期时间,避免死锁和长时间阻塞。 接下来是多库并发控制的问题。库存系统可能有多个仓库或数据库,分布式锁需要跨所有节点协调。根据引用[1]中的RedLock算法,可能需要多个独立的Redis实例来实现更可靠的锁。不过Redisson已经支持RedLock,可以介绍如何配置和使用。 另外,引用[4]提到锁的粒度问题,使用userid作为锁的key,这里库存管理可能需要以商品ID或库存ID作为锁的键,确保同一商品的库存操作串行化,避免超卖。需要强调锁的粒度要合适,太粗会影响并发性能,太细会增加复杂度。 还需要考虑高并发下的性能优化,比如分段锁。引用[3]提到了Go的分段加锁Demo,可能可以借鉴到Java中,将库存分成多个段,每个段单独加锁,提高并发度。例如,将库存拆分为多个子库存,减少锁竞争。 此外,异常处理也很重要,比如锁的自动续期、避免锁泄漏。Redisson的看门狗机制可以自动延长锁的持有时间,防止业务未完成时锁过期。需要提醒用户正确处理锁的获取和释放,确保在异常情况下也能释放锁,比如在finally块中释放。 最后,分布式事务和幂等性可能也是需要考虑的,引用[2]提到了接口的幂等性,库存操作需要保证即使重复请求也不会多次扣减。可以通过唯一事务ID或版本号机制来实现。 总结回答结构:先介绍Redisson分布式锁的核心机制,然后详细说明库存扣减流程,包括锁的获取、原子操作、多库处理,接着讨论锁的优化如分段锁和RedLock,最后强调异常处理和监控。这样用户能一步步了解如何正确高效地实现分布式库存管理。</think>### Redisson分布式锁在库存管理系统中的实现实践 #### 一、核心机制设计 1. **可重入锁机制** Redisson的`RLock`支持线程级别的重入特性,同一线程可重复获取锁,防止死锁。适用于需要嵌套调用的库存操作场景: ```java RLock lock = redissonClient.getLock("product_stock:1001"); lock.lock(10, TimeUnit.SECONDS); // 设置自动过期时间[^1] ``` 2. **看门狗自动续期** 当未显式设置`leaseTime`参数时,Redisson会启动后台线程每10秒检测锁状态并自动续期(默认30秒有效期),避免业务未完成时锁过期[^1]。 #### 二、库存扣减流程实现 ```java public boolean deductStock(String productId, int quantity) { String lockKey = "stock_lock:" + productId; RLock lock = redissonClient.getLock(lockKey); try { // 尝试获取锁(等待5秒,锁持有30秒) if (lock.tryLock(5, 30, TimeUnit.SECONDS)) { int currentStock = redisTemplate.opsForValue().get(productId); if (currentStock >= quantity) { redisTemplate.opsForValue().decrement(productId, quantity); return true; } return false; } } finally { lock.unlock(); } } ``` #### 三、多库并发控制方案 1. **库存分片策略** 采用分段锁提升并发能力,将总库存拆分为N个分片: ```java int shard = productId.hashCode() % 16; String lockKey = "stock_shard_lock:" + shard; ``` 2. **跨库事务协调** 使用RedLock算法实现跨多Redis节点的强一致性: ```java RLock lock1 = redissonClient1.getLock("lockKey"); RLock lock2 = redissonClient2.getLock("lockKey"); RedissonRedLock redLock = new RedissonRedLock(lock1, lock2); ``` #### 四、性能优化实践 | 优化维度 | 实施方法 | 效果提升 | |----------------|-----------------------------------|---------------------------| | 锁粒度控制 | 按商品ID+仓库ID组合锁定 | 降低锁竞争概率 | | 热点库存拆分 | 将1000件库存拆分为10个100件的分片 | 并发能力提升8-10倍 | | 预扣库存策略 | 使用Redis原子操作提前扣减虚拟库存 | 减少数据库压力 | #### 五、异常处理关键点 1. **网络分区防护** 设置合理的`lockWatchdogTimeout`(默认30秒),配合`innodb_lock_wait_timeout`(数据库行锁超时)形成双层保护[^3] 2. **幂等性保证** 为每个操作生成唯一事务ID: ```sql UPDATE inventory SET stock=stock-? WHERE product_id=? AND version=? ``` #### 六、监控指标建议 1. 锁等待时间百分位(P99 ≤ 50ms) 2. 库存操作TPS与锁获取成功率关联分析 3. 分片锁的竞争热度分布
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值