目录
首先引入依赖，配置好信息
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方法，他会尝试去获取每一个节点上的锁，只有都获取成功，才会真正拿到锁
获取锁之后使用方法和以前是一样的。
这样可以确保多节点的一致性，但是缺点就是运维成本较高，实现复杂