redis 分布式锁的引出redission的过程

为什么要用分布式锁：

通常情况下，单tomcat下面实现的服务，我们使用synchronized 或者Reentrantlock 可以锁住一个资源，是因为这个锁是 单tomcat 下jvm 进程级别的锁，而无法跨tomcat 来实现资源锁定。

我们在开发过程中，经常需要在分布式系统的集群架构环境下实现业务，也就是相同一个服务，会存在在多个服务器当中，为了保证数据的最终一致性，需要使用分布式锁来提供支持

单tomcat实例：

单tomcat服务的情况下，我们会使用锁 如下图中的synchronized 来实现多线程的资源安全问题。
但是下面的代码如果出现在多个服务器当中，也就是集群架构，就会出现超卖问题（卖出的数量超过实际存在的数量），两个服务器同时被两个请求访问，同一个数量如40，被同时减去1，余下39会被缓存到redis，然而实际上是被较少了两次。

简单分布式锁 setnx

下图就是分布式锁的一个简单使用，一个线程进来 获取到锁，然后执行完业务之后，释放锁

但是在实际开发时候 我们 并不会这么使用，原因有1、出现异常 锁无法释放 2、锁没有释放就宕机

针对以上问题 对代码做了以下改进，1、增加try catch finally 捕捉到异常

然而 上述的redis分布式锁的使用还是会出现问题，下图给出了极端的场景：
比如第一个线程执行完毕这段业务代码需要15秒，那么根据redis设置的过期时间可知，在第10秒，redis中的锁已经失效了，锁失效导致这时候第二个线程进来了，假设执行完毕这段业务代码需要8秒，那么在执行到第5秒的时候，第一个线程执行到了删除锁的环节，但是其实本身线程设置的锁已经过期了，所以这时候删除的是第二个线程的 锁，第二个线程的锁的消失，导致第三个线程进入到资源，假设执行完毕这段业务代码需要5秒，在执行到第3秒的时候，线程2执行锁删除，

针对上述问题的追究发现问题出现在 ，线程不该删除不属于自己的锁，于是做了下图的修改，让redis 的key随机生成，删除的时候可以只删除自己加的锁。

修改到现在，发现漏掉一种情况，如下图 第一个线程进入到判断并且通过判断，准备释放锁之前，redis锁的过期时间到了，这时候会导致第二个线程获取到锁，然后第一个线程 执行到了 锁删除的部分，把第二个线程的锁给删除了，会导致第三个线程进来。导致线程不安全。

根据上图的问题，发现 redis锁的过期时间是个问题，设置太短可能导致业务没执行完毕就删除锁，设置太长起不到作用。既然这个超时时间当初是为了 担心发生宕机导致锁删除代码无法删除完成的，那其实可以让它尽量不生效，或者说，让它的过期时间随着业务执行时间的增加而增加，啥意思呢，就是可以设置一个线程盯着 redis，比如过10秒发现锁还在 ，就延长10秒过期时间。这样就算宕机，redis的过期时间也不会增加，从而过期时间到了就可以删除锁，同时也不会导致因为业务时间太长，而被redis锁过期导致锁失效。
但是写一个线程来监视redis锁是否存在来完成续期，是不理想的。于是推出了redission。

redission

下两张图（第二张一张图放不下 用两张图放），引入了redisson，之后利用三行代码 成功搞定 上述的所有问题，说白了就是主要搞定了 我们想要实现的写一个线程来定期监视redis锁是否存在，存在则来完成续期的过程，这个过程是有redission底层代码实现的，这篇就不做过多的源码分析。

总结：
第一阶段：setnx （如果宕机，会导致死锁）
第二阶段：setnx+setex（如果业务时间超过过期时间，那么锁会自动丢失，第二个线程介入，线程不安全）
第三阶段：redission （看门狗机制，如查看redis中的锁是否存在，若存在就增加过期时间，知道由业务自己删除）。