让我来告诉你redis为什么要用分布式锁,以及到底怎么用?

愿天堂没有BUG

共 3301字,需浏览 7分钟

 ·

2021-03-27 00:50

前言

白嫖掘金很久了,最近学习了redis分布式锁的相关的知识,决定还是写一篇文章分享给大家,一是加强自己的记忆,二是希望能够给想了解相关知识的朋友一点思路。本文将使用nginx和2个集群的微服务来给大家展示为啥要用分布式锁,以及后面一步步的分析加锁的过程中会出现的问题。

简单的demo程序

这里有一个简单的demo程序,就是一个controller调用一次就操作一次redis减少一个库存

@RestController
public class GoodController {
@Autowired
private StringRedisTemplate stringRedisTemplate;

@Value("${server.port}")
private String serverPort;

@GetMapping("/buyGoods")
public String buyGoods() {
String result = stringRedisTemplate.opsForValue().get("goods");
int goodsNumber = result == null ?0 : Integer.parseInt(result);
if(goodsNumber > 0) {
int realNumber = goodsNumber - 1;
stringRedisTemplate.opsForValue().set("goods", String.valueOf(realNumber));
System.out.println("成功买到商品,库存还剩下" + realNumber + " 件" + "\t 服务提供窗口" + serverPort);
return "成功买到商品,库存还剩下" + realNumber + " 件" + "\t 服务提供窗口" + serverPort;
} else {
System.out.println("商品已经售完/活动结束/调用超时,欢迎下次光临" + serverPort);
}
return "商品已经售完/活动结束/调用超时,欢迎下次光临" + serverPort;
}
}

复制代码

其他配置类就不贴了,主要就是这么一个功能。然后同样的代码,复制到另一个项目中。起两个微服务做集群。唯一区别就是一个端口是1111 另一个端口是2222

接着利用nginx转发和负载均衡 nginx的配置如下

upstream mynginx{
server 127.0.0.1:1111 weight=1;
server 127.0.0.1:2222 weight=1;}
server {
listen 80;
server_name localhost;

#charset koi8-r;


#access_log logs/host.access.log main;


location / {
proxy_pass http://mynginx;
index index.html index.htm;
}
复制代码

做了一个轮询的负载均衡。

然后用JMeter创建一百个线程一秒钟 请求进来。



对比控制台打印的结果,很明显的看到出现了一个商品被多次售卖的情况

解决方案

考虑给redis上锁,现在生产上成熟的方案是直接用redisson。咱们先不用这个,就直接用redis的String setnx来上锁,然后分析有什么问题,以及redisson的出现到底解决了生产众的什么问题

首先是加锁,代码如下


结果如下



看了一下,没有出现一个商品被多次售卖的情况。这里加锁的想法是这样的,定义一个常量就是锁的名称,当作是key,然后利用 setIfAbsent 这个方法的返回,key不存在就创建返回true,存在就返回false。然后自己用玩了,就删除这个key。

ok看起来一切正常,没有什么问题。但是,真的是这样吗?

1、当你获取锁之后,如果你接下来的业务处理报异常了,是不是不能成功的删除key,然后其他线程就一直都不能获取锁了,对吧。类似与 文件流、或者锁。你用的时候一定要保证释放。所以咱们在删除key的地方加上finally

2、极端情况下,程序刚刚走到获取锁,然后程序突然宕机了,根本走不到finally,没办法保证解锁这时候怎么办?是不是可以考虑给这个key加上一个过期时间?
stringRedisTemplate.expire(REDIS_LOCK, 10L, TimeUnit.SECONDS); 加上这个代码,给redis设置一个过期时间,这样就能保证key能自动删除了

3、上面的代码变成了这样


这里还有一个问题是什么,建key和设置过期时间,这是两行代码,没有保证原子性,在高并发的情况下还是会出问题。所以图中的两行代码可以合并成一行 Boolean flag =
stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK,value,10L, TimeUnit.SECONDS);这样就保证了创建key和设置过期时间的原子性

4、在这里,我们给这个key设置的过期时间是10秒。如果我们的业务处理时间超过了10秒,会出现什么情况?A线程自己的key已经被删除,B线程建了一个key。然后A处理完业务以后他自己的key已经超时。然后执行删除key的时候会发生什么?会删除B线程的key,然后B删除的时候会删除C的key,就这样全乱了。所以这里我们删除key这么写


比较这个value相等才能保证删除的是自己的key

5、到这一步了,还有问题吗?有的。上面finally里面的判断和删除锁,也不是原子的。怎么办,官方早就给了相关的解决方法。


没错,就是lua脚本。直接上代码


6、到这里基本上就没啥问题了,还有一点需要解决的是:我们如何能够保证key的过期时间大于业务的执行时间。有人说:我设置一个很大的过期时间,可以吗?可以!这不就和上面说的第二条冲突了吗?所以最好的情况还是有效期能够有自动续期的功能。还有个问题是,目前我们都说的是单机的redis,生产中,你大概率会用到集群,主从哨兵模式。cap中redis属于是ap高可用,并不是强一致性的。情况再极端一点,key写入了主服务器,还没有完成同步,主服务器挂了,这时候选举出来的新主没有这个key的信息怎么办?集群环境下,自己写的这个锁还是不保险。

7、redisson闪亮登场了。配置文件增加


这里是上的单机,也可以配置集群。

核心代码在这里



结语

这里通过首先自己写一个redis锁,一步步的分析问题以及最终的解决方案。至于redisson为什么能够解决上面的这些问题,还有key自动续期的问题。立一个flag,51之前看源码,弄清楚,然后再分享出来。最后还有一个问题,关于上面提到的第五点,获取和解锁原子性的问题,如果不让你用lua脚本,你有其他办法解决吗?


作者:TheChosenOne
链接:
https://juejin.cn/post/6938671503282192414

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

浏览 103
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报