真正的Redis分布式锁，就该是这样实现的

　　众所周知，redis分布式锁使用SET指令可以实现，但是仅仅使用该命令就行了吗？是否还需要考虑CAP理论。
　　要是有上面说的那么简单就好喽，我们平时在开发中用到的分布式锁方案可能比较简单，这个取决于业务的复杂程度以及并发量。
　　下面我们来说说在高并发场景中，该如何正确使用分布式锁。
　　在正式讲解分布式锁之前，先来看下将要围绕展开来讲的几个问题：
　　什么场景使用分布式锁？
　　在同一时刻，只能有一个线程去读写一个【共享资源】，也就是高并发的场景下，通常为了保证数据的正确，需要控制同一时刻只允许一个线程访问。
　　此时就需要使用分布式锁了。
　　简而言之，分布式锁就是用来控制同一时刻，只有一个线程可以访问被保护的资源。分布式锁的特性无死锁：都有机会获得锁，即使获取锁的客户端挂掉；互斥：在任何的某一时刻，只有一个线程可以持有锁；
　　可以使用SETNXkeyvalue命令实现互斥的特性。
　　解释下：如果key不存在，则设置value给这个key，否则啥都不做。
　　该命令的返回值有如下两种情况：1：表示设置成功；0：表示key没有设置成功。
　　举例如下：
　　成功的情况：
　　SETNXlock：1011（integer）1获取101锁成功
　　失败的情况：
　　SETNXlock：1012（integer）0后面申请锁获取失败
　　可见，成功的就可以开始使用共享资源了。
　　使用结束后，要及时释放锁，给后面申请获得资源的机会。
　　那么该如何释放锁呢？
　　释放锁比较简单，使用DEL命令删除这个key就可以了。如下：
　　DELlock：101（integer）1
　　分布式锁简单使用方案如下：
　　这看起来不是挺简单的吗，能有什么问题？往下听我分析。
　　首先该方案存在一个锁无法被释放的问题，场景如下：服务重启了，导致无法正常释放锁；业务逻辑异常，无法执行DEL指令。
　　可见，这个锁就会一直被占用，导致其它客户端也拿不到这个锁了。key设置过期时间
　　优化一点：可以考虑在获取锁成功的时候给key设置一个过期时间
　　设置举例如下：
　　SETNXlock：1011获取锁（integer）1
　　EXPIRElock：1016060s过期删除（integer）1
　　可见，60秒后后该锁就好释放掉，其他客户就可以申请使用了。
　　说实话，这种写法太low了，仍然存在问题。
　　由上面举例可知：加锁和设置过期时间是两个操作命令，并不是原子操作。
　　试想一下，可能存在这么个情况：
　　比如执行第一条命了成功，第二条命令还没来得及执行就出现了异常，导致设置过期时间失败，这样锁也是无法释放。
　　不要慌，Redis2。6。X之后，官方对SET命令的参数进行了扩展，即key不存在的时候设置value，同时设置过期时间，这样就可以解决以上说到的问题了，即满足了原子性。
　　SETkeyNamevalueNXPX30000NX：表示当keyName不存在的时候才SET成功，从而可以成功获得锁；PX30000：表示获得的锁有设置30秒的过期时间。
　　这样一看，似乎没啥毛病。不，仔细一看，写的还是不够严谨。想下，有没可能释放的不是自己加的锁。
　　思考中释放的锁不是自己的
　　说下什么场景下，释放的锁不是自己的：A获取锁成功并设置过期时间30秒；A由于不知什么原因执行比较慢（有可能是网络延迟问题、此时正在GC等），30秒过后还没执行完，但是锁已经过期释放了；B此时过来申请加锁成功；接着A开始执行DEL释放锁指令，这个时候就会把B的锁释放了。
　　所以，有个关键点需要注意的是：只能释放自己申请的锁。
　　总之，解铃还须系铃人解决释放不是自己的锁问题：
　　可以在加锁的时候设置一个唯一标识作为value值。在释放锁的时候，判断获取的value值与锁的value值是否相等，相等则删除，否则不能释放锁。
　　伪代码如下：
　　判断value与锁的唯一标识if（redis。get（lock：101）。equals（value））｛redis。del（lock：101）；相等就删除｝复制代码
　　同样也是需要考虑原子性问题，因为这也这是GETDEL指令组合而成的。
　　此时，我们可以考虑通过Lua脚本来实现，这样判断和删除的过程就是原子操作了。
　　获取锁的value值与ARGV〔1〕比较，匹配成功则执行delifredis。call（get，KEYS〔1〕）ARGV〔1〕thenreturnredis。call（del，KEYS〔1〕）elsereturn0end复制代码
　　使用上面的脚本，为每个锁分配一个随机字符串签名，只有当删除锁的客户端的签名与锁的value匹配的时候，才会去删除它。
　　遇到问题不要慌，先从官方文档入手：redis。iotopicsdist
　　到目前为止，以上修改后（优化后）的方案算相比较完善的了，业界大部分使用的也都是该方案。锁的过期时间设置多少才合适呢？
　　当然这个锁的过期时间不能瞎写，通常是根据多次测试后的结果来做选择，比如压测多轮之后，平均执行时间在300ms。
　　那么我们的锁过期时间就应该放大到平均执行时间的34倍。
　　有些小伙伴可能会问：为啥是放大34倍呢？
　　这叫凡事留一手：考虑到锁的操作逻辑中如果有网络IO操作等，线上的网络不会总是稳定的，此时需要留点时间来缓冲。
　　我们可以让获得锁的线程开启一个守护线程，用来给快要过期的锁续航。
　　加锁的时候设置一个过期时间，同时客户端开启一个守护线程，定时去检测这个锁的失效时间。
　　如果快要过期，但是业务逻辑还没执行完成，自动对这个锁进行续期，重新设置过期时间。
　　道理大家都懂，可是这样的代码该怎么写呢。
　　可以先谷歌一下，相信谷歌大哥会告诉你有这么一个库把这些工作都封装好了，你只管用就是了，它叫Redisson。
　　在使用分布式锁的时候，其实就是采用了自动续期的方案来避免锁过期，这个守护线程我们一般也把它叫做看门狗线程。
　　记过多次优化，方案也算比较完美了，抽象出对应的模型如下。首先通过SETkeyNamerandomValueNXPXexpireTime，同时启动守护线程为快要过期但还没执行完的客户端的锁续命；然后客户端执行业务逻辑，操作共享资源；最后通过Lua脚本来释放锁，通常先get锁，判断锁是不是自己加的，然后再执行DEL操作。
　　这个方案可以说很OK了，能想到这些的优化点已经击败一大批程序猿了。
　　对于追求极致的程序员来说，你们可能会考虑到：在代码具体什么位置加、解锁？怎么考虑实现可重入锁？要不要考虑主从架构带来的问题？。。。。。。
　　这里就不展开讨论了。有兴趣的可以在评论区一起讨论交流哈。总结到这里，分布式锁涉及的问题，以及该如何正确使用的方案都讲完了，相信你看到这里，多少会有点收获。其实，不管用什么做分布式锁都会存在的问题，重要的是自己思考的过程。此时，建议你合眼睛，自己在脑子里回顾一下，分布式锁的每一步都在做什么，为什么要这么做，解决什么问题。对于系统的设计，出发点都不一样，设计出来的方案也不尽相同，没有最好的框架，也没有最好的方案，只有最合适的。