让我来告诉你redis为什么要用分布式锁,以及到底怎么用?
共 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给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。