常德网站建设的策划方案,WordPress做app下载,商务网站主页设计公司,上海虹口网站制作一、为什么要使用分布式锁
1.抢劵场景
#xff08;1#xff09;代码及流程图 #xff08;2#xff09;抢劵执行的正常流程 就是正好线程1执行完整个操作#xff0c;线程2再执行。 #xff08;3#xff09;抢劵执行的非正常流程 因为线程是交替进行的#xff0c;所以有…一、为什么要使用分布式锁
1.抢劵场景
1代码及流程图 2抢劵执行的正常流程 就是正好线程1执行完整个操作线程2再执行。 3抢劵执行的非正常流程 因为线程是交替进行的所以有可能线程1查询后线程2再查询。假如现在只有一张票所以线程1会买到这张票并扣除库存现在也就是没有票了。但是线程2查询的时候库存是有一张票的所以也会进行库存扣除变成-1张了。这样就出现了超卖的问题了。 4那怎么解决3的问题呢 1. 首先想到的就是普通的加锁如下图所示 2. 这样会不会出现问题呢当然有可能在实际项目中服务器大部分都是集群部署的因为普通加锁只能解决单个服务器的互斥不能解决多个服务器线程的互斥所以还是有问题。 3. 那应该怎么解决呢就是我们提及到的使用分布式锁这样就可以限制其他服务器也获取锁的问题只有当一台服务器解锁其他服务器才能拿到锁。 二、redis分布式锁
1.核心命令 Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在则 SET)的简写。
2.如何使用 1. 命令设置为什么获取锁要把超时时间一起写上去呢还有为什么一定要设置过期时间呢第一不分开写就是要保证数据的原子性。第二不设置过期时间可能会导致死锁。可以看执行流程图如果服务器宕机会导致锁不能释放造成死锁所以要加过期时间兜底。 2. 执行流程 3.如何控制锁的有效时长呢 1.根据业务执行时间预估。这种方法往往不能保证原子性一般不使用。 2.给锁续期。就是根据执行业务的时长进行锁时长的增加。那自己还需要开一个线程专门来监控实现起来也比较麻烦所以会使用redission实现的分布式锁。
三、redission实现的分布式锁
1.redission实现分布式锁的流程
1流程图 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时就可以删除锁。 关键点必须是在同一个线程才能重入。 3.redission分布式锁的主从一致性
1非正常情况 1. 当主节点宕机。 2. 其中一个从节点会代替主节点。 3. 如果这时线程2也来获取锁因为线程1获取锁后主节点宕机了所以线程2会访问新的主节点获取锁成功。这样会出现两个线程获取同一把锁就有问题了。 2如何解决1的问题 RedLock(红锁)不能只在一个redis实例上创建锁应该是在多个redis实例上创建锁(n / 2 1)避免在一个redis实例上加锁。由于缺点太多了。实际中并不会大量使用redission的红锁。 redisAP思想。 zookeeperCP思想。 所以实际中就是 使用zookeeper来解决主从一致性。 四、面试的时候怎么说
面试官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实现的分布式锁它是可以保证强一致性的。
