一文让你搞懂如何手写一个redis分布式锁

2022-11-11 09:09:49

目录场景搭建环境分析解决问题分析1分析2分析3总结场景既然要搞懂Redis分布式锁,那肯定要有一个需要它的场景。高并发售票问题就是一个经典案例。搭建环境准备redis服务,设置redis的键值对:se...

目录
场景
搭建环境
分析解决问题
分析1
分析2
分析3
总结

场景

既然要搞懂Redis分布式锁,那肯定要有一个需要它的场景。

高并发售票问题就是一个经典案例。

搭建环境

准备redis服务,设置redis的键值对:set ticket 10
准备 postman、JMeter 等模拟高并发请求的工具
核心代码
@Service
publicclassTicketServiceImplimplementsTicketService{
@Autowired
privateStringRedisTemplatestringRedisTemplate;

privateLoggerlogger=LoggerFactory.getLogger(TicketServiceImpl.class);

@Override
publicStringsellTicket(){
StringticketStr=stringRedisTemplate.opsForValue().get("ticket");
intticket=0;
if(null!=ticketStr){
ticket=Integer.parseInt(ticketStr);
}
if(ticket>0){
intticketNew=ticket-1;
stringRedisTemplate.opsForValue().set("ticket",String.valueOf(ticketNew));
logger.info("当前票的库存为:"+ticketNew);
}else{
logger.info("手速不够呀,票已经卖光了...");
}
return"抢票成功...";
}
}

分析解决问题

以上代码没有做任何的加锁操作,在高并发情况下,票的超卖情况很严重,根本无法正常使用

分析1

既然要加分布式锁,那么我们可以使用Redis中的setnx命令来模拟一个锁。

redis>EXISTSjob#job不存在
(integer)0

redis>SETNXjob"programmer"#job设置成功
(integer)1

redis>SETNXjob"code-farmer"#尝试覆盖job,失败
(integer)0

当一个线程进入到当前方法中,使用 setnx 设置一个键,如果设置成功,就允许继续访问,设置失败,就不能访问该方法;

当方法运行完毕时,将这个键删除,下一次再有线程来访问时,就重新执行该操作。

publicStringsellTicket(){
Stringlock="lock";
//如果成功设置这个值,证明目前该方法并没有被操作,可以进行卖票操作
Booleantag=stringRedisTemplate.opsForValue().setIfAbsent(lock,"");
if(!tag){//如果设置失败,证明当前方法正在被执行,不允许再次执行
//实际开发环境应该使用队列来完成访问操作,这里主要探究分布式锁的问题,所以仅仅模拟了场景
//这里使用自旋的方式,防止访问信息丢失
sellTicket();
return"当前访问人数过多,请稍后访问...";
}
StringticketStr=stringRedisTemplate.opsForValue().get("ticket");
intticket=0;
if(null!=ticketStr){
ticket=Integer.parseInt(ticketStr);
}
if(ticket>0){
intticketNew=ticket-1;
stringRedisTemplate.opsForValue().set("ticket",String.valueOf(ticketNew));
logger.info("当前票的库存为:"+ticketNew);
}else{
logger.info("手速不够呀,票已经卖光了...");
}
stringRedisTemplate.delete(lock);
return"抢票成功...";
}

分析2

上述的代码在程序正常运行下不会出现票超卖的问题,但是我们需要考虑:

1.如果程序运行中系统出现了异常,导致无法删除lock,就会造成死锁的问题。也许有人马上就会想到,使用 try{} finally {} ,在finally中进行删除锁的操作。

但是,如果是分布式架构,第一个服务器接收到请求,加了锁,此时第二个服务器也接收到请求,setnx 命令失败,需要执行return操作,根据finally的特性,执行return之前,需要先执行finally里的代码,于是,第二个服务器把锁给删除了,程序中锁失效了,肯定会出现票超卖等一系列问题。

2.如果程序在运行中直接彻底死了(比如,程序员闲着没事儿,来了个 kill -9;或者断电),就算加了finally,finally也不能执行,还是会出现死锁问题

解决方法:

