Redis篇之分布式锁

一、为什么要使用分布式锁

1.抢劵场景

(1)代码及流程图

Redis篇之分布式锁_第1张图片Redis篇之分布式锁_第2张图片

(2)抢劵执行的正常流程

        就是正好线程1执行完整个操作,线程2再执行。

                              Redis篇之分布式锁_第3张图片

(3)抢劵执行的非正常流程

        因为线程是交替进行的,所以有可能线程1查询后,线程2再查询。假如现在只有一张票,所以线程1会买到这张票,并扣除库存,现在也就是没有票了。但是线程2查询的时候,库存是有一张票的,所以也会进行库存扣除,变成-1张了。这样就出现了超卖的问题了。

                               Redis篇之分布式锁_第4张图片

(4)那怎么解决(3)的问题呢

        1. 首先想到的就是普通的加锁,如下图所示:

Redis篇之分布式锁_第5张图片Redis篇之分布式锁_第6张图片

       

        2. 这样会不会出现问题呢?当然有可能,在实际项目中,服务器大部分都是集群部署的,因为普通加锁只能解决单个服务器的互斥,不能解决多个服务器线程的互斥,所以还是有问题。

Redis篇之分布式锁_第7张图片

        

        3. 那应该怎么解决呢?就是我们提及到的使用分布式锁,这样就可以限制其他服务器也获取锁的问题,只有当一台服务器解锁,其他服务器才能拿到锁。

Redis篇之分布式锁_第8张图片

二、redis分布式锁

1.核心命令

        Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在,则 SET)的简写。

2.如何使用

        1. 命令设置,为什么获取锁要把超时时间一起写上去呢?还有为什么一定要设置过期时间呢?第一,不分开写就是要保证数据的原子性第二,不设置过期时间可能会导致死锁。可以看执行流程图,如果服务器宕机,会导致锁不能释放,造成死锁,所以要加过期时间兜底。

Redis篇之分布式锁_第9张图片

        2. 执行流程:

Redis篇之分布式锁_第10张图片

3.如何控制锁的有效时长呢

        1.根据业务执行时间预估。这种方法往往不能保证原子性,一般不使用。

        2.给锁续期。就是根据执行业务的时长进行锁时长的增加。那自己还需要开一个线程专门来监控,实现起来也比较麻烦,所以会使用redission实现的分布式锁

三、redission实现的分布式锁

1.redission实现分布式锁的流程

(1)流程图

Redis篇之分布式锁_第11张图片

(2)解释流程图的步骤

        首先,线程1获取锁成功后,采用 watch-dog来检查和更新锁状态,每隔(过期时间/3)的时间续期一次,然后操作redis,手动释放锁后,会通知watch-dog不用监听锁了。

        如果线程2也需要加锁,但是没有获取到锁,则会while循环去尝试获取锁,循环的次数也不是无限的,而是到达一定阈值就停止。也不用担心因为循环而导致获取锁失败,因为在高并发的情况下,业务时长不会太长,所以会在这种情况下可以增加分布式锁的使用性能。这也是分布式锁的一个特性:等待机制

(3)具体代码

public void redisLock() throws InterruptedException{
        //获取重入锁,执行锁的名字(自定义)
        RLock lock = redissionClient.getLock("nameLock");
        try {
            //尝试获取锁,参数分别是:锁的最大等待时间,锁自动释放时间,时间单位
            boolean isLock = lock.tryLock(10,30,TimeUnit.SECONDS);
            //判断是否获取锁成功
            if(isLock){
                //业务代码
            }
        }finally {
            //释放锁
            lock.unlock();
        }
    }

关键点:加锁、设置过期时间等操作都是基于lua脚本完成的,目的是保证数据的原子性

2.redission分布式锁的可重入

(1)例子代码

public void add1() {
        RLock lock = redissonClient.getLock("nameLock");
        boolean isLock = lock.tryLock();
        //执行业务
        add2();
        // 释放锁
        lock.unlock();
    }

    public void add2() {
        RLock lock = redissonClient.getLock("nameLock");
        boolean isLock = lock.tryLock();
        //执行业务
        // 释放锁
        lock.unlock();
    }

