redis分布式锁的正确使用姿势

1、分布式锁概述

分布式锁常见的实现方式:

  • 数据库乐观锁
  • 基于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. 线程1,首先执行到10s后,锁(product_001)失效;

  2. 线程2,在第10s后同样进入当前方法,此时加上锁(product_001);

  3. 当执行到15s时,线程1删除线程2加的锁(product_001);

  4. 线程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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

波波老师

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值