分布式锁学习笔记

最新推荐文章于 2022-10-04 12:53:32 发布

bnbjin

最新推荐文章于 2022-10-04 12:53:32 发布

阅读量197

点赞数

分类专栏：算法

本文链接：https://blog.youkuaiyun.com/bnbjin/article/details/100763186

版权

算法专栏收录该内容

6 篇文章

订阅专栏

安全性与活跃性（liveness）保证

安全性：互斥。在任意时刻，仅存在唯一客户拥有锁。
活跃性A：死锁释放。最终肯定可以获取到一个锁，即便拥有着锁的客户崩溃宕机。
活跃性B：容错。只要大多数节点正常，客户就能够获取和释放锁。

为什么基于故障转移（容错转移）的实现还不够？

基于REDIS的分布式锁库的简单实现方案：一个锁对应一个键的实例。利用REDIS的超时机制，最终肯定可以获取到锁。锁不存在，即未占用，存在即被占用。锁释放时，删除键即可。
但是这种方案存在问题：如果REDIS主节点崩溃，即便是在REDIS主从架构的集群，无法保证安全性（互斥性），因为REDIS的主从复制是异步的。
以下是该方案中一个触发竞争条件（race condition）的场景：

客户A从主节点获取锁
在主节点复制该锁数据到从节点前，主节点就崩溃了
从节点晋升为主节点
客户B从（新）主节点获取相同的锁（违反安全性）

单实例方案的正确实现

在竞争条件可接受的情况下，单实例方案是一个可行的方案。
获取锁

SET resource_name my_random_value NX PX 30000
注： 仅当键不存在时，该命令会创建键，30000ms超时。键值应该是全局（客户间）唯一的值，为了释放锁的权力仅有唯一且就是创建锁的客户所有（除超时）。

解锁

if redis.call("get", KEY[1]) == ARGV[1] then
	return redis.call("del", KEYS[1])
else
	return 0
end

分布式方案实现

实现方案其实就是参照分布式一致性算法的，与PAXOS非常类似的。

初始化：

设存在N个（N为奇数）节点，每个节点互相独立，不存在任何协同。

过程：

获取当前时间（ms）
尝试按顺序地从N个节点获取锁，使用相同的键名和键值。
2.1. 客户请求每个节点时也会有一个超时，而该超时的值也有要求。要求是与锁自动释放的超时相比，请求超时要足够小（大概小于千分之五）。这是为了防止客户持续来自已崩溃的节点的响应。
客户计算获取到锁所花费的时间（当前时间 - 第一步所获得的时间）。向每个节点获取锁的所花费的总时间小于锁的自动超时才认为锁是成功地被获取了。
如果锁被获取了，则锁的超时时间 = 初始超时时间 - 获取锁所花费的时间
如果获取锁失败，则客户需要向所有节点发送释放锁的请求（即便被认为是获取锁失败的节点）

其他：

对每个节点获取锁和释放锁的过程，同单实例版本一致。

算法是安全的吗？

假设一个客户能够从大多数节点中获取锁。所有的节点将会包含一致存活时间的一个键。但是，在异步的环境下，每个键被设置的时间是不相同的，因此它们超时的时间也是不相同的。
假设客户在第一个节点设置键的时间点是T1（请求第一个服务器的那一刻），在最后一个节点设置成功的时间是T2（从最后一个节点接收到设置成功的响应的一刻），那么，我们可以保证第一个被设置的键的最低有效存活时间是MIN_VALIDITY = TTL - (T2 - T1) - CLOCK_DRIFT。？

理论的严谨性我们可以参考分布式共识算法PAXOS，在此不作详述。

活跃性参数（Liveness arguments）

系统的活跃性基于三个主要的特点：

自动释放锁：锁最终可以重新被获取和锁定。
事实上，获取锁的客户，在崩溃的时候，都会释放自身所获取的锁以使锁可以被重新获取，而无需等待自动释放的时间。
当客户需要重新请求获取锁时（前面一次尝试失败），它需要等待一段比从多数节点获取锁锁需要的时间。

在遇到网络分裂（network partition）的情况时，我们需要付出TTL时长的可用惩罚。如果存在连续分区，则需要付出无限的惩罚。这个情况经常发生在，客户获取锁了以后，被网络分裂，导致无法释放锁。
基本来说，如果系统内存在无限个连续的网络分区，系统会在无限长的一段时间中不可用。

性能、宕机恢复、持久化和延迟启动

性能

用户使用REDIS作为锁服务器的原因在于，它能提供获取/释放锁的超低延迟。
为了达到这一点，请求N个REDIS服务器节点的策略应该使用多路复用（multiplexing）。

宕机恢复和持久化

设计到宕机恢复的问题，持久化是一个经常被考虑的补救措施。通过宕机的节点重启后，重新读取前面持久化了的原数据镜像。
但是如果这种措施，会非常消耗性能。

延迟启动

实际上，重启后的节点，是对宕机前已存在的锁无感知。对于新的获取锁的请求，是可以正常工作的。
为了避免持久化造成大量性能消耗，在确保锁安全性的同时，我们可以使用延迟启动。宕机重启的节点，保持不可用一段时间，该时长应该比最大TTL（锁的生存时间）大一点。
使用该方法，甚至无需任何持久化措施，也能够保证系统的安全性。
但是，这样会牺牲系统的可用性，因为节点宕机恢复是牺牲了TTL时长的可用性的。如果短期内大量（过半数）节点崩溃，则在TTL时间段内，会产生锁系统全局不可用的情况，因为超半数节点处于宕机或延迟启动的不可用状态。