一、分布式锁的模型
（一）悲观锁： 认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。例如Synchronized、Lock都属于悲观锁。
- 优点： 简单粗暴
- 缺点： 性能略低
（二）乐观锁： 认为线程安全问题不一定会发生，因此不加锁，只有在更新数据时判断有没有其他线程对数据做了修改，如果没有修改则认为是安全的，自己才能更新数据；如果已经被其它线程修改，说明发生了安全问题，此时可以重试或异常。
- 优点： 性能好
- 缺点： 存在成功率低的问题
（三）常见的实现方式：
- 版本号法： 通过 id-stock-version结构，通过查询的version与本次是否相同来判断是否被修改。
- CAS法： 是版本号法的改良版，是用 old-query-new的结构，通过第一次query出来的stock，与第二次提交的stock是否一致，若一致则 old = new;
二、Redis的分布式锁
（一）分布式锁的作用： 作为公用JVM锁监视器，集群中的每台JVM都能获取锁监视器监测的线程，多个JVM内部同步了线程执行。
（二）分布式锁的需求： 多进程可见、互斥、高可用、 高性能、安全性…
（三）常见分布式锁的差异：
| MySQL | Redis | Zookeeper | |
|---|---|---|---|
| 互斥 | 利用mysql本身的互斥锁机制 | 利用setnx这样的互斥命令 | 利用节点的唯一性和有序性实现互斥 |
| 高可用 | 好 | 好 | 好 |
| 高性能 | 一般 | 好 | 一般 |
| 安全性 | 断开连接，自动释放锁 | 利用锁超时时间，到期释放 | 临时节点，断开连接自动释放 |
（四）Redis实现分布式锁
1、获取锁:
-
互斥： 确保只有一个线程获取锁。
SETNX lock thread1
2、释放锁
-
手动释放：
DEL lock -
过期释放：
EXPIRE lock 5
（1）通过 SET 操作 实现原子性操作： SET lock thread1 EX 10 NX，意思是创建一个lock缓存，值为thread1，保持10s时间，NX为互斥操作
（2）当锁获取失败时的方法：
- 阻塞式获取锁： 一直等待到有线程释放锁。（对CPU资源消耗高）
- 非阻塞式获取锁： 失败就不再尝试获取锁。
3、代码实现分布式锁
（1）需求： 定义一个类，实现Redis分布式锁功能。
public class SimpleRedisLock implements ILockService {
private static final String LOCK = "lock:";
private String threadName;
private StringRedisTemplate redisTemplate;
public SimpleRedisLock() {
}
public SimpleRedisLock(String threadName, StringRedisTemplate redisTemplate) {
this.threadName = threadName;
this.redisTemplate = redisTemplate;
}
@Override
public boolean tryLock(long timeoutSec) {
//1、获取锁
Boolean absent = redisTemplate.opsForValue().setIfAbsent(LOCK + threadName, String.valueOf(Thread.currentThread().getId()), timeoutSec, TimeUnit.SECONDS);
return Boolean.TRUE.equals(absent);
}
@Override
public void unlock() {
//2、解锁
redisTemplate.delete(LOCK + threadName);
}
}
四、基于Redis的分布式锁优化——Redisson对象
（一）基于setnx实现的分布式锁存在的问题
- 不可重入： 同一个线程无法多次获得同一把锁
- 不可重试： 获取锁只尝试一次就返回false，没有重试机制
- 超时释放锁： 锁超时释放，虽然可以避免死锁，但在业务耗时过长，也会导致锁释放，存在安全隐患。
- 主从一致性： 如果Redis提供了主从集群，主从同步存在延迟，当主宕机时，如果从同步主中的所数据，则会出现锁实现。
（二）实现分布式锁的常用对象——Redisson
1、概念： Redisson是一个Redis的基础上实现的Java驻内存数据网络（In-Memory Data Grid）。提供了一系列分布式的Jav常用对象，还提供了许多分布式服务，其中包含了各种分布式锁的实现。
2、分布式锁的种类 官网地址： https://redisson.org
-
分布式锁（Lock）和同步器（Synchronizer）
- 可重入锁（Reentrant Lock）
- 公平锁（Fair Lock）
- 联锁（Multi Lock）
- 红锁（Red Lock）
- 读写锁（ReadWrite Lock）
- 信号量（Semaphore）
- 可过期性信号量（PermitExpirableSemaphore）
- 闭锁（CountDownLatch）
3、Redisson的基本使用
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.13.6</version>
</dependency>
@Configuration
public class RedisConfig {
@Bean
public RedissonClient redissonClient() {
//配置类
Config config = new Config();
//连接redis
config.useSingleServer().setAddress("redis://192.168.92.131:6379").setPassword("123321");
//创建客户端
return Redisson.create(config);
}
}
@Resource
private RedissonClient redissonClient;
@Test
void testRedisson() throws InterruptedException {
// 获取锁（可重入），指定锁名称
RLock lock = redissonClient.getLock("anyLock");
// 尝试获取锁，参数分别是： 获取锁的最大等待时间（期间会重试），锁自动释放时间，时间单位
boolean isLock = lock.tryLock(1, 10, TimeUnit.SECONDS);
// 判断释放获取成功
if(isLock){
try{
System.out.println("执行业务");
}finally{
//释放锁
lock.unlock();
}
}
}
4、Redisson可重入锁原理
（1）可重入锁是什么？
可重入锁是指一个线程可以多次获取一把锁的锁获取机制。
（2）ReentrantLock可重入原理
当线程获取锁时，如果有线程占用锁，就检查该线程是否是自己本身，若是自己则再一次尝试获取锁，每执行一次尝试获取锁，就会有个重入计数器记录线程重入的次数，在本次方法执行结束后释放锁，重入计数器相应减一，直到整个方法执行完，才能完整的将锁释放掉。
（3）基于Redis的可重入锁的实现方式
流程： 判断锁是否存在（若不存在，则获取锁并添加线程标识，设置锁有效期，执行业务，执行完毕后依旧需要判断锁的归属以及锁计数状态） 》判断锁标识是否是自己（若是，则锁计数+1） 》 若不是，获取锁失败 》
lua脚本
local key = KEYS[1];
local threadId = ARGV[1];
local releaseTime = ARGV[2];
--1、判断当前锁是否是自己
if (redis.call("HEXISTS", key, threadId) == 0) then
-- 不是，则直接返回
return nil;
end
-- 如果是，则计数器-1
local count = redis.call("HINCRBY", key, threadId, -1);
--2、判断统计数是否为0
if (count > 0) then
-- 统计数不为零，则重置计时器
redis.call("expire", key, releaseTime);
else
--统计数为零，则释放锁
redis.call("del", key);
return nil;
end
5、multiLock，主从一致性
（1）产生原因： 多台Redis，主节点主要存储最新的数据，从节点需要同步数据，在数据同步过程中，会产生延时，因为某些异常导致了主节点宕机了，从节点的数据就不一致并且因为锁对象锁定的redis宕机了，所以锁就失效了，产生了之前所提到的所有分布式安全问题。
（2）解决方法： 联锁机制。
（3）联锁机制的主从一致性的解决方式： 通过获取Redis集群的所有锁，只有获取了Redis集群的所有锁才能进行数据更新。
（4）Redssion的联锁： MultiLock
6、Redisson的锁重试以及WatchDog机制
（1）Redisson的锁重试机制的基本流程： 可自行查看RedissonLock类的重试锁机制和释放锁机制
- 将等待时间，释放时间，统一转换为毫秒级
- 第一次尝试获取锁（若返回的TTL为null，说明获取到了）
- 判断是否获取锁（阻塞等待结果返回）
- 判断锁释放时间是否为默认（传参了-1，表示默认），若为默认则使用WatchDog监控时间（30s），否则以传入的参数为准
- 使用异步释放函数，函数里包含了可重入锁实现的脚本（结果返回到一个Future类）
- 判断是否获取锁（阻塞等待结果返回）
- 若未获取到锁，则将等待时间减去获取锁的那段时间，并且加以判断等待时间是否不足（若不足，则放弃重试返回错误信息）
- 订阅当前尝试获取锁的线程标识（阻塞等待剩余等待时间，若还是没有释放锁的信号，则取消订阅并返回错误信息），当释放锁脚本中
publish命令执行后，开始进行锁获取 - 订阅到锁信号
- 判断等待时间是否充足（等待时间先被减去等待信号的时间，计算结果若小于零，则返回错误信息）
- 若充足，则循环尝试获取锁，直至锁成功获取，或等待时间不足返回错误（循环尝试并不是一直循环，只有在获取到锁信号的时候才会尝试获取）
三、分布式锁使用过程中的相关问题
（一）数据超量修改
1、产生原因： 由于多线程的参与，功能模块的方法之间执行顺序就会有差异，那么当多个线程由于操作顺序不同可能都查询到了库存还有剩余，都会去执行扣减库存的操作，这样原本库存数 < 请求线程数，就造成了库存直接变负的情况。
2、解决方案： 加锁，保持用户访问时持有锁才能修改操作。
3、加乐观锁和加悲观锁对问题解决效果
（1）加乐观锁： 由于是通过对更新前后数据变化进行判断是否能够更新数据，同时访问的线程，在线程 a 访问更新后，线程 b 由于更新前后访问的数据不一致，导致线程更新失败，同时在同一时期访问的线程全部失败，所以它的效率会极差，但依旧可以完成业务。
（2）加悲观锁： 由于线程 a 获得了锁，进入了访问更新阶段，但线程 b 并未获取锁而阻塞，若因为没有锁重试机制，可能会导致大量线程失败，相较于乐观锁的方式，成功率显然有所提升，并且其安全性也获得了提升，不会因为同一个用户的多次相同请求而多次更新。
（二）集群状态下，锁功能失效
1、产生原因： JVM内部维护了一个锁监视器，在同一个userid下，认为这个线程是同一个线程，但是当有两个或更多的JVM集群出来，而锁监视器并没有锁定同一个线程，所以才会有并发安全问题。
2、解决方案： 采用分布式锁
（三）业务阻塞导致锁超时释放
1、原因： 线程被阻塞，分布式锁超时被释放，导致线程运行混乱。
2、解决方法： 在业务完成后，先检查锁的标识是否一致，再判断是否释放锁。
（四）超时释放锁
1、产生原因： 由于JVM的垃圾回收机制，线程在释放锁之前可能会遭遇阻塞，造成超时释放锁
2、解决方法： 将判断表示与释放锁形成原子性。
3、实现方法： 使用Lua脚本，编写多条Redis，保证Redis命令的原子性。
3、Lua脚本的使用方法： Redis提供了一个回调函数，可以调用脚本。文章来源：https://www.toymoban.com/news/detail-619280.html
EVAL "return redis.call('set', KEYS[1], ARGV[1])" 1 name Rose
4、释放锁的业务流程文章来源地址https://www.toymoban.com/news/detail-619280.html
- 获取锁中的线程标识
- 判断是否与指定标识（当前线程标识）一致
- 如果一致则释放锁（删除）
- 如果不一致则什么都不做
到了这里，关于Redis学习路线（6）—— Redis的分布式锁的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
