设计原则
1，安全性-互斥：在任意时间点只有一个client可以获取锁
2，活性属性A-无死锁
3，活性属性B-容错性
实现方式
1，利用set-if-absent机制锁定资源，满足互斥原则
2，利用redis的过期淘汰策略释放资源，满足活性属性A
3，client需要释放资源时，删除这个key
设计漏洞
超时淘汰问题
情景1：clientA为资源R加锁success，由于执行超时，锁超时淘汰；clientA在最终执行完成后依旧会去del-key；而clientB在clientA超时释放redis-key时获取到了资源R的锁；那么当clientA执行del-key操作时，会误删clientB的锁
情景2：clientA为资源R加锁success，此时clientA发生full-GC，整个服务stop-the-world；stop-the-world期间clientA的锁超时淘汰，clientB获取到资源R的锁，此时clientA和clientB发生并发冲突，如下图：
节点crash问题
情景3：clientA在master节点为资源R获取到锁；master与slave还未同步之前，master异常crash；此时slave节点晋升为master，clientB为资源R申请锁；由于同步为完成，new-master此时不存在clientA的redis-lock-key，那么clientB成功获取到资源R的锁；duang！发生并发问题
解决方案：
情景1-解决：加锁时为redis-lock-key设置unique_value，del-key操作利用lua脚本原子的去校验unique_value是否符合预期，符合预期则删除，否则等待超时淘汰策略删除
情景2-解决：无论是执行超时，还是stop-the-world情景，都会产生并发问题-clientA和clientB获得了相同资源的lock，所以需要在数据库增加乐观锁兜底方案
情景3-解决：RedLock
RedLock
加锁流程
1：client获取一个毫秒级别时间戳：currentTime
2：以相同的key和相同的unique_value尝试顺序的为N个redis-node加锁；在顺序加锁过程中为了防止client长时间因为网络或者redis-node失活而被阻塞的情况，client会利用一个timeOut时间来保证获取锁，当超时则放弃当前node立即尝试操作下一个node
3：当超过半数的redis-node都加锁成功，并且总的加锁时间expend-time小于锁的expire-time，那么此时认为加锁成功，那么锁的available-time=expire-time-expend-time
4：如果加锁失败，那么立即去释放所有redis-node上的锁
失败重试
当客户端获取锁失败时，客户端应该在一个随机延迟之后进行重试；之所以采取随机延时是为了避免不同客户端同时重试导致谁都无法拿到锁的情况出现。所以客户端越快尝试从大多数redis-node上获取锁，出现脑裂的情况就会越低。所以最好的方式是使用多路传输方式向N个redis-node同时发送set命令。很重要的一点就是如果client在大多数节点没有获取到锁，那么必须尽快的释放所有节点上的锁，这样就没必要等到key超时后才可以获取这个锁。
释放锁
RedLock释放锁的流程很简单，如果获取锁失败，则要求所有redis-node节点都去释放锁
安全论证
前提
存在A,B,C,D,E五个redis-node，以及clintA，clientB两个客户端
本地时钟问题：
1，clientA在A,B,C三个redis-node上set-key-success，在D,E上网络失败，set-key-fail，此时clientA获取到锁
2，C-redis-node上的时钟向前跳跃，导致C-redis-node上的lock被expire-release
3，clientB在A,B,C,D,E五个redis-node上申请加锁
4，由于C-redis-node因为时钟前跳导致lock-relase，此时clientB在C,D,E三个获取到锁
5，clientA和clientB持有了相同的锁
full-GC-stop-the-world问题
1，clientA在A,B,C,D,E上成功获取锁之后，clientA进入full-GC，整个jvm进入stop-the-world
2，clientA获取到的锁在stop-the-world期间全部过期删除
3，clientB在A,B,C,D,E上获取到锁
4，clientA和clientB获取到了相同资源的锁lock
奔溃立即重启问题
1，clientA在A,B,C三个redis-node上set-key-success，在D,E上网络失败，set-key-fail，此时clientA获取到锁
2，C-redis-node在还未完成持久化时奔溃-重启，导致lock锁丢失
3，clientB在C,D,E上获取到锁
4，clientA和clientB获取到相同的锁
问题解决方案
本地时钟问题，full-GC-stop-the-world问题解决：
使用数据库级别的乐观锁来避免问题
奔溃重启问题
redLock在加锁成功之后，如果加锁成功的redis-node意外奔溃，不会立即重启这个redis-node，而是在锁的expire-time之后重启这个redis-node，这样就避免了奔溃立即重启问题
RedLock使用场景：
满足一下条件的场景推荐使用redLock：
1，有界的网络延迟：可以保证数据包总会在最大延迟下到达
2，有界的进程暂停：硬实时的约束
3，有界的时钟误差
总结
如何使用redis加锁？
推荐使用redis-2.6.12版本之后的set复合命令：set key unique_value nx px expire_time，原子的加锁并设置过期时间expire-time，特别注意，加锁为key设置唯一不重的value，可以解决过期误删key的问题
如何主动释放redis锁
推荐使用redis的lua脚本，原子的通过验证key的unique-value来删除redis-key
是否推荐redLock？
不推荐！！！，redLock加锁依赖多节点，虽然解决了master奔溃slave晋升的问题，但是，redLock对于网络延迟，对于操作延迟，对于系统时钟同步的乐观（都假设这些条件处于一个有界合理范围），导致在一些情况下，依旧会出单节点redis锁的问题，而且解决问题的难度比单节点redis-lock的复杂度要高，需要耗费更多的系统资源，网络资源，造成更长的操作时间，而无论单节点redis锁，还是redLock锁，他们的异常都可以通过数据库的乐观锁来保证最后的一致性，所以，为了解决解决了master奔溃slave晋升的问题使用redLock实在划不来，不如数据库层面的乐观锁
redis分布式锁的最终方案：
1，使用set key unique-value NX PX expire-time原子设置锁以及过期时间，为key绑定一个独一无二的value
2，利用redis的过期淘汰策略去淘汰过期键，防止死锁
3，利用redis的lua脚本以及验证unique-value的方式，原子的保障不出现误删情况
4，数据库层面做好乐观锁，防止锁因为超时，节点奔溃重启，节点奔溃选举产生的锁失效问题！
