分布式锁，redis锁，执行的过程

分布式锁具备的那些条件

• 互斥性： 在任意时刻只能有一个客户端拥有锁。
• 不会发生死锁，即使有一个客户端持有锁的期间崩溃没有解锁，也不能影响其他客户端的使用。
• 解铃还须系铃人，加锁解锁的必须是同一个客户端。

执行过程

假设有两个服务，服务A 和 服务B 多个也行 ，只是举个例子

step1

首先服务A 去尝试获取锁 ，向redis去发起命令，SET REDIS:LOCK （一个随机值）NX EX 300
这个命令就是存储key并且同时去设置它的过期时间 ，必须要同时去设置过期时间（防止死锁），这是一个保障在存储过后再去设置过期时间中间的时候发生宕机，其他服务去获取锁的时候发生死锁，服务A没法去释放锁，这是一个原子性的命令，同时包含setnx和expire；

这个过期时间，必须有，比如服务A拿到锁之后，发生异常，没有办法去解锁，其他服务无法拿到锁，就会发生死锁；
这里需要一个Watchdog（看门狗） 这个用于续约这个锁过期时间，很重点-- 比如线程A 设置这个锁10秒过期 ，这个时候还没处理完业务 ，就自动删除KEY了 ，这个时候其他线程又去拿到这个锁了，这个时候就出现线程安全问题了，所以也是为了具备一个互斥性；Watchdog是用于每过10s或多少秒去看是否还持有锁，然后进行去延长时间的机制；

step2

这个时候服务A 如果发现KEY已经存在，命令执行失败，说明未能获取锁，这时候可以分两种处理：1. 直接返回失败，获取锁失败-- 2. 循环每过3秒或1秒几秒的去尝试获取锁；没存在，就说明拿到锁然后去处理业务；执行成功就服务A拿到锁；

step3

服务A执行完业务，去释放锁时，服务A 去删除向redis删除KEY，这里在删除KEY之前一定判断解锁的redis存储的VALUE的随机值是否是当前服务A的VALUE是否一致 必须保证解锁的只有锁的持有者去解；这里一般使用lua脚本保持锁的原子性；