共计 2825 个字符，预计需要花费 8 分钟才能阅读完成。
基于缓存的分布式锁（公司大牛内部文章分享）目前有很多成熟的缓存产品，包括 Redis，memcached 等。这里以 Redis 为例来分析下使用缓存实现分布式锁的方案。主要的实现方式是使用 Jedis.setNX 方法来实现。
public boolean trylock(String key) {
ResultCode code = jedis.setNX(key, “This is a Lock.”);
if (ResultCode.SUCCESS.equals(code))
return true;
else
return false;
}
public boolean unlock(String key){
ldbTairManager.invalid(NAMESPACE, key);
}
以上实现方式同样存在几个问题：1、单点问题。2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在 redis 中，其他线程无法再获得到锁。3、这把锁只能是非阻塞的，无论成功还是失败都直接返回。4、这把锁是非重入的，一个线程获得锁之后，在释放锁之前，无法再次获得该锁，因为使用到的 key 在 redis 中已经存在。无法再执行 setNX 操作。5、这把锁是非公平的，所有等待的线程同时去发起 setNX 操作，运气好的线程能获取锁。
当然，同样有方式可以解决。现在主流的缓存服务都支持集群部署，通过集群来解决单点问题。没有失效时间？redis 的 setExpire 方法支持传入失效时间，到达时间之后数据会自动删除。非阻塞？while 重复执行。非可重入？在一个线程获取到锁之后，把当前主机信息和线程信息保存起来，下次再获取之前先检查自己是不是当前锁的拥有者。非公平？在线程获取锁之前先把所有等待的线程放入一个队列中，然后按先进先出原则获取锁。
redis 集群的同步策略是需要时间的，有可能 A 线程 setNX 成功后拿到锁，但是这个值还没有更新到 B 线程执行 setNX 的这台服务器，那就会产生并发问题。redis 的作者 Salvatore Sanfilippo，提出了 Redlock 算法，该算法实现了比单一节点更安全、可靠的分布式锁管理（DLM）。Redlock 算法假设有 N 个 redis 节点，这些节点互相独立，一般设置为 N =5，这 N 个节点运行在不同的机器上以保持物理层面的独立。
算法的步骤如下：1、客户端获取当前时间，以毫秒为单位。2、客户端尝试获取 N 个节点的锁，（每个节点获取锁的方式和前面说的缓存锁一样），N 个节点以相同的 key 和 value 获取锁。客户端需要设置接口访问超时，接口超时时间需要远远小于锁超时时间，比如锁自动释放的时间是 10s，那么接口超时大概设置 5 -50ms。这样可以在有 redis 节点宕机后，访问该节点时能尽快超时，而减小锁的正常使用。3、客户端计算在获得锁的时候花费了多少时间，方法是用当前时间减去在步骤一获取的时间，只有客户端获得了超过 3 个节点的锁，而且获取锁的时间小于锁的超时时间，客户端才获得了分布式锁。4、客户端获取的锁的时间为设置的锁超时时间减去步骤三计算出的获取锁花费时间。5、如果客户端获取锁失败了，客户端会依次删除所有的锁。使用 Redlock 算法，可以保证在挂掉最多 2 个节点的时候，分布式锁服务仍然能工作，这相比之前的数据库锁和缓存锁大大提
问题一：1、GC 等场景可能随时发生，并导致在客户端获取了锁，在处理中超时，导致另外的客户端获取了锁？
在一个客户端获取了分布式锁后，在客户端的处理过程中，可能出现锁超时释放的情况，这里说的处理中除了 GC 等非抗力外，程序流程未处理完也是可能发生的。之前在说到数据库锁设置的超时时间 2 分钟，如果出现某个任务占用某个订单锁超过 2 分钟，那么另一个交易中心就可以获得这把订单锁，从而两个交易中心同时处理同一个订单。正常情况，任务当然秒级处理完成，可是有时候，加入某个 rpc 请求设置的超时时间过长，一个任务中有多个这样的超时请求，那么，很可能就出现超过自动解锁时间了。当初我们的交易模块是用 C ++ 写的，不存在 GC，如果用 java 写，中间还可能出现 Full GC，那么锁超时解锁后，自己客户端无法感知，是件非常严重的事情。我觉得这不是锁本身的问题，上面说到的任何一个分布式锁，只要自带了超时释放的特性，都会出现这样的问题。如果使用锁的超时功能，那么客户端一定得设置获取锁超时后，采取相应的处理，而不是继续处理共享资源。Redlock 的算法，在客户端获取锁后，会返回客户端能占用的锁时间，客户端必须处理该时间，让任务在超过该时间后停止下来。
问题二：算法依赖本地时间，会出现时钟不准，导致 2 个客户端同时获得锁的情况？Redlock 有个关键的特性是，获取锁的时间是锁默认超时的总时间减去获取锁所花费的时间，这样客户端处理的时间就是一个相对时间，就跟本地时间无关了。
总结：由此看来，Redlock 的正确性是能得到很好的保证的。仔细分析 Redlock，相比于一个节点的 redis，Redlock 提供的最主要的特性是可靠性更高，这在有些场景下是很重要的特性。但是我觉得 Redlock 为了实现可靠性，却花费了过大的代价。
首先必须部署 5 个节点才能让 Redlock 的可靠性更强。然后需要请求 5 个节点才能获取到锁，通过 java Future 的方式，先并发向 5 个节点请求，再一起获得响应结果，能缩短响应时间，不过还是比单节点 redis 锁要耗费更多时间。然后由于必须获取到 5 个节点中的 3 个以上，所以可能出现获取锁冲突，即大家都获得了 1 - 2 把锁，结果谁也不能获取到锁，这个问题，redis 作者借鉴了 raft 算法的精髓，通过冲突后在随机时间开始，可以大大降低冲突时间，但是这问题并不能很好的避免，特别是在第一次获取锁的时候，所以获取锁的时间成本增加了。如果 5 个节点有 2 个宕机，此时锁的可用性会极大降低，首先必须等待这两个宕机节点的结果超时才能返回，另外只有 3 个节点，客户端必须获取到这全部 3 个节点的锁才能拥有锁，难度也加大了。分析了这么多原因，我觉得 Redlock 的问题，最关键的一点在于 Redlock 需要客户端去保证写入的一致性，后端 5 个节点完全独立，所有的客户端都得操作这 5 个节点。如果 5 个节点有一个 leader，客户端只要从 leader 获取锁，其他节点能同步 leader 的数据，这样，分区、超时、冲突等问题都不会存在。所以为了保证分布式锁的正确性，我觉得使用强一致性的分布式协调服务能更好的解决问题。
问题又来了，失效时间我设置多长时间为好？如何设置的失效时间太短，方法没等执行完，锁就自动释放了，那么就会产生并发问题。如果设置的时间太长，其他获取锁的线程就可能要平白的多等一段时间。
对于这个问题目前主流的做法是每获得一个锁时，只设置一个很短的超时时间，同时起一个线程在每次快要到超时时间时去刷新锁的超时时间。在释放锁的同时结束这个线程。如 redis 官方的分布式锁组件 redisson, 就是用的这种方案
