分布式锁--Redlock

业务背景
平时开发中都会遇到这样的业务背景：一个任务或者一个订单请求到你，你很强大有三台机器但是只希望任务在同一时间只有一台机器处理，这时候单机的加锁策略synchronized、Lock等通通就不管用了，
这时候就需要用到分布式锁，多个终端抢占一个单例的分布式锁。以下是现有实现分布式锁的方法，使用的是redis的setnx命令，有值不做操作，无值设置成功，设置成功之后再设置超时时间。
假设服务执行到190行宕机，那么超时时间未设置成功，这个锁成为死锁。

分布式锁需要满足以下几个条件：
1、互斥性，同一时间只能有一个锁持有者
2、不能发生死锁，一个拥有锁的客户端挂掉了不能影响其他竞争者之后正常获取锁
3、容错性，大部分的redis节点存活就能正常获取锁和释放锁
4、谁获取的锁谁来解锁
显然之前的例子是不满足第二点的“死锁”的。以下是现有的解锁操作，使用的 del(key)，直接将key删除达到解锁效果，如果出现这样的一个业务场景，A业务获取了锁并设置锁超时时间为5S，此时由于各种原因业务处理了6S，锁自动释放了，B业务开始并
获取锁，此时锁是空闲的，获取锁成功，之后A业务处理完毕去解锁，会将B业务持有的锁（key）删除掉。显然是不满足第四点的。

解决方案
造成条件2不能达到的原因是 setNx和expire操作是两个操作，并不是原子操作。redis有个命令setEx是原子操作可以设置超时时间的，但是此命令是会覆盖旧值，不能完成锁的功能，那么就会想有没有一个既能原子设置值和时间又能set if not exist的，
Redis 2.6.12版本加入了集荣耀与光辉与一体的set命令，如下方案1所示
1、Jedis中的方法 set(final String key, final String value, final String nxxx, final String expx, final long time)
参数含义：
①key：就是锁
②value：锁的值，为了满足第四点使用
③nxxx：看下官方的注释

• @param nxxx NX|XX, NX – Only set the key if it does not already exist. XX – Only set the key if it already exist.
  --------------NX代表key不存在的话才赋值，这个完美替代 setNx命令；XX：有值才赋值，这个想了想可以用来更新锁的超时时间
  ④expx: 看下官方的注释
• @param expx EX|PX, expire time units: EX = seconds; PX = milliseconds
  ---------------超时时间的单位 EX是秒 PX是毫秒
  ⑤time: 看下官方的注释
  @param time expire time in the units of expx
  ---------------就是超时时间，用的单位是第四个参数设置的
  此操作是原子操作，设置值和超时时间浑然一体，在获取锁的时候value类似于一个订单号的作用，在解锁的时候将value传入，判断现在的锁是否是此订单号所持有的，完美解决了以上问题。
  2、Lua脚本实现
  redis内置的lua解释器可以支持lua脚本的运行，并且redis保证脚本的执行是原子性的，将setNx与expire命令写在lua脚本中可以解决。
  3、zk实现
  基于zookeeper临时有序节点可以实现的分布式锁。大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。
  缺点是性能不好，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上。
  4、Redlock
  以上redis相关的锁的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况：
  ①：在Redis的master节点上拿到了锁
  ②：这个加锁的key还没有同步到slave节点
  ③：master故障，发生故障转移，slave节点升级为master节点
  ④：锁丢失了
  以下为某个服务redis的拓扑图，有一主二从三哨兵，极端情况下会存在主从切换的情况，三个哨兵监控master的状态，在多个哨兵同时判断master挂掉后会进行切换。

针对以上场景，redis官方提出了Redlock算法，以下为该算法的大致思路：
在Redis的分布式环境中，我们假设有N个Redis master。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。我们确保将在N个实例上使用与在Redis单实例下相同方法获取和释放锁。现在我们假设有5个Redis master节点，同时我们需要在5台服务器上面运行这些Redis实例，这样保证他们不会同时都宕掉。
为了取到锁，客户端应该执行以下操作：
①：获取当前Unix时间，以毫秒为单位。
②：依次尝试从5个实例，使用相同的key和具有唯一性的value（例如UUID）获取锁。当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁。
③：客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的Redis节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
④：如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。
⑤：如果因为某些原因，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）。

Redisson对此算法进行了封装:

但是如果redis集群中的节点过多的话，此算法性能将会很差。

总结
方案1的set新方法是现阶段最适合的方案，Redlock是最牛逼的