最新《Redis实战篇》五、分布式锁-redission(3),2024年最新为什么大公司一定要使用微服务

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

private RedissonClient redissonClient;

@Override
public Result seckillVoucher(Long voucherId) {
// 1.获取优惠券信息
SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
// 2.判断秒杀是否开始
LocalDateTime beginTime = voucher.getBeginTime();
LocalDateTime endTime = voucher.getEndTime();
if(beginTime.isAfter(LocalDateTime.now()) || endTime.isBefore(LocalDateTime.now())){
return Result.fail(“不再秒杀时段内!”);
}
// 3.判断库存是否充足
if(voucher.getStock() < 1){
//库存不足
return Result.fail(“库存不足!”);
}
Long userId = UserHolder.getUser().getId();
// 这个代码我们不用了,下面要用Redisson中的分布式锁
// SimpleRedisLock lock = new SimpleRedisLock(“order:” + userId, stringRedisTemplate);
RLock lock = redissonClient.getLock(“order:” + userId);
boolean isLock = lock.tryLock();
// 判断是否获取锁成功
if(!isLock){
// 获取锁失败,返回错误和重试
return Result.fail(“不允许重复下单~”);
}
try {
// 获取代理对象(只有通过代理对象调用方法,事务才会生效)
IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
return proxy.createVoucherOrder(voucherId);
} finally {
lock.unlock();
}
}


**进行测试:**


在集群环境下,一秒一千次请求~ 一个用户只能下一单。分布式锁测试成功~