给锁加一个标识符,只允许自己来操作锁,其他访问程序不能操作锁
还要给锁加一个过期时间,这样就算程序死了,当时间过期后,还是能够继续执行
publicStringsellTicket(){
Stringlock="lock";//锁的键
StringlockId=UUID.randomUUID().toString();//锁的值:唯一标识
try{
//如果成功设置这个值,证明目前该方法并没有被操作,可以进行卖票操作
//添加一个过期时间,暂定为30秒,这里的操作具有原子性,如果过期时间设置失败,键也会设置失败
Booleantag=stringRedisTemplate.opsForValue().setIfAbsent(lock,lockId,30,TimeUnit.SECONDS);
if(!tag){//如果设置失败,证明当前方法正在被执行,不允许再次执行
//实际开发环境应该使用队列来完成访问操作,这里主要探究分布式锁的问题,所以仅仅模拟了场景
//不设置回调的话,访问信息会丢失
sellTicket();
return"当前访问人数过多,请稍后访问...";
}
StringticketStr=stringRedisTemplate.opsForValue().get("ticket");
intticket=0;
if(null!=ticketStr){
ticket=Integer.parseInt(ticketStr);
}
if(ticket>0){
intticketNew=ticket-1;
stringRedisTemplate.opsForValue().set("ticket",String.valueOf(ticketNew));
logger.info("当前票的库存为:"+ticketNew);
}else{
logger.info("手速不够呀,票已经卖光了...");
}
}finally{
//如果redis中的值,和当前的值一致,才允许删除锁。
if(lockId.equals(stringRedisTemplate.opsForValue().get(lock))){
stringRedisTemplate.delete(lock);
}
}
return"抢票成功...";
}

分析3

写到这里已经可以解决大部分问题了,但是还需要考虑一个问题:

如果程序运行的极慢(硬件处理慢或者进行了GC),导致30秒已经到了,锁已经失效了,程序还没有运行完成,这时候,就会有另一个线程总想钻个空子,导致票的超卖问题。

这里我们可以使用 sleep 模拟一下

......
if(ticket>0){
try{
//为了测试方便,过期时间和线程暂停时间都改成了3秒
Thread.sleep(3000);
}catch(InterruptedpythonExceptione){
e.printStackTrace();
}
intticketNew=ticket-1;
stringRedisTemplate.opsForValue().set("ticket",String.valueOf(ticketNew));
......

这样运行就会出现极其严重的超卖问题

那么该如何设置这个过期时间呢?继续加大?这显然是不合适的,因为无论多么大,总有可能出现问题。

解决方法

我们可以使用守护线程,来保证这个时间永不过期

publicStringsellTicket(){
Stringlock="lock";//锁的键
StringlockId=UUID.randomUUID().toString();//锁的值:唯一标识
MyThreadmyThread=null;//锁的守护线程
try{
//如果成功设置这个值,证明目前该方法并没有被操作,可以进行卖票操作
//添加一个过期时间,暂定为3秒,这里的操作具有原子性,如果过期时间设置失败,键也会设置失败
Booleantag=stringRedisTemplate.opsForValue().setIfAbsent(lock,lockId,3,TimeUnit.SECONDS);
if(!tag){//如果设置失败,证明当前方法正在被执行,不允许再次执行
//实际开发环境应该使用队列来完成访问操作,这里主要探究分布式锁的问题,所以仅仅模拟了场景
//不设置回调的话,访问信息会丢失
sellTicket();
return"当前访问人数过多,请稍后访问...";
}

//开启守护线程,每隔三分之一的时间,给锁续命
myThread=newMyThread(lock);
myThread.setDaemon(true);
myThread.start();

StringticketStr=stringRedisTemplate.opsForValue().get("ticket");
intticket=0;
if(null!=ticketStr){
ticket=Integer.parseInt(ticketStr);
}
if(ticket>0){
try{
Thread.sleep(3000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
intticketNew=ticket-1;
stringRedisTemplate.opsForValue().set("ticket",String.valueOf(ticketNew));
logger.info("当前票的库存为:"+ticketNew);
}else{
logger.info("手速不够呀,票已经卖光了...");
}
}finally{
//如果redis中的值,和当前的值一致,才允许删除锁。
if(lockId.equals(stringRedisTemplate.opsForValue().get(lock))){
//程序运行结束,需要关闭守护线程
myThread.stop();
stringRedisTemplate.delete(lock);
logger.info("释放锁成功...");
}
}
return"抢票成功...";
}

/**使用后台线程进行续命
*守护线程
*在主线程下如果有一个守护线程这个守护线程的生命周期跟主线程是同生死的
*/
classMyThreadextendsThread{
Stringlock;
MyThread(Stringlock){
this.lock=lock;
}

@Override
publicvoidrun(){
while(true){
try{
//三分之一的时间
Thread.sleep(1000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
//假设线程还活着,就要给锁续命
logger.info("线程续命ing...");
stringRedisTemplate.expire(lock,3,TimeUnit.SECONDS);
}
}
}

总结

到这里,我们已经基本实现了redis分布式锁,并且可以在高并发场景下正常运行。

需要注意的是,实现分布式锁的代码肯定不是最佳的,重要的是了解分布式锁的实现原理,以及发现问题并解决问题的思路。

到此这篇关于一文让你搞懂如何手写一个redis分布式锁的文章就介绍到这了,更多相关redis分布式锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!