Redisson实现分布式锁（看门狗机制）

目录

可重入锁：

 锁重试和看门狗机制：

主从一致性：

---

首先引入依赖，配置好信息

3.使用Redisson的分布式锁

可重入锁：

可重入锁实现是通过redsi中的hash实现的，key依旧是业务名称加id，然后第一个field存储线程唯一标识，value存储上锁的计数，同一个线程获取多次锁通过对锁的计数＋来实现，释放通过-1来实现，当锁的数为零且锁是当前线程的锁的时候才可以释放锁

获取锁的lua脚本如下：

1.首先通关exists去判断这个key是否有锁

2.如果没有锁，则直接获取锁，通过hset命令创建所，通过expire设置过期时间。 

3.如果锁存在，则根据field中存储的线程标识判断是否是当前线程的锁

3.1 如果是自己的，则获得锁，通过hincrby将锁的重入次数加1，并设置有效期

3.2 如果锁不是自己的，则获取失败

释放锁的lua脚本如下：

1.首先判断锁是否被自己持有，根据线程波标识，如果不是自己的，说明已经被释放

2.如果线程是自己的，则判断锁的重入次数是否大于0，

2.1 如果大于0说明不能释放，则对重入次数-1并重置有效期

2.2 如果等于0，则释放锁

 锁重试和看门狗机制：

   获取锁：

1.首先线程进入之后会尝试获取锁，

1.1如果获取成功，且没有设置过期时间，则会自动设置一个看门狗，锁有效期为30s，看门狗会每隔10s去检查线程是否执行完成，如果没有执行完成，则继续续10s时长， 

1.2如果获取锁失败，则进入自旋去不断尝试获取锁，这中间有个判断剩余时间，如果超时，则返回false，如果没超时且拿到了释放锁的信号，则去尝试获取锁

释放锁：

1.线程首先尝试去释放锁，如果释放锁成功，则发送释放锁的消息，并取消看门狗

2.如果失败则记录异常并返回

总结：

可重入：redisson不同于redsi的setnx,他利用hash结构记录线程id和重入次数。

可重试：利用信号量，获取锁失败的会在等待时间内不断重复去获取锁

超时续约：利用看门狗机制，默认30s,每隔10s去判断锁是否释放，如果没释放则续期重置时间，释放则取消看门狗。

那么到这里我们已经解决了三个问题，现在还有主从一致性问题没有解决：

主从一致性：

redis的主从模式是指有一个主节点和多个从节点，主节点负责写操作，从节点负责读操作

主从同步是有一定延迟性的，所以这里需要确保主从的同步

这里就可以设置多个独立节点来实现，redisson封装了一个getMutiLock方法，他会尝试去获取每一个节点上的锁，只有都获取成功，才会真正拿到锁

获取锁之后使用方法和以前是一样的。

这样可以确保多节点的一致性，但是缺点就是运维成本较高，实现复杂