Redis分布式锁

关于redis相关基本概念，前文有过具体的描述。

1. 对Redis特性进行一次总结：

1. 支持丰富的数据类型，如String、List、Map、Set、ZSet等。
2. 支持数据持久化，RDB和AOF两种方式
3. 支持集群工作模式，分区容错性强
4. 支持事务
5. 单线程，顺序处理命令

2. Redis实现分布式锁有两种实现方式：

一是使用redis的watch命令进行实现，二是使用redis的setnx（set if not exists）命令进行实现，下文主要对setnx命令进行具体的描述

3. 实现方式

1. set方法中nxx参数为NX，表示当key不存在时才会set值，保证了互斥性;若给定的 key 已经存在，则 SETNX 不做任何动作
2. set值的同时设置过期时间（过期后del此key），客户端宕机或网络延迟时不会一直持有锁，避免了死锁发生;
3. set方法中的value，比如UUID之类的，用来表示当前请求客户端的唯一性标识;
4. 因为是redis单例，暂时没有考虑容错性;

4. 可能出现的问题：

1. 加锁后，业务并发访问这个线程都返回了失败，只有少部分获取到锁的线程才能处理，这种情况下是非常不通情理的
   使用reddison已经内部实现的自旋锁来进行锁的等待，获取不到锁就while循环一直尝试加锁，知道锁的获取成功才返回结果，但是这是悲观锁

2. 加完锁后，每次获取完锁时就对一个特定值+1，执行完后对特定值进行释放，但是线程拿到锁后，抛出异常时，无法执行最后释放锁操作
   加finally块执行释放锁操作

3. 加了finally块后，这个块中的业务失败了，或者程序挂了，redis连接失败了，无法释放锁（
   对锁加超时时间

4. 加了超时时间后，在持有锁这个业务中的执行时间比超时时间长，在业务执行的时候，锁超时释放了，这时，其他的请求的线程就能获取到这个锁了，出现了线程的重复进入
   对redis锁的key值用一个UUID来设计，同个线程内获取这个锁都需要生成一个唯一的id，释放时只能让同个线程内存放的id匹配释放

5. 第二个线程执行了业务，而且这个业务执行后，比第一个线程快，并且锁超时解锁解了第一个锁
   获取到这个锁的时候，另外开辟一个线程，比如超时时间是10秒，这个线程就每5秒就查询一下这个锁是否失效，如果没有失效就增加5秒中，保持这个锁的有效性

6. 线程如果获取分布式锁失败，为什么不尝试重新获取锁?
   Redis的SETNX命令，如果key已经存在，则不会做任何操作，所以SETNX实现的分布式锁并不是可重入锁。当然，也可以自己通过代码实现重试n次或者直至获取到分布式锁为止。但是，这不能保证竞争的公平性，某个线程会因为一直等待锁而阻塞。因此，Redis实现的分布式锁更适用于对共享资源一写多读的场景。

7. 程获取分布式锁成功后，设置了锁的失效时间，这个失效时间长短如何确定？
   分布式锁必须设置失效时间，而且失效时间必须大于业务处理所需的时间（保证数据一致性）。所以，在测试阶段尽可能准确的预测出业务正常处理所需的时间，设置失效时间是防止因为业务处理过程的某些原因导致死锁的情况。