(2)如何实现呢

        利用hash结构记录线程id重入次数。其中key就是锁的名字,field就是线程的唯一标识,value就是重入的次数。根据上面代码,add1方法先获取锁后,value的值就是1。然后调用add2方法,add2方法也获取该锁,所以value的值就变成2。然后add2解锁,value就减一变成1。回到add1方法中,释放锁,value再减一,最后value就变成了0。最后当value为0时,就可以删除锁。

        关键点:必须是在同一个线程才能重入。

Redis篇之分布式锁_第12张图片

3.redission分布式锁的主从一致性

(1)非正常情况

        1. 当主节点宕机。

Redis篇之分布式锁_第13张图片

        2. 其中一个从节点会代替主节点。

Redis篇之分布式锁_第14张图片

        3. 如果这时线程2也来获取锁,因为线程1获取锁后,主节点宕机了,所以线程2会访问新的主节点,获取锁成功。这样会出现,两个线程获取同一把锁,就有问题了。

Redis篇之分布式锁_第15张图片

(2)如何解决(1)的问题

        RedLock(红锁):不能只在一个redis实例上创建锁,应该是在多个redis实例上创建锁(n / 2 + 1),避免在一个redis实例上加锁。由于缺点太多了。实际中并不会大量使用redission的红锁。

        redis:AP思想。

        zookeeper:CP思想。

        所以,实际中就是 使用zookeeper来解决主从一致性。

Redis篇之分布式锁_第16张图片

四、面试的时候怎么说

面试官:Redis分布式锁如何实现 ?

候选人:嗯,在redis中提供了一个命令setnx(SET if not exists)

由于redis的单线程的,用了命令之后,只能有一个客户端对某一个key设置值,在没有过期或删除key的时候是其他客户端是不能设置这个key的

面试官:好的,那你如何控制Redis实现分布式锁有效时长呢?

候选人:嗯,的确,redis的setnx指令不好控制这个问题,我们当时采用的redis的一个框架redisson实现的。

在redisson中需要手动加锁,并且可以控制锁的失效时间和等待时间,当锁住的一个业务还没有执行完成的时候,在redisson中引入了一个看门狗机制,就是说每隔一段时间就检查当前业务是否还持有锁,如果持有就增加加锁的持有时间,当业务执行完成之后需要使用释放锁就可以了

还有一个好处就是,在高并发下,一个业务有可能会执行很快,先客户1持有锁的时候,客户2来了以后并不会马上拒绝,它会自旋不断尝试获取锁,如果客户1释放之后,客户2就可以马上持有锁,性能也得到了提升。

面试官:好的,redisson实现的分布式锁是可重入的吗?

候选人:嗯,是可以重入的。这样做是为了避免死锁的产生。这个重入其实在内部就是判断是否是当前线程持有的锁,如果是当前线程持有的锁就会计数,如果释放锁就会在计算上减一。在存储数据的时候采用的hash结构,大key可以按照自己的业务进行定制,其中小key是当前线程的唯一标识,value是当前线程重入的次数

面试官:redisson实现的分布式锁能解决主从一致性的问题吗

候选人:这个是不能的,比如,当线程1加锁成功后,master节点数据会异步复制到slave节点,此时当前持有Redis锁的master节点宕机,slave节点被提升为新的master节点,假如现在来了一个线程2,再次加锁,会在新的master节点上加锁成功,这个时候就会出现两个节点同时持有一把锁的问题。

我们可以利用redisson提供的红锁来解决这个问题,它的主要作用是,不能只在一个redis实例上创建锁,应该是在多个redis实例上创建锁,并且要求在大多数redis节点上都成功创建锁,红锁中要求是redis的节点数量要过半。这样就能避免线程1加锁成功后master节点宕机导致线程2成功加锁到新的master节点上的问题了。

但是,如果使用了红锁,因为需要同时在多个节点上都添加锁,性能就变的很低了,并且运维维护成本也非常高,所以,我们一般在项目中也不会直接使用红锁,并且官方也暂时废弃了这个红锁。

面试官:好的,如果业务非要保证数据的强一致性,这个该怎么解决呢?

候选人:嗯~,redis本身就是支持高可用的,做到强一致性,就非常影响性能,所以,如果有强一致性要求高的业务,建议使用zookeeper实现的分布式锁,它是可以保证强一致性的。

你可能感兴趣的:(redis,分布式,数据库,面试)