![image-20221221131219831](https://img-blog.csdnimg.cn/img_convert/f11160a94e7111973db4f6da89307482.png)


![image-20221221131345069](https://img-blog.csdnimg.cn/img_convert/ef924c2ff59e7e325e84de7b36b02138.png)


#### 5.3 分布式锁-redission可重入锁原理


在Lock锁中,他是借助于底层的一个voaltile的一个state变量来记录重入的状态的,比如当前没有人持有这把锁,那么state=0,假如有人持有这把锁,那么state=1,如果持有这把锁的人再次持有这把锁,那么state就会+1 ,如果是对于synchronized而言,他在c语言代码中会有一个count,原理和state类似,也是重入一次就加一,释放一次就-1 ,直到减少成0 时,表示当前这把锁没有被人持有。


在redission中,我们的也支持支持可重入锁


在分布式锁中,他采用hash结构用来存储锁,其中大key表示表示这把锁是否存在,用小key表示当前这把锁被哪个线程持有。流程图如下:


![image-20221221155020125](https://img-blog.csdnimg.cn/img_convert/bfdaf1f5dd5547a7651a114d97edf70f.png)



> 
> 为什么每次获取锁成功 或 释放锁 后都要重新设置锁的有效期呢?
> 
> 
> 这样是为了下面的业务有足够的时间去执行~
> 
> 
> 


**1、接下来我们一起分析一下当前的可重入锁实现的lua表达式**


* 获取锁的Lua脚本:



local key = KEYS[1]; – 锁的key
local threadId = ARGV[1]; – 线程唯一标识
local releaseTime = ARGV[2]; – 锁的自动释放时间
– 判断是否存在
if(redis.call(‘exists’, key) == 0) then
– 不存在, 获取锁
redis.call(‘hset’, key, threadId, ‘1’);
– 设置有效期
redis.call(‘expire’, key, releaseTime);
return 1; – 返回结果
end;
– 锁已经存在,判断threadId是否是自己
if(redis.call(‘hexists’, key, threadId) == 1) then
– 存在, 获取锁,重入次数+1
redis.call(‘hincrby’, key, threadId, ‘1’);
– 设置有效期
redis.call(‘expire’, key, releaseTime);
return 1; – 返回结果
end;
return 0; – 代码走到这里,说明获取锁的不是自己,获取锁失败


* 释放锁的Lua脚本:



local key = KEYS[1]; – 锁的key
local threadId = ARGV[1]; – 线程唯一标识
local releaseTime = ARGV[2]; – 锁的自动释放时间
– 判断当前锁是否还是被自己持有
if (redis.call(‘HEXISTS’, key, threadId) == 0) then
return nil; – 如果已经不是自己,则直接返回
end;
– 是自己的锁,则重入次数-1
local count = redis.call(‘HINCRBY’, key, threadId, -1);
– 判断是否重入次数是否已经为0
if (count > 0) then
– 大于0说明不能释放锁,重置有效期然后返回
redis.call(‘EXPIRE’, key, releaseTime);
return nil;
else – 等于0说明可以释放锁,直接删除
redis.call(‘DEL’, key);
return nil;
end;


**2、测试Redission的分布式锁的可重入效果**



/**
* @author lxy
* @version 1.0
* @Description 测试Redisson的分布式锁的可重入性质
* @date 2022/12/21 16:01
*/
@Slf4j
@SpringBootTest
public class RedissonTest {

@Resource
private RedissonClient redissonClient;

private RLock lock;

@BeforeEach
void setUp(){
    lock = redissonClient.getLock("order");
}

@Test
void method1() throws InterruptedException {
    // 尝试获取锁
    boolean isLock = lock.tryLock(1L, TimeUnit.SECONDS);
    if (!isLock){
        log.error("获取锁失败....1");
        return;
    }
    try {
        log.info("获取锁成功....1");
        method2();
        log.info("开始执行业务....1");
    } finally {
        log.warn("开始释放锁....1");
        lock.unlock();
    }

}

void method2(){
    // 尝试获取锁
    boolean isLock = lock.tryLock();
    if(!isLock){
        log.error("获取锁失败....2");
        return;
    }
    try {
        log.info("获取锁成功....2");
        log.info("开始执行业务....2");
    } finally {
        log.warn("准备释放锁....2");
        lock.unlock();
    }
}

}


Debug测试:


![](https://img-blog.csdnimg.cn/img_convert/c65ad4e7e318bbfd27c866aa9a5ead62.png)


![](https://img-blog.csdnimg.cn/img_convert/1a6bd76a35f7215cbbe5828a59cf9120.png)


**3、接下来我们可以查看下Redisson中的分布式锁的实现:**


![image-20221221163708051](https://img-blog.csdnimg.cn/img_convert/510d4d790b0b55cbc959bef8ce19ecbc.png)



> 
> 注意源码中的KEYS[1]指外边的大Key,AVG[1]:大Key的过期时间,AVG[2]:当前的线程ID
> 
> 
> 


![image-20221221163825349](https://img-blog.csdnimg.cn/img_convert/3e22f9139fc91a4e7c4fb7aef7889fb9.png)



> 
> 源码中的KEYS[1]指外边的大Key,AVG[2]:大Key的过期时间,AVG[3]:当前的线程ID。KEYS[2]和ARGV[1]所代表的含义我们后面会讲解~
> 
> 
> 


#### 5.4 分布式锁-redission锁重试和WatchDog机制


关于锁可重试的原理见:<https://www.processon.com/view/link/63a86e6534446c6f609d3a3f>


关于锁超时续约 和 锁释放的原理见:<https://www.processon.com/view/link/63a891cece3d3c6150d7c2ac>


**Redission分布式锁原理**


![image-20221226021503722](https://img-blog.csdnimg.cn/img_convert/8a01f71e372a509084a734c43387d1a8.png)



> 
> 注意:只有leaseTime=-1,才会走WatchDog的逻辑
> 
> 
> 


**总结:Redisson分布式锁原理**


* 可重入:利用hash结构记录线程id和重入次数
* 可重试:利用信号量和PubSub功能实现等待、唤醒,获取锁失败的重试机制
* 超时续约:利用watchDog,每隔一段时间(releaseTime / 3),重置超时时间



> 
> **为什么需要超时续约呢?**  
>  因为我们某个线程获取到锁然后开始执行业务逻辑,但是业务执行时候出现了卡顿,从而导致锁超时后会被释放。之后我这业务执行完,再次执行unlock会出错。同时超时释放别的线程会拿到分布式锁而卡顿的业务还没执行完,从而就会产生线程安全问题~  
>  所以超时续约目的主要是 `当前线程获取锁后,只要没执行完就不会超时释放,会不断的超时续约`,直到业务逻辑执行完释放锁后,超时续约结束!
> 
> 
> 


#### 5.5 分布式锁-redission锁的MutiLock原理


为了提高redis的可用性,我们会搭建集群或者主从,现在以主从为例


此时我们去写命令,写在主机上, 主机会将数据同步给从机,但是假设在主机还没有来得及把数据写入到从机去的时候,此时主机宕机,哨兵会发现主机宕机,并且选举一个slave变成master,而此时新的master中实际上并没有锁信息,此时锁信息就已经丢掉了。


![image-20221226022637870](https://img-blog.csdnimg.cn/img_convert/c85c3272db0443291745a09d3edbe390.png)


为了解决这个问题,redission提出来了`MutiLock锁`,使用这把锁咱们就不使用主从了,每个节点的地位都是一样的, 这把锁`加锁的逻辑需要写入到每一个主丛节点上,只有所有的服务器都写入成功,此时才是加锁成功`,假设现在某个节点挂了,那么他去获得锁的时候,只要有一个节点拿不到,都不能算是加锁成功,就保证了加锁的可靠性。


![image-20221226022539880](https://img-blog.csdnimg.cn/img_convert/69100fa6371903d31f31bc17bd75c409.png)


**代码演示:**


①Linux下建立三个Redis节点(使用Docker)



docker run -p 6379:6379 --name redis -v /mydata/redis/data:/data -v /mydata/redis/conf/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf
docker run -p 6380:6379 --name redis2 -v /mydata/redis2/data:/data -v /mydata/redis2/conf/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf
docker run -p 6381:6379 --name redis3 -v /mydata/redis3/data:/data -v /mydata/redis3/conf/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf


②修改Redisson配置类



![img](https://img-blog.csdnimg.cn/img_convert/a291751f22aa3b3d6ddb4a8c36ef1e5f.png)
![img](https://img-blog.csdnimg.cn/img_convert/445eb83c152e234d66cba403f318ad58.png)

**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友,可以戳这里获取](https://bbs.csdn.net/topics/618545628)**


**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**



[外链图片转存中...(img-SGlCrOpi-1715813756409)]
[外链图片转存中...(img-qYLGxkdN-1715813756409)]

**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友,可以戳这里获取](https://bbs.csdn.net/topics/618545628)**


**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**

  • 15
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值