进程锁有什么弊端？

当遇到集群架构时，进程锁就不能保证数据的安全；

例如售出减库存时，连个进程的请求拿到的库存数都是100，都-1后库存数应该是98 ，但是这种情况库存数就会更新成99，出现超卖的问题。

如何解决

使用Redis的setnx实现一把分布式锁，只有能拿到锁的进程才可以扣减库存。

这样使用有什么问题？

如果在业务层面出现了异常，锁永远都释放不了，就会出现死锁

解决方法： try catch finally
这样解决后第二个问题是，如果代码执行到一半服务器宕机了，那么也会造成死锁问题

解决方法：设置超时时间

第三个问题是，这样操作是有原子问题的，可能在两行代码之间还会出现宕机情况，出现死锁

解决方法：使用redisTemplate自带的原子操作

第四个问题是业务处理时间超过设置的超时时间，导致锁失效，另一个进程获取锁还没有完成业务逻辑，第一个进程就把锁给释放掉了，所以问题点在解锁上，自己的锁被其他进程释放掉了。

解决方法：生成一个唯一ID，将分布式锁的value设置为ID，解锁时判断是否是自己的锁

第五个问题是， if逻辑和解锁不是原子操作，过期时间在临界区时如果业务执行完if逻辑有可能导致锁过期，下一个进程拿到锁后马上又被第一个进程给释放掉了。

锁续命：开启一个新的线程来定时监控锁是否被释放，如果没有被释放掉就将超时时间重置，这个时间一定是比超时时间要小

## Redisson解决分布式锁

引入redisson依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.6.5</version>
</dependency>

将Redisson注入到Spring中

@Bean
public Redisson redisson(){
    Config config = new Config();
    config.useSingleServer().setAddress("redis://localhost:6379").setDatabase(0);
    return (Redisson) Redisson.create(config);
}

使用Redisson分布式锁

RLock lock = redisson.getLock(lockKey);
try {
    lock.lock();
    System.out.println("locked");
}finally {
    lock.unlock();
}

Redisson分布式锁流程图

Redisson分布式锁是怎么实现的？

我们来分析一下源码

当调用lock.lock();时，会调用RedissonLock的lockInterruptibly方法，注意leaseTime默认是-1

核心逻辑在tryAcquire方法中，然后调用tryAcquireAsync方法

最终调用tryLockInnerAsync方法

我们发现字符串中有一堆代码，这个其实是Lua脚本

所以redisson分布式锁使用lua脚本实现了加锁逻辑

那么什么是Lua脚本？

Lua脚本

Redis在2.6版本退出了脚本功能，允许开发者将Lua脚本传到Redis执行。

可以使用EVAL命令对Lua脚本进行处理，格式如下：

EVAL 被执行的脚本 键数量 key [key ...] arg [arg ...]
# 示例:
EVAL "return {KEY[1],KEY[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"