redis分布式锁的正确使用姿势
作者:互联网
分布式锁常见的实现方式:
- 数据库乐观锁
- 基于redis实现分布式锁
- 基于zookeeper实现分布式锁
分布式锁的要求:
- 互斥性
- 安全性:锁只能被持有该锁的用户删除,而不能被其他用户删除
- 不能死锁
- 容错性:当部分节点宕机,客户端仍能获取锁或者释放锁
分布式锁应用场景:
- 库存扣减,防止超卖
2、redis分布式锁
2.1、常见实现方式
2.1.1、实现代码
public String deductStock() {
String lockKey = "product_001";
try {
/*Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "aaa"); //jedis.setnx
stringRedisTemplate.expire(lockKey, 30, TimeUnit.SECONDS); //设置超时*/
//为解决原子性问题将设置锁和设置超时时间合并
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "aaa", 10, TimeUnit.SECONDS);
//未设置成功,当前key已经存在了,直接返回错误
if (!result) {
return "error_code";
}
//业务逻辑实现,扣减库存
....
} catch (Exception e) {
e.printStackTrace();
}finally {
stringRedisTemplate.delete(lockKey);
}
return "end";
}
2.1.2、问题及解决方案
上述代码可以看到,当前锁的失效时间为10s,如果当前扣减库存的业务逻辑执行需要15s时,高并发时会出现问题:
-
线程1,首先执行到10s后,锁(product_001)失效;
-
线程2,在第10s后同样进入当前方法,此时加上锁(product_001);
-
当执行到15s时,线程1删除线程2加的锁(product_001);
-
线程3,可以加锁 .... 如此循环,实际锁已经没有意义;
解决方案:
- 定义一个子线程,定时去查看是否存在主线程的持有当前锁,如果存在则为其延长过期时间
2.2、基于Redission实现方式
2.2.1、Redission简介
Jedis是Redis的Java实现的客户端,其API提供了比较全面的Redis命令的支持。Redission也是Redis的客户端,相比于Jedis功能简单。Jedis简单使用阻塞的I/O和redis交互,Redission通过Netty支持非阻塞I/O。
Redission封装了锁的实现,其继承了java.util.concurrent.locks.Lock的接口,让我们像操作我们的本地Lock一样去操作Redission的Lock。
常用API:
RLock redissonLock = redission.getLock();
redissionLock.lock(30,TmieUnit.SECONDS);加锁并设置锁的存活时间
redissionLock.unLock();解锁
2.2.2、实现原理
- 多个线程去执行lock操作,仅有一个线程能够加锁成功,其它线程循环阻塞;
- 加锁成功,锁超时时间默认30s,并开启后台线程(子线程),加锁的后台会每隔10秒去检测线程持有的锁是否存在,还在的话,就延迟锁超时时间,重新设置为30s,即锁延期;
- 对于原子性,Redis分布式锁底层借助Lua脚本实现锁的原子性。锁延期是通过在底层用Lua进行延时,延时检测时间是对超时时间timeout /3;
2.2.3、简单实现代码
public String deductStockRedission() {
String lockKey = "product_001";
RLock rlock = redission.getLock(lockKey);
try {
rlock.lock();
//业务逻辑实现,扣减库存
....
} catch (Exception e) {
e.printStackTrace();
} finally {
rlock.unlock();
}
return "end";
}
2.2.4、Redission优点
- redisson所有指令都通过lua脚本执行,redis支持lua脚本原子性执行;
- redisson设置一个key的默认过期时间为30s,如果某个客户端持有一个锁超过了30s怎么办?redisson中有一个watchdog(看门狗),它会在你获取锁之后,每隔10秒帮你把key的超时时间设为30s,就算一直持有锁也不会出现key过期而其他线程获取到锁的问题了;
2.2.5、Redisson可重入锁
Redisson存储锁的数据类型是 Hash类型,Hash数据类型的key值包含了当前线程信息。
2.2.6、问题及解决方案
a)主从同步问题
当主Redis加锁了,开始执行线程,若还未将锁通过异步同步的方式同步到从节点,主节点就挂了,此时会把某一台从节点作为新的主节点,此时别的线程就可以加锁了,这样就出错了,怎么办?
解决方案:
- 采用zookeeper代替redis:由于zk集群的特点,其支持的是CP,而Redis集群支持的则是AP;
- redisson 提供了实现了redlock算法的RedissonRedLock;
下面说一下RedLock。
假设有3个redis节点,这些节点之间既没有主从,也没有集群关系,客户端用相同的key和随机值在3个节点上请求锁,请求锁的超时时间应小于锁自动释放时间,当在2个(超过半数)redis上请求到锁的时候,才算是真正获取到了锁。如果没有获取到锁,则把部分已锁的redis释放掉。
RedLock缺点:
- 性能、资源:因为需要对多个节点分别加锁和解锁,而一般分布式锁的应用场景都是在高并发的情况下,所以耗时较长,对性能有一定的影响;
虽然RedLock解决了单点故障问题,但不太推荐使用。如果考虑高可用高并发推荐使用Redisson,考虑一致性推荐使用zookeeper。
b)提高并发:分段锁
由于Redission实际上就是将并行的请求,转化为串行请求,这样就降低了并发的响应速度,为了解决这一问题,可以采用分段的思想提高并发性。
参考文章:
https://mp.weixin.qq.com/s/X2yJlbnWSR3eOQe4ayy3Yg
https://mp.weixin.qq.com/s/M3mEZ-tgwSS5PdX8MnWh0A
https://mp.weixin.qq.com/s/1yT01x32P5kaBFrbA5bzRg
标签:姿势,加锁,redis,Redission,线程,lockKey,分布式 来源: https://blog.51cto.com/u_14643435/2845755