亦庄网站建设价格,广州网站推广服务,信用中国 网站 支持建设,在网上建设网站分布式锁
在许多环境中#xff0c;分布式锁是非常有用的原语#xff0c;在这些环境中#xff0c;不同的进程必须以互斥的方式操作共享资源。在应对并发问题时#xff0c;Redis 客户端还可以通过加锁的方式#xff0c;来控制并发写操作对共享数据的修改#xff0c;从而保…分布式锁
在许多环境中分布式锁是非常有用的原语在这些环境中不同的进程必须以互斥的方式操作共享资源。在应对并发问题时Redis 客户端还可以通过加锁的方式来控制并发写操作对共享数据的修改从而保证数据的正确性。
从设计建模角度来看这三个属性是有效使用分布式锁所需的最低保证。
互斥性在任何给定时刻只有一个客户端可以持有锁。无死锁最终即使锁定资源的客户端崩溃或分区也始终可以获取锁。容错性只要大多数 Redis 节点正常运行客户端就可以获取和释放锁。
Redis属于分布式系统当有多个客户端需要获取锁时这个锁不能是某个客户端本地锁。这个锁是保存到共享的存储系统Redis中。可以被多个客户端共享访问、获取。 它是一个分布式锁。 不是客户端本地锁。
单实例分布式锁
Redis 使用键值对来保存锁变量不同客户端发送的加锁和释放锁的操作请求 这个变量名作为键值对的键而锁变量的值则是键值对的值 要获取锁方法如下 unique_value 是客户端的唯一标识可以用一个随机生成的字符串来表示。 PX 30000 表示此锁会在30s后过期为避免死锁问题。
加锁操作 使用 SET 命令的 NX 和 EX/PX 选项。使用随机值是为了以安全的方式释放锁。当返回 OK 表示加锁成功。
# 仅当密钥尚不存在时该命令才会设置密钥NX选项过期时间为 30000 毫秒PX选项
SET distributed_lock unique_value NX PX 30000# 以下测试使用 uuidgen 生成一个随机字符串
rootubuntu-x64_01:/opt# redis-cli --no-auth-warning -h 192.168.88.11 -p 6380 -a ****** SET distributed_lock $(uuidgen) NX PX 30000
OKrootubuntu-x64_01:/opt# redis-cli --no-auth-warning -h 192.168.88.11 -p 6380 -a ****** get distributed_lock
0cde222a-bf17-4286-9a58-a886a8a8a716解锁操作使用 lua 脚本执行解锁操作仅当密钥存在且存储在密钥中的值正是我期望的值时才删除该密钥。当返回 1 表示解锁成功。
if redis.call(get,KEYS[1]) ARGV[1] thenreturn redis.call(del,KEYS[1])
elsereturn 0
end# 使用 lua 脚本执行解锁操作, 持有锁客户端解锁成功返回1
rootubuntu-x64_01:/opt# redis-cli --no-auth-warning -h 192.168.88.11 -p 6380 -a ****** --eval /opt/distributed_unlock.lua distributed_lock , 0cde222a-bf17-4286-9a58-a886a8a8a716
(integer) 1# 使用 lua 脚本执行解锁操作, 未持有锁客户端解锁失败返回0
rootubuntu-x64_01:/opt# redis-cli --no-auth-warning -h 192.168.88.11 -p 6380 -a ****** --eval /opt/distributed_unlock.lua distributed_lock , 3e8a7cf1-424c-4bb8-ae6e-29f583c2
(integer) 0上面的加锁操作为避免出现死锁。我们使用了 SET 命令的 NX 和 EX/PX 选项而不是使用 SETNX EXPIRE 因为 Redis 扩展了 SET 命令的参数用这一条命令就可以实现原子性操作否则需要考虑用LUA脚本。
“锁有效期”是我们用作密钥生存时间的时间。它既是自动释放时间也是客户端在另一个客户端能够再次获取锁之前执行所需操作的时间而不会在技术上违反互斥保证互斥保证仅限于给定的窗口从获取锁的那一刻起的时间。
在释放锁操作时客户端需要判断当前锁变量的值是否和自己持有锁的值相等。如果相等才会执行解锁操作。这样避免误释放锁的问题。
释放锁操作的逻辑包含读取锁变量、判断值是否相等、删除锁变量多个操作。为保证原子性执行在执行时使用了LUA脚本从而保证了锁释放操作的原子性。
分布式锁加锁和释放锁的过程涉及多个操作我们需要保证这些锁操作的原子性。
由于单实例节点存在单点故障所以是否可以通过主从复制哨兵模式来实现分布锁的高可用 当主节点不可用时切换为新的主节点以维护分布锁变量
这是不可行的。通过这样做我们无法实现互斥的安全属性因为 Redis 复制是异步的。 这是不可行的。通过这样做我们无法实现互斥的安全属性因为 Redis 复制是异步的。 这是不可行的。通过这样做我们无法实现互斥的安全属性因为 Redis 复制是异步的。
该模型存在竞争条件
客户端1获取master中的锁。在对密钥的写入传输到副本之前主服务器崩溃了。副本被提升为主节点。 客户端2获取对 1 已持有锁的同一资源的锁。违反安全 有时在特殊情况下例如在故障期间多个客户端可以同时持有锁是完全可以的。如果是这种情况您可以使用基于复制的解决方案。 多实例分布式锁
Redlock 算法 该算法基本思路假设有 5 个 Redis 主节点。这些节点是完全独立的这里实例说明下是完全独立的没有主从关系的。需要在不同的计算机或虚拟机上运行 5 个 Redis master以确保它们以基本独立的方式。不使用复制或任何其他隐式协调系统。让客户端和多个独立的Redis依次请求加锁如果客户端能够和半数以上的实例成功地完成加锁操作则认为成功获得
为了获取锁客户端执行以下操作 Step 1: 它获取当前时间以毫秒为单位。 Step 2: 它尝试在所有 N 个实例中顺序获取锁在所有实例中使用相同的密钥名称和随机值。在步骤 2 中在每个实例中设置锁时客户端使用比总锁自动释放时间较小的超时来获取锁。例如如果自动释放时间为 10 秒则超时可能在 5-50 毫秒范围内。这可以防止客户端在尝试与已关闭的 Redis 节点通信时长时间处于阻塞状态如果某个实例不可用我们应该尽快尝试与下一个实例通信。 如果某个Redis实例发生故障了为了保证Redlock算法有够继续运行我们需要给加锁操作设置一个超时时间。 Step 3: 客户端通过从当前时间减去步骤 1 中获得的时间戳来计算获取锁所花费的时间。当且仅当客户端能够在大多数实例至少 3 个中获取锁时并且获取锁所花费的总时间小于锁的有效时间则认为获取了锁。 Step 4: 如果获取了锁则其有效时间被视为初始有效时间减去经过的时间如步骤 3 中计算的那样。 如果锁的有效时间已经来不及完成共享数据的操作了我们可以释放锁以免出现还没完成数据操作锁就过期了的情况。 Step 5: 如果客户端由于某种原因未能获取锁要么无法锁定 N/21 个实例要么有效期为负它将尝试解锁所有实例甚至是它认为没有锁定的实例能够锁定。
该算法依赖于这样的假设虽然进程之间没有同步时钟但每个进程中的本地时间以大致相同的速率更新与锁的自动释放时间相比误差幅度很小。这种假设与现实世界的计算机非常相似每台计算机都有一个本地时钟我们通常可以依靠不同的计算机来获得很小的时钟漂移。
此时我们需要更好地指定我们的互斥规则只有持有锁的客户端在锁有效时间内如步骤3中获得的终止其工作减去一些时间仅几毫秒才可以保证。以补偿进程之间的时钟漂移。 小结
1分布式锁不能是某个客户端本地锁是由共享系统维护的而Redis作为共享存储系统可以实现分布式锁。 2分布式锁加锁和释放锁的过程涉及多个操作我们需要保证这些锁操作的原子性。加锁通过一条命令SET 命令的 NX 和 EX/PX 选项实现原子操作。释放锁通过lua脚本实现原子操作 3锁变量需要设置有效时间避免客户端发生任何异常无法解锁的情况导致死锁。 4通过SET命令设置锁变量时每个客户端使用唯一值以免出现误释放操作。 5利用分布锁完成大部分场景应用上层[互斥]目的。把并发请求阻挡在上层减轻对要操作的资源压力。 6 一个分布式锁极端情况下锁会失败不能假设分布式锁100%安全对于敏感业务资源层要做好兜底。
