在很多互联网产品应用中,有些场景需要加锁处理,比如:秒杀,全局递增ID,楼层生成等等。大部分的解决方案是基于DB实现的,Redis为单进程单线程模式,采用队列模式将并发访问变成串行访问,且多客户端对Redis的连接并不存在竞争关系。其次Redis提供一些命令SETNX,GETSET,可以方便实现分布式锁机制。
踩坑1. 数据库事务超时
不要感觉奇怪,分布式锁怎么会导致数据库事务超时呢? 我的代码大概是这样的:
伪代码
@Transaction(readOnly=false)
void update(){
do{
redis=JedisUtil.getJedis();
flag = getLock(key,redis);
if(flag){
update();
}
}while(true)
}
当你的key长时间获取不到锁,并且数据库事务都有超时时间的限制,那么就会出现数据库事务超时问题; 解决方案
❝
数据库事务改为手动提交事务;
踩坑2. redis key过期,而业务没有执行完
我的key的过期时间设置的是30s,如果30秒业务还没有执行完毕,锁就会自动释放,锁释放之后,其它线程又会去占用锁,同样会导致问题的发生; 解决方案
❝
最简单的解决方案就是使用redisson; 如果非要用redis来解决的话,只能使用定时器去检测key,如果说key还有2秒就快过期了,那么再为key重新设置30秒的过期时间;
踩坑3. redis连接池爆满
分布式锁刚加上之后,生产出现一个问题,就是:redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool 解决办法 开始查代码,发现是开发人员没有对连接进行释放;
修复bug之后,又在线上跑了一段时间,又出现了redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool 解决办法
void update(){
do{
redis=JedisUtil.getJedis();
flag = getLock(key,redis);
if(flag){
update();
}else{
// 释放当前redis连接
// 由于我们的业务场景属于比较耗时的业务型,所以在这里休眠1000毫秒
redis.close();
sleep(1000);
}
}while(true)
}
1.当前请求获取锁,如果获取不到,则释放当前连接,并休眠一会; 2.合理配置redis连接池大小,主要参考具体业务场景的并发量来设置;
踩坑4. 解铃还须系铃人
回顾一下加锁的参数:
set(key, vlue,"NX","PX", 30000);
其中:value,我使用它来表示加锁人,必须是一个唯一的标识
❝
比如: A线程 key=test value=01 B线程 key=test value=02
如果A线程执行业务耗时超过了锁的持有时间,锁会自动释放;锁自动释放之后,线程B又加锁成功,但是,此时A线程执行完业务逻辑之后,去释放锁,但A线程的锁已经自动释放了,如果没有value来标识的话,它可能就会去释放B线程的锁;
踩坑5. redis集群实现分布式锁
❝
这种情况我没有遇到,因为公司的redis集群做了改进;
先说一下这种问题产生的原因: 如果master节点由于某原因发生了主从切换,那么就会出现锁丢失的情况;
解决办法
❝
需要通过使用redlock算法; 或使用redisson,它有对redlock算法做封装;
以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !