背景

redis实现分布式锁我们就不多介绍了，setNX -> expire -> lua脚本 -> threadID -> RedLock
在redis的cluster模式下，出现以下情况：

  1. 线程1通过setNX拿到了某个key的锁，该key存储在node1上。
  2. node1挂掉。
  3. 线程2此时就能通过setNX拿到了该个key的锁，该key存储在node2上。（做不到，redis采用的是hashslot算法，同一个key哈希的是16383而不是n，所以落到的slot不变，而此时持有该slot的是node1，应该是不会超过的。）所以这里并不是这个逻辑，我们继续看。
  4. node1在挂掉前并没有把数据同步给从节点，所以这是时候从节点被提升为master。

  5. 此时就可以继续执行第三步了，就能成功，也就是出现了分布式锁最不能容忍的问题：两个客户端持有锁。

    过程

    这个场景是假设有一个 Redis cluster，有 5 个 Redis master 实例。然后执行如下步骤获取一把锁：

  6. 获取当前时间戳，单位是毫秒；

  7. 跟上面类似，轮流尝试在每个 master 节点上创建锁，超时时间较短，一般就几十毫秒（客户端为了获取锁而使用的超时时间比自动释放锁的总时间要小。例如，如果自动释放时间是 10 秒，那么超时时间可能在 5~50 毫秒范围内）；
  8. 尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n / 2 + 1 ；
  9. 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
  10. 要是锁建立失败了，那么就依次之前建立过的锁删除；
  11. 只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。

说实话没有太看懂。