前言
在我们的日常开发过程中，一般都会有一些定时任务，在集群环境中为保证定时任务运行在某一台机器上，这个时候就需要使用到分布式锁；另外在一些第三方框架中也会有分布式锁的应用，比如Seata分布式事务中，AT模式的行锁就是存放在TC服务中，一旦抢占到行锁的服务才能够操作对应的表数据，没拿到行锁的服务只能等待锁释放；
在日常开发中，通常会采用redis作为中间存储层来实现分布式锁。
redis分布式锁的几个问题及对应解决方案
一般我们实现的分布式锁伪代码如下，和jvm内存锁差不多：
try{ boolean lock = false; // 上锁 if(lock = tryLock()){ // TODO 执行业务逻辑 } }finally{ if(lock){ // 解锁 unlock(); } } 复制代码
- 锁无法释放问题：
一旦抢占到锁的服务在执行业务逻辑时宕机了，那么该分布式锁就无法解除，其他服务就永远无法抢占到分布式锁；
为了解决抢占锁的服务宕机后导致其他服务无法拿到锁的问题，我们可以给分布式锁设置一个过期时间。伪代码如下：
try{ boolean lock = false; // 上锁，过期时间30秒 if(lock = tryLock(30)){ // TODO 执行业务逻辑 } }finally{ if(lock){ // 解锁 unlock(); } } 复制代码
- 过期时间无法确定
因为我们无法为每个任务提前计算好执行时间，当前我们设置的过期时间是30秒，假如有任何一个任务的执行时间超过了30秒，那么就会导致过期后，有其他的进程抢占了分布式锁，也就意味着同一时间有多个任务在一个分布式锁中，这显然违背了分布式锁的互斥性；
- 加解锁的同源性
如果任务A执行时间过长，任务还没执行完毕，分布式锁就过期了，那么任务B抢占到分布式锁，当任务A执行完毕后，将执行解锁操作，此刻解除的锁是任务B抢占到的锁；
为了解决上述两个问题，我们需要做以下处理：
1.为了在任务执行期间保证分布式锁不过期，我们需要添加一个定时任务检测分布式锁的剩余时间，当ttl还剩10秒时，我们可以给这个分布式锁续到30秒，直至任务执行完毕，该分布式锁被删除；
2.为了解决加解锁的同源性问题，我们在加锁的时候，需要带上相关的业务标签，比如
tryLock(key,taskA,30)表示分布式锁key对应的值是taskA，过期时间为30秒，解锁时unlock(key,taskA)一定要对比此刻锁对应的值一定要时taskA；这样的话，才能保证加解锁的同源性；
所以，我们又可以升级一下我们的伪代码了：
try{ String key = "myLock" String taskName = "taskA"; boolean lock = false; // 上锁，过期时间30秒 if(lock = tryLock(key,taskName,30)){ // TODO 执行业务逻辑 } }finally{ if(lock){ // 解锁 unlock(key,taskName); } } 复制代码
- 可重入性
在我们平时使用的jvm锁synchronized中，同一个线程是可以多次获取锁的，这称为锁的重入，那么我们的分布式锁可不可以实现类似的功能呢？
答案是可以的，我们需要修改底层实现分布式锁的的数据结构为Hash，myLock:taskA:count中myLock代表分布式锁的key，taskA代表对应的对应的Hash结构的key，count代表锁重入的次数，每次重入加1，解锁就减1；
- 原子性
我们在加解锁的过程中，必须保证加锁、解锁操作的原子性，所以我们必须通过Lua脚本来实现上述两个方法；
小结
我们通过伪代码一步一步提出redis分布式锁面临的问题，并同时给出了对应的解决方案，我们下面做出以下几点小结：
- redis分布式锁的加锁、解锁操作必须通过Lua脚本保证原子性；
- 为了保证服务宕机后不会影响其他服务抢占锁，需要设置锁的过期时间；
- 锁的过期时间带来两个问题，一个是无法确定任务执行时间；另一个就是过期后有可能导致加解锁不能保证同源性；
- 加上watch dog机制保证任务没执行完毕，锁不会过期；
- 加锁、解锁都带上对应的值标记，解锁时一定要判断是否和加锁的值一致，保证加解锁的同源性；
- 通过
redis Hash结构实现分布式锁的重入性；
