Redis快速上手篇七(集群-分布式锁)

分布式锁

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效。

单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁主流的实现方案：

1. 基于数据库实现分布式锁

2. 基于缓存（Redis等）

3. 基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

1. 性能：redis最高

2. 可靠性：zookeeper最高

这里，我们基于 redis setNX 命令实现分布式锁。

基于redis单线程的原理

当线程过来后 进行 setNX <key> <value>操作 只有第一个线程可以设置成功

如第一个线程 setNX key lock，呢只有当一一个线程删掉 key 后后面的线程才能继续执行

同时会出一个个问题：

1.第一个线程设锁后业务报错就不会执行后面的删锁

解决方法： try catch 代码块

                在finally 语句块内 写删锁语句

2.第一个线程设锁执行业务逻辑，服务器宕机掉线

解决方法：给锁设置过期时间（设锁的同时设置，不要用两条命令）

通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）

3.在高并发场景会导致没锁的情况

设置了过期时间但是在过期时间结束业务逻辑没有执行完毕

导致我们设置的锁会被其他请求清除掉

解决方法: 设置UUID

设锁的同时将UUID也与之绑定作为 key 对应的 value

删除锁之前判断当前线程的UUID与锁的UUID是否为同一个 为同一个才能进行删除

4.由于某些不可控原因如(突然的网络卡顿)导致线程判断UUID后执行到删锁已经超过了所设置的过期时间，

同时由于高并发的环境，又有新的请求过来设置了新的锁，但是这个线程因为不可控因素刚刚执行到删锁，导致删掉了我们刚刚设置的锁。

解决方法：保证原子性(同时执行同时失败)

                  续命锁

                        redisson 框架 http://t.csdnimg.cn/9ODp9