[TOC]
1. 分布式锁背景
在单体机器的jvm中，多个线程想要访问共享资源，那么，需要在jvm中创建一个独占锁，哪个线程获取到了锁，那么这个线程可以访问资源。其他线程只能等待获取到锁的线程释放锁。
在多体机器的集群环境中，仍然是多个线程想要访问共享资源。但是因为这些线程并不在一个jvm中，所以创建独占锁就不能实现不同机器的jvm内的线程等待。所以就需要引入第三方锁，集群内的所有jvm都可以访问第三方锁，哪一个机器的得到了锁，那么这个机器的线程就可以访问资源，其他机器的线程只能等待释放锁。
2. 锁的基本特性
- 安全：独占锁。在任意一个时刻，只有一个客户端持有锁。
- 健壮：无死锁。即使持有锁的机器挂了，或者网络不可达，也不能造成死锁。
- 容错：只要存在一个可用的锁平台，那么就能获取与释放锁。
3. 基于Redis实现锁的基本原理
实现redis分锁的最简单的方法就是在redis中创建一个key，这个key有实效时间，保证分布式锁的健壮性，保证锁最终会自动释放，不会出现死锁。释放锁，就是删除这个key。
上述实现看起来还不错，但是依然存在问题：
假如获得锁的线程在超时时间内还未处理完成怎么办？
假如redis集群主从复制失败了怎么办？
这两个问题都会导致多个线程获得了锁，破坏了分布式锁的安全性。
4. redis实现锁
为了解决3中的两个问题，可以随机生成value.
也就是说，在获取锁的时候，使用set key value nx px time来保证只有key不存在时，才会创建，超时时间是time.超时时间就是线程持有锁的最大时间。
释放锁的时候，需要验证当前线程释放的线程是不是自己持有的锁。
但是超时时间问题还是没有解决。
使用set可以存储字符串，线程在获取到锁后，将获取锁的时间做为值放入，同时还要加上线程自己的随机数，将字符串打造成多个属性的对象的json串。
其他线程在获取锁的时候，根据json串，判断，持有锁的线程是不是死掉了。
举个例子：约定持有锁的线程，每隔1分钟将json里面的值++。其他线程尝试获取锁的时候，发现当前时间已经有多个时间间隔的值没有更新了，那么就可以认为持有锁的线程挂了。
5. redis分布式锁
前面我们考虑的都是单体的redis如何实现分布式锁。
那么如果redis也是多个实例的，这些实例之间完全独立，没有主从赋值或者其他集群协调。那么前面我们讨论的解决方案就不能保证安全了。
为了实现分布式锁，我们可以约定==客户端尝试向所有的redis实例获取锁，如果至少有2/3的redis获取锁成功，那么就表示这个客户端获取分布式锁成功。锁需要时间戳和随机值保证唯一性。==
因为我们的阈值是2/3，不可能同时有多个线程获取2/3的锁，而且这些锁还是同一把锁。
为了防止redis实例不可达，我们不仅仅需要2/3成功，还需要在获取锁的时候，设置小于2个数量级的超时时间。
举个例子：
我们redis实例有5个，这些redis实例之间没没有任何关系。
接着客户端得到锁的key==(所有的锁的key相同，value不同)==。
然后客户端尝试向所有的redis实例注册锁。
假设有3个redis实例注册成功，此时客户端持有锁。
另一个客户端在第一个客户端持有锁的状态下，尝试获取锁，那么，此时至少有2/3的redis实例的锁是占有的，那么尝试获取锁的线程就无法满足2/3的这个阈值了，就无法持有锁了。
尝试获取锁失败，需要尽快释放已经获取持有锁的redis实例，避免影响下一次获取锁。
假设锁的有效时间是10s，那么客户端和redis的连接超时时间应该设置为100ms <= 在两个数量级以上，否则线程花费80%以上的时间获取了锁，然后还没开始使用呢，就超时了。
==超时续期==可以使用==EXPIRE==进行续期。
这个方法能满足需要，但是依然不太好，因为尝试获取锁的时候，不是同步的，也就是说，无法在同一时间获取到全部2/3的锁。获取锁的过程中，也需要花费一定的时间。
所以，锁的实际使用时间是不确定的，即使有超时时间，实际可使用的时间也是小于超时时间的。
而且，还存在一个比较致命的问题，这些redis实例之间存在==时钟漂移==。当redis实例之间没有做时钟同步，那么因为时钟漂移问题，会造成锁的实际使用时间很可能是不确定的，往往小于预期时间。
6. 获取锁失败
当客户端获取锁失败后，不应该立即重试，一般情况下，如果因为冲突而无法获取到锁，那么失败后立即重试，几乎也是失败的。因为多个客户端在同一时间抢夺同一个锁，会造成==脑裂==。(为了防止脑裂，一般解决方式是采用过半策略。得到支持的数量超过一半才能认为是得到整个集群的支持)
所以，客户端在获取锁失败后，应该等待随机的时间，然后在尝试获取锁。
而且还应该注意一点，当获取失败后，应该尽可能快的释放已经获取到的锁。否则，在一个超时时间内，没有客户端可以获取锁。
还是延续前面的例子：我们有5个客户端，5个redis实例。
第一次：每个客户端得到了一个redis锁，但是没有客户端获取的redis锁的数量超过2/3，所有客户端获取锁失败。
第二次：因为客户端等待随机的时间，有2个客户端获取到了锁，另外有一个客户端获取到了锁，其他两个客户端没有获取到锁，因为不满足2/3的策略，获取失败。
多次进行后，到达了超时时间，依然没有客户端获取到锁，那么，这个锁就是低可用性的锁，特别是随着客户端的数量的增加，可用性也会下降。
==失败惩罚==
某个客户端尝试获取锁，当得到1/3的锁后，发现剩余的锁都被占用了，此时客户端无法获取锁，需要释放，结果在释放一半的时候，网络中断了，那么这个客户端持有的锁在超时时间内就无法释放了。只能等到超时时间到，自动释放。
==此时这些锁可以认为在这段时间内被惩罚了。==
7. 最终
这样就完美了吗？
当然不是，我们前面的==过半策略==是==2/3==如果更小点呢？
假设现在有100个redis实例，我们的阈值是60%。
因为持续并发，需要增加redis实例，于是又增加了100个redis实例。
如果在增加的同时，正好有客户端在获取锁，那么此时，就有可能存在多个客户端获取到锁的问题。
所以，这个过半策略，应该是能够动态计算的。
- redis实例崩溃造成锁在一定的时间内不可用
即使这样，在分布式环境下，存在着各种各样的问题，比如redis实例崩溃，导致锁本来是空闲的，但是集群内的部分redis实例崩溃了，在进行重启恢复的时候，只恢复到了锁持有的状态，此时如果崩溃的机器数量比较大，就会导致在这部分崩溃的机器的锁自动释放前，没有任何客户端可以获取锁。
- 因网络隔离，造成锁不安全
假设我们有100个redis实例，客户端A现在已经获取到了2/3的锁66个，此时，集群的锁是占用状态。
但是因为动态削减redis实例，造成B客户端在尝试获取锁的时候，获取了33个锁，就满足过半策略了(假设从100 -> 48),此时33刚好是48的2/3，那么就相当于两个客户端都获取到了锁。
8. 使用
在java语言中，使用的最多的redis锁应该就是redisson了。
