redis分布式锁的接近完美的解决方案

分布式锁问题出现及其解决方案

 

在分布式环境下多个操作需要以原子的方法执行（如果是单机环境下就只需要JDK锁就行了）

 

实现方式

1.使用SETNX保证设置的key是唯一存在的（如果key存在就不插入，悲观锁）

2.原子操作：incr（将key的value+1）（乐观锁，获取不到就立即返回结果）

 

发散思维，解决可能出现的问题：

1. 在执行业务时，多个并发的请求，导致同个资源被访问被多次执行（加锁）
2. 加锁后，业务并发访问这个线程都返回了失败，只有少部分获取到锁的线程才能处理，这种情况下是非常不通情理的（使用reddison已经内部实现的自旋锁来进行锁的等待，获取不到锁就while循环一直尝试加锁，知道锁的获取成功才返回结果，但是这是悲观锁）
3. 加完锁后，每次获取完锁时就对一个特定值+1，执行完后对特定值进行释放，但是线程拿到锁后，抛出异常时，无法执行最后释放锁操作（加finally块执行释放锁操作）
4. 加了finally块后，这个块中的业务失败了，或者程序挂了，redis连接失败了，无法释放锁（对锁加超时时间）
5. 加了超时时间后，在持有锁这个业务中的执行时间比超时时间长，在业务执行的时候，锁超时释放了，这时，其他的请求的线程就能获取到这个锁了，出现了线程的重复进入
   （对redis锁的key值用一个UUID来设计，同个线程内获取这个锁都需要生成一个唯一的id，释放时只能让同个线程内存放的id匹配释放）
   ，第二个线程执行了业务，而且这个业务执行后，比第一个线程快，并且锁超时解锁解了第一个锁
   （获取到这个锁的时候，另外开辟一个线程，比如超时时间是10秒，这个线程就每5秒就查询一下这个锁是否失效，如果没有失效就增加5秒中，保持这个锁的有效性）
   
   主从redids中，主节点挂掉后进行主从切换后，从节点没法获取已经上锁的进程的锁id进行线程的重新上锁（）