基于Redis实现分布式锁

分布式锁

满足分布式系统或集群模式下多进程可见并且互斥的锁

要满足的基本特性：

• 多进程可见
• 互斥
• 高可用：大多数情况下获取锁的动作都应该是成功的，否则会对业务执行造成困扰
• 高性能：获取锁的动作应该快
• 安全性

基于Redis实现

• 获取锁：setnx key value
  • set key value ex 10 nx：将获取锁和设置锁超时时间放在同一条命令中，防止刚获取到锁Redis就宕机了导致死锁
• 释放锁：del key

锁的误删问题

线程1拿到锁，但由于业务阻塞锁超时释放，线程2此时拿到锁，而此时线程1业务执行完毕，直接执行了锁的删除，导致线程3也能拿到锁，此时就有两个线程同时在执行业务

所以在删锁的时候要先判断锁中存的线程标识是否是当前线程的

原子性问题

线程1拿到锁后执行业务完毕，对比完锁中的线程标识和自己的线程标识，正准备释放锁，但此时发生了阻塞（可能是jvm的full gc等问题），锁超时释放，线程2拿到了锁，此时线程1的阻塞结束，释放了锁，线程3又能拿到锁，这样线程2和线程3都在执行业务，产生并发问题

判断锁标识和释放锁的动作应该保证原子性

Redis提供了lua脚本功能，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性。

# redis提供的调用函数
redis.call('命令名称','key','其他参数',……)
#set name jack
redis.call('set','name','jack')
#如果想执行多条命令，如set name jack 再get name
redis.call('set','name','jack')
local name = redis.call('get','name')
return name

#调用脚本
eval "脚本内容" 脚本中需要key类型的参数个数

//Spring data提供的调用Lua脚本的方法
public <T> T execute(RedisScript<T> script, List<K> keys, Object... args) {
    return this.scriptExecutor.execute(script, keys, args);
}

private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;

//将脚本一次加载
static {
    UNLOCK_SCRIPT = new DefaultRedisScript<>();
    UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));//指定脚本路径
    UNLOCK_SCRIPT.setResultType(Long.class);
}

基于Redis的分布式锁优化

基于setnx实现的分布式锁可能存在下面问题

• 不可重入
• 不可重试：获取锁只尝试一次，没有重试机制
• 超时释放：如果业务执行时间比较长，导致锁的释放，也会存在安全隐患
• 主从一致性问题：可能由于主从同步的延迟，在主机宕机后数据未能同步给从机（当然概率极低）

Redisson

一个在Redis基础上实现的Java驻内存数据网络，提供了一系列分布式的Java常用对象，还提供了许多分布式服务，其中就包括各种分布式锁的实现

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.20.1</version>
</dependency>

在RedisConfig中配置客户端

//配置Redisson客户端
@Bean
public RedissonClient redissonClient() {
    Config config = new Config();
    //添加redis地址
    //useSingleServer添加单点地址 useClusterServers添加集群地址
    config.useSingleServer().setAddress("redis://81.70.144.36:6379").setPassword("G211322@Wj");
    return Redisson.create(config);
}

使用Redisson的分布式锁

@Resource
private RedissonClient redissonClient;

@Test
public void test() throws InterruptedException {
    //指定锁的名称获取锁可重入
    RLock lock = redissonClient.getLock("anyLock");
    //获取锁的最大等待时间（期间会重试），锁自动释放时间，也可以使用无参的
    boolean flag = lock.tryLock(1, 10, TimeUnit.SECONDS);
    if (flag) {
        try {
            System.out.println("业务执行");
        }finally {
            //释放锁
            lock.unlock();
        }
    }
}

Redisson可重入锁原理

可以借鉴ReentrantLock实现可重入的原理，ReentrantLock在判断锁已经被占有了之后，会再判断占有锁的这个线程是不是就是自己，如果是，允许再次获取锁，计数器加一，在释放锁时计数器减一。

可以使用hash类型，field存线程标识，value标记锁被该线程占有的次数，Redisson底层也是这样做的。

但是hash类型的操作没有nx这样的命令，所以我们需要手动判断锁是否存在。

可重试原理

Redisson的可重试不是无休止的等待和重试，而是利用Redis的订阅发布和信号量，在锁彻底被释放时，发布一条消息，正在等待重试的线程一旦接收到这样的消息，就会先判断时间是否超出最大等待时间，没有就进行抢锁，期间也会不断校验是否超出最大等待时间。

超时续约

利用watchDog定时任务每隔一段时间就重置超时时间，防止业务没处理完锁就过期了，前提是拿到了锁，锁被释放时也会通过发布订阅通知停止watchDog

主从一致性问题

Redisson的multiLock使用连锁机制，多个独立的Redis节点，必须在所有节点都获取重入锁才算获取锁成功。可以将multiLock看成多个可重入锁的集合