Redis实现分布式锁

一、使用分布式锁的背景是什么

1、如果你公司的业务，各个应用都只部署了一台机器，那么完全用不着分布式锁，直接使用Java的锁即可

2、可是当你们的业务量大，多台机器并发情况下争夺一个资源的时候，就必须要保证业务的原子性了。

举例：

例子1、超卖问题：一共100个商品待抢购，当还有最后一个库存的时候，实例1,2,3.....10都查询到还有库存，用户同时都下单成功；那么就出现了超卖问题：你一共100的库存，哪来的110个商品发货？

怎么解决呢？将100个商品写入redis中，并加上分布式锁，必须一个实例，拿到锁，并完成交易，扣除库存后，释放锁，才能让下一个实例拿到锁；这样就保证了不会超卖

例子2、定时任务问题：多台分布式应用，要执行对账，如果多台机器同时执行，就有可能产生脏数据；如果使用分布式锁，使同时只有一个应用实例去执行一个任务，这样就实现了互斥，不会导致脏数据产生

二、Redis分布式锁，是如何实现的？

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

获取锁：

#添加锁，lock是锁的名称，value就是值（根据业务命名） NX代表互斥，EX是设置超时时间
SET lock value NX EX 10

释放锁：

# 释放锁，删除即可
DEL key

分布式锁必须加超时时间的原因是，如果应用获取到锁后，宕机了，那么就永远释放不了锁了

三、Redisson实现分布式锁，如何控制锁的有效时长？

如果应用使用了分布式锁，但是在锁的有效时间都超过了（锁失效了），那么应用的其他实例就会拿到锁，也去执行业务代码，就有可能会导致脏数据产生

那么如何合理控制锁的有效时长呢？

1、根据业务预估

根据业务代码评估后，觉得实例拿到锁之后，多久能跑完，就给锁设值多久过期

但是这样很不准确

2、动态地给锁续期

我只要拿到锁的线程还在跑，那我就一直给锁加有效时间（超时时间）即可，每次加10秒钟，诶，非常合理

有以下两种方式：

1、自己代码里新开一个线程，每隔10秒或者多少秒，延长一下锁的有效时间（过期时间）

或者说，在数据库标记一个标识，新开一个线程记录当前线程id + 状态，根据状态判断是否需要延期

2、使用Redisson的看门狗机制

Redisson自带有一个watch dog（看门狗机制），

如图所示，

1、实例1在获取到锁后，在加锁后，Redisson会另外开一个线程（看门狗线程），监控持有锁的线程，会不断增加持有锁的线程的持有锁的时间（超时时间，默认10秒）

看门狗线程，每次续期（release / 3）的时间，其中release是锁的默认超时时间：30s，也就是说默认10秒钟续期一次，每次重新设置为30秒过期时间

当实例1释放锁的时候，需要通知一次看门狗，不需要再做监听了，因为key已经被删除了

2、在实例2，尝试加锁的过程中，如果加锁失败，会循环，尝试获取锁；

当然实例2也不会无限循环尝试获取，一段时间没有加锁成功就会报错，这就是Redisson新增的重试机制

public void redisLock() throws InterruptedException{// 获取锁（重入锁），执行锁的名称RLok lock = redissonClient.getLock("myLockName");// 尝试获取锁，参数分别是：1、获取锁的最大等待时间（就是未获取到锁循环尝试获取的时间）// 2、锁自动释放时间（过期时间），如果你设置了这个值，那么Watch dog（看门狗）就不会生效，因为他会认为你能控制锁的超时时间，不会定时给你续期// 3、第三个参数为 前两个时间参数的单位// boolean isLock = lock.tryLock(10, 30, TimeUnit.SECONDS);boolean isLock = lock.tryLock(10, TimeUnit.SECONDS);// 判断是否获取锁成功if(isLock) {try {System.out.prientln("执行你的业务逻辑");} finally {// 释放锁lock.unlock();}}
}

所有的加锁解锁，设置过期时间，看门狗续期等，都是根据lua脚本来实现的，保证执行的原子性