利用redis实现分布式锁知识点总结及相关改进
先上原文，本文只为总结及对相关内容的质疑并提出若干意见，原文内容更详细https://www.cnblogs.com/linjiqin/p/8003838.html
@frameStart@
@frameTitle@最新修改@frameTitle@
老版问题：lock时如果只用jedis.set(String key, String value, String nxxx, String expx, int time)方法存在若干问题：1.不支持重入锁，2.且超时时间的设置也是一个问题
解决方案：1. 锁的结构用hash，因为string形式无法支持可重入；
2. 使用了hash就不能再用jedis.set(String key, String value, String nxxx, String expx, int time)这个方法了，所以取锁也要使用eval表达式。
hash数据结构：
1 bizKey：{ // 某个业务锁 2 clientId：“”，// 业务id，唯一； 3 state：1， //取锁次数，用来实现可重入 4 // 超时时间直接用expire来表示，用字段的话不安全。 5 }
伪代码如下：
加锁基本思路： 判断锁是否存在，如果不存在，直接加锁；如果存在，则判断client是否与当前业务id一致，如果一致，加锁成功，state+1，否则提示加锁失败
去锁基本思路：判断锁是否存在，如果不存在，直接返回成功；如果client不一致，返回失败；now = state-1，如果now=0，直接删掉锁。返回成功。
最后，关于超时时间的问题：如果不设超时的话，业务异常导致来不及解锁时会导致数据一直存在。如果设的话，设的太小了，可能业务处理时间太长，别的线程在锁过期后会取到锁，此方式最不可取。如果设的时间太长，与不设同义。
方案：？
关于锁超时的俩种言论，参考一下：
一种：
使用 WATCH/MULTI/EXEC ，watch能保证 MULTI 和 EXEC 之间的命令只有在watch的值没有变化才执行成功，见官方文档https://redis.io/topics/trans...。
所以一般这个锁的值要在整个系统保持唯一。
另一种：
锁超时被释放不是很正常吗。。 因为我没有用过redis，所以对于楼上说的超时如何避免我不知道。。
但是从分布式系统的角度来分析这个问题，锁其实就等于租约，谁从redis得到了租约，谁就是集群的leader，执行一些follower不能做的操作，
但是呢，leader总是会由于种种问题（网络、gc）无法及时续租，导致超时，这时候另外一个follower进而得到锁，导致集群双主。
所以问题的性质就变成了分布式情况下如何避免多主（或脑裂）。常用的做法就是fencing机制，如kafka的epoch。楼主可以试下
@frameEnd@
1.redis基础知识点：
1.1 多线程环境下，多条命令不具备原子性，尽量使用单命令或eval表达式；
1.2 redis天然单线程，化异步为同步，处理效率极高；且一般内网操作，速度比较快；支持多机部署，用来实现锁机制十分合适；
2. 针对锁的基本特性，利用redis的特点解决之
2.1互斥性：set一个key NX 观看返回值即可
2.2 防死锁：设置key的过期时间即可
2.3 容错性：使用Redisson实现分布式锁
2.4 排他性：set key value时，value设置一个独一无二的值如uuid
针对以上几个特性，
**获取锁**：
使用jedis.set(key, value_uuid, NX, PX, 10000);即可实现取锁；
**释放锁**：
使用eval表达式即可：
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(key), Collections.singletonList(value));
**存在问题**
问题1：锁超时时间大小不好设置，因为业务处理的时间大小不确定，可能会很长，长到超时时间满足不了。
问题2：关于拿锁是重试还是排队拿锁？可以自己参考AQS类，锁的本质就是一个状态的获得，AQS类是JVM中state变量的获取，而基于redis的分布式锁则是内存中变量的获取，redis已经天然的变异步为同步了，所以只能排队拿锁，如果恰好每次重试的过程中都是被其它客户端持有锁的，极有可能造成线程长时间拿不到锁（即使你忙循环调用redis，redis也不会单独优先处理你的）
2.5 可重入：不支持，重置有效期是错误的方式；另外value_uuid被设定成了固定值（用来排他），无法像AQS的state字段那样增长或者减少。
2.6 总结：排他和可重入似乎不能同时实现。而且实现了可重入，不支持排他，这个锁机制也是不可用的。所以，放弃可重入
