SpringCloud（27. Redis 和 ZK 分布式锁）

上一篇 ：26.分布式服务框架Dubbo面试题简析

1. redis 分布式锁

• 官方叫做 RedLock 算法，是 redis 官方支持的分布式锁算法。
• 这个分布式锁有 3 个重要的考量点：
  • 互斥（只能有一个客户端获取锁）
  • 不能死锁
  • 容错（只要大部分 redis 节点创建了这把锁就可以）

RedLock 获取锁基本思想

• 这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：
  • 获取当前时间戳，单位是毫秒；
  • 跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
  • 尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 （n / 2 + 1）；
  • 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
  • 要是锁建立失败了，那么就依次将之前建立过的锁删除；
  • 只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。
    
• Redis 官方给出了以上两种基于 Redis 实现分布式锁的方法，详细说明可以查看：https://redis.io/topics/distlock 。

2. ZK 分布式锁

• zk 分布式锁，其实可以做的比较简单
  • 就是某个节点尝试创建临时 znode，此时创建成功了就获取了这个锁；
  • 这个时候别的客户端来创建锁会失败，只能注册个监听器监听这个锁。
  • 释放锁就是删除这个 znode，一旦释放掉就会通知客户端，
  • 然后有一个等待着的客户端就可以再次重新加锁。
• 这种情况下没有获取锁的客户端是无序的，当锁被释放，所有等待中的客户端都会尝试抢占锁
• 这就类似 ReentrantLock 中的公平、非公平锁
• 如果想要等待的客户端是有序的，可以创建临时顺序节点：
  • 创建临时顺序节点后，若有多个客户端同时尝试创建临时节点时，都会创建成功，但是在创建的节点名称后自动加上一个序号
  • 第一个拿到锁的客户端会执行；
  • 后面的每个客户端都会去监听排在自己前面的那个人创建的 node 上，也即序号值-1的节点，
  • 一旦客户端释放了锁，zookeeper 就会通知排在后面的客户端，
  • 一旦被通知了之后，就去获取到锁，就可以执行代码了。

3. redis 分布式锁和 zk 分布式锁的对比

• Redlock 在实践中存在一些问题，主要包括以下几点：

  1. 误判问题：Redlock 算法中需要获取多个 Redis 节点的锁，如果其中一个节点出现了故障或网络延迟，可能会导致其他节点误判为锁已经被获取。这种情况下可能会导致多个客户端同时获取到锁，从而导致竞态条件的发生。
  2. 时间漂移问题：由于系统中不同节点之间时钟的不同步，可能会导致一个节点的时钟比其他节点快或慢。如果某个节点的时钟比其他节点快，那么它会提前释放锁，从而导致其他节点误认为锁已经被释放。如果某个节点的时钟比其他节点慢，那么它可能会错误地认为锁还未被释放。
  3. 数据分片问题：Redlock 算法要求锁的数据在所有节点上都存在，但是在数据被分片存储的情况下，锁的数据可能只存在于部分节点上，这会导致锁无法正常被获取。
  4. 单点故障问题：Redlock 算法中所有的锁都由 Redis 节点来管理，如果其中一个节点发生故障，可能会导致整个系统无法正常工作。
  5. 竞争条件问题：Redlock 算法中多个客户端同时尝试获取同一个锁时，可能会导致竞争条件的发生。这种情况下可能会导致多个客户端都认为自己已经获取到了锁，从而导致数据不一致或其他问题的出现。
  6. 惊群问题: 是指在并发编程中，多个进程或线程同时等待同一个事件或资源的时候，可能会出现多个进程或线程同时被唤醒的情况，导致性能下降或资源浪费的问题。

• ZooKeeper 在实践中存在一些问题，主要包括以下几点：

  • 性能问题：ZooKeeper 节点的数量有限，同时，每次获取锁都需要向 ZooKeeper 服务器发送请求，这会给服务器带来较大的负载。因此，在高并发场景下，使用 ZooKeeper 实现分布式锁可能会导致系统性能下降。
  • 可靠性问题：如果 ZooKeeper 服务器发生故障，可能会导致分布式锁的可靠性和一致性受到影响。为了避免这个问题，可以使用 ZooKeeper 的多个实例来实现高可用性和冗余备份。
  • 临时性问题：ZooKeeper 分布式锁是基于临时节点实现的，如果一个客户端获取到锁之后突然宕机或网络异常，那么其他客户端就无法释放该节点上的锁，从而导致死锁的情况。为了解决这个问题，可以使用心跳机制来保证节点的存活性，以及使用超时时间来避免死锁。
  • 长时间占用问题：如果一个客户端获取到锁之后长时间不释放，会导致其他客户端长时间等待，从而降低系统的可用性和性能。

• 如果应用场景对于分布式锁的可靠性和一致性要求较高，那么可以选择使用 ZooKeeper 实现的分布式锁；

• 如果应用场景对于分布式锁的性能和效率要求较高，那么可以选择使用 Redis 实现的分布式锁。