RedLock算法（红锁算法）介绍

最新推荐文章于 2025-04-15 22:20:49 发布
最新推荐文章于 2025-04-15 22:20:49 发布
阅读量858 收藏 1
点赞数
分类专栏： 分布式锁 文章标签： java 数据库 redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ideaxx/article/details/128601133
版权

文章目录

一. 部署图

各redis独立部署，各自独立
在这里插入图片描述

二. RedLock算法简单介绍

加锁

  1. 应用程序获取系统当前时间
  2. 应用程序使用相同的kv值依次从多个redis实例中获取锁。
    如果某一个节点超过一定时间依然没有获取到锁则直接放弃，尽快尝试从下一个健康的redis节点获取锁，以避免被一个宕机了的节点阻塞
  3. 计算获取锁的消耗时间 = 客户端程序的系统当前时间 - step1中的时间。
  4. 获取锁的消耗时间 < 总的锁定时间(30s) 并且半数以上节点获取锁成功，则认为获取锁成功
  5. 计算剩余锁定时间：总的锁定时间 - step3中的消耗时间
  6. 若获取锁失败，对所有的redis节点释放锁

解锁

对所有的redis节点释放锁即可

第二十章_Redis分布式锁Redlock算法和底层源码分析
sinat_31583645的博客
06-06 1047
首先，我们假设客户端能够在大多数实例中获取锁所有实例都将包含一个具有相同生存时间的密钥，然而，这个key是在不用时间设置的，所以过期也会在不同的时间过期，假设第一个key设置时间T1，最后一个key设置时间t2，我们确定第一个key的过期时间至少是MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT，所以所有的key设置超时至少是这个时间，在设置大多数密钥期间，另一个客户端将无法获取锁，因为如果已经存在N/2+1个密钥，则N/2+1 set NX操作无法成功。
Redis（十八）Redlock算法
爱喝星冰乐的博客
03-26 1148
Redlock算法
Redis之RedLock算法以及底层原理
qq_26641137的博客
04-15 1209
Redis之RedLock算法以及底层原理
【redis】redis红锁Redlock算法和底层源码分析
苗老八的博客
05-04 2424
一台redis组成的分布式锁有一个致命的缺陷，一旦这台redis宕机，就无法操作分布式锁在其中一台宕机了，其他也还会继续工作，说明多重锁在高可用方面是优于单机分布式锁的注：阳哥说平时单机性能就够用了。
学习小记 -- Redis的RedLock算法
weixin_42029860的博客
08-29 855
RedLock算法是Redis集群中用的分布式锁算法，在讲之前先简单回顾一下在单Redis节点中分布式锁的使用原理： 我们都知到，用Redis可以实现分布式锁，在单Redis节点中，分布式锁通常使用 SET lock_key NX PX 5000 NX代表只在键不存在时，才对键进行设置操作。 PX 5000设置键的过期时间为5000毫秒。 但是会有问题，如果Client向Master获取锁之后同步给Slave，如果Client获取锁成功之后Master节点挂掉，并且未将该锁同步到Slave，..
Redis中的红锁算法
荣山的博客
10-05 1208
Redis中的红锁算法
redlock:Redlock算法PHP实现
04-30
[Redlock] 算法PHP实现。 要求 PHP> = 5.4 使用[SCAN] 命令，Redis> = 2.8 安装（使用作曲家） 您可以在找到packagist中的库。 { " require " : { " everlution/redlock " : " dev-master " } } 文献资料 贡献...
Rust分布式锁优化：Redlock算法改进.pdf
最新发布
05-05
文档支持目录章节跳转同时还支持阅读器左侧大纲显示和章节快速定位，文档内容完整、条理清晰。文档内所有文字、图表、函数、目录等元素均显示正常，无任何异常情况，敬请您放心查阅与使用。文档仅供学习参考，请勿...
Go分布式锁方案：Redlock算法的Go实现.pdf
04-30
文档支持目录章节跳转同时还支持阅读器左侧大纲显示和章节快速定位，文档内容完整、条理清晰。文档内所有文字、图表、函数、目录等元素均显示正常，无任何异常情况，敬请您放心查阅与使用。文档仅供学习参考，请勿...
Javas使用Redlock实现分布式锁过程解析
08-25
Redlock 算法是 Redis 官方提出的实现分布式锁管理器的算法，该算法具有三个重要的属性：安全属性、效率属性 A 和效率属性 B。安全属性保证了互斥地访问共享资源，不管什么时候，只有一个客户端持有锁。效率属性 A ...
Redlock 算法：Redis 实现分布式锁（译）
weixin_33762321的博客
05-20 219
先介绍两个概念 Safety Properties, 在程序运行中不会进入非预期的状态(如非法调用参数, 数组下标越界等运行错误) Liveness Properties, 在程序运行中预期状态一定会到达(如停机, 获取资源请求一定有返回结果等等) 保证分布式锁有效的三个属性 Safety Properties：安全性，此处也就是互斥性，任意时刻只能有一个客户端可以持有锁 Liveness ...
官方系列之 Redis 分布式锁 / RedLock 算法
潘广宇的博客
07-28 302
算法需要具备的三大特性 ● 安全属性：独享（相互排斥）。在任意一个时刻，只有一个客户端持有锁。 ● 活性A：无死锁，即便持有锁的客户端崩溃，锁仍然可以被获取。 ● 活性B：容错，只要大部分Redis节点都活着，客户端就可以获取和释放锁. 单节点情况 客户端A向服务端请求获取锁： set key_ rand_A NX PX 300000 # key_ 代表锁名称，rand_A是A客户端随机生成的密钥，NX代表只有锁不存在的时候，才能获取（设置），PX是锁的自动过期时间（过期锁自动释放机制）
Redis集群下的RedLock算法(真分布式锁) 实践
lgxzzz的博客
03-30 1762
在不同进程需要互斥地访问共享资源时，分布式锁是一种非常有用的技术手段。 有很多三方库和文章描述如何用Redis实现一个分布式锁管理器，但是这些库实现的方式差别很大，而且很多简单的实现其实只需采用稍微增加一点复杂的设计就可以获得更好的可靠性。 这篇文章的目的就是尝试提出一种官方权威的用Redis实现分布式锁管理器的算法，我们把这个算法称为RedLock。 Redlock是redis官方提出的实现分布式锁管...
Redis RedLock算法和底层源码分析
一位打工仔的博客
09-13 675
失败了多少个机器实例后我还是可以容忍的，所谓的容忍就是数据一致性还是可以Ok的，CP数据一致性还是可以满足。加入在集群环境中，redis失败1台，可接受。2X+1 = 2 * 1+1 =3，部署3台，死了1个剩下2个可以正常工作，那就部署3台。加入在集群环境中，redis失败2台，可接受。2X+1 = 2 * 2+1 =5，部署5台，死了2个剩下3个可以正常工作，那就部署5台。
redis红锁算法
weixin_38738049的博客
12-15 560
3客户端计算获取锁所需的时间通过从当前时间减去步骤1中获得的时间戳，当且仅当客户端能够在大多数实例（至少3个）中获取锁时，获取锁所花费的总时间小于锁有效时间，则认为已获取锁。2在5个实例上依次获取锁，在所有实例中使用相同的key名字和随机值，在步骤2期间，当设置锁再每个实例时，客户端使用与总锁自动释放时间相比小的超时来获取它。首先，我们假设客户端能够在大多数实例中获取锁所有实例都将包含一个具有相同生存时间的密钥，然而，这个key是在不用时间设置的，所以过期也会在不同的时间过期，加锁时客户端执行以下操作。
Redis分布式锁解析：Redlock算法与实践案例
silenceallat的博客
04-05 1369
本文深入解析了Redis分布式锁的核心算法——Redlock，通过阐述其工作原理、应用场景、实用技巧与案例，揭示了Redlock在分布式系统中的重要性与适用性。同时，文章也提到了Redlock算法的局限性以及可能的替代方案，为分布式锁的设计与实现提供了全面的指导与思考。
分布式锁之(RedLock)红锁
Forest24的博客
05-02 9273
需要锁的条件： 多任务环境下。（进程，线程） 任务都对同一共享资源进行写操作。 对资源的访问是互斥的。 操作周期： 竞争锁。获取锁后才能对资源进行操作。 占有锁。操作中。 其他竞争者，任务阻塞。 占有锁者，释放锁。继续从1开始。 JVM 锁 解决不了分布式环境中的加锁问题。 手写Redis锁： redis：内存存储的数据结构服务器，内存数据库。可用于：数据库，高速缓存，消息队列。...
06----------再谈分布式锁(使用Redlock算法)
冷炎嗄的博客
08-30 2580
分布式锁的原理，它的使用非常简单，一条指令就可以完成加锁操作。不过在集群环境下，这种方式是有缺陷的，它不是绝对安全的。 比如在 Sentinel 集群中，主节点挂掉时，从节点会取而代之，客户端上却并没有明显感知。原先第一个客户端在主节点中申请成功了一把锁，但是这把锁还没有来得及同步到从节点，主节点突然挂掉了。然后从节点变成了主节点，这个新的节点内部没有这个锁，所以当另一个客户端过来请求加锁时，立...
Redlock算法的原理和实践
猪猪
01-17 1012
Redlock算法是一种基于多个独立Redis实例的分布式锁实现方案，旨在提高分布式锁的可靠性和安全性。
分布式锁实现（RedLock算法优化）
04-09
<think>嗯，我现在要了解一下分布式锁的实现，特别是RedLock算法的优化。首先，我应该从基础开始，分布式锁是什么，为什么需要它？然后，RedLock算法是怎么工作的，可能有什么问题，之后是优化方法。 首先，分布式锁用于在分布式系统中协调多个节点对共享资源的访问，确保同一时间只有一个节点可以执行某个操作。常见的实现方式有基于数据库、ZooKeeper、Redis等。其中Redis因为性能好，常用作分布式锁的实现，比如RedLock算法。 RedLock算法是Redis的作者Antirez提出的，用来在Redis集群环境下实现更可靠的分布式锁。传统的单节点Redis锁可能有单点故障的问题，比如主从切换时可能导致锁失效。RedLock通过在多个独立的Redis节点上获取锁，来避免单点问题。 RedLock的基本步骤是：客户端获取当前时间，然后依次向N个独立的Redis节点请求加锁；每个请求设置一个较短的超时时间，防止长时间阻塞；客户端计算获取锁所需的时间，如果超过锁的有效时间，或者没有拿到半数以上的节点锁，就失败；否则，锁的有效时间减去获取锁的时间就是实际的有效期。 不过RedLock也有一些问题和争议。比如，Martin Kleppmann曾指出，RedLock依赖系统时钟的同步，如果时钟发生跳跃，可能导致锁失效。此外，网络延迟、GC停顿等问题也可能影响锁的正确性。 那优化RedLock算法的话，可以从哪些方面入手呢？可能的优化方向包括时钟同步问题、锁的续期机制、容错处理、减少网络开销等。 比如，时钟同步问题，可以通过使用更稳定的时钟源，或者在锁的实现中增加对时钟变化的检测。锁的续期机制，类似Redisson的看门狗机制，自动续期锁的有效期，避免业务处理时间过长导致锁失效。容错方面，可能需要处理节点故障后的锁恢复，或者动态调整节点数。网络开销方面，可能减少通信次数，比如并行获取锁而不是串行。 另外，可能还有其他的优化策略，比如结合其他一致性协议，或者改进锁的获取和释放流程。比如，使用Quorum机制，确保大多数节点确认，或者引入版本号来避免旧请求的影响。 不过具体的优化措施可能需要根据实际应用场景来调整，比如对性能的要求，对一致性的要求等等。可能需要查阅一些资料，看看实际中RedLock的优化是怎么做的。比如，有没有改进RedLock的实现，或者结合其他算法来增强其可靠性。 比如，有些系统可能采用RedLock的基础上，增加故障转移机制，或者使用更高效的通信协议。或者，使用更严格的超时控制，确保在出现网络分区时能够正确处理锁的状态。 另外，关于锁的有效期设置，也是一个关键点。设置过短的话，可能导致业务还没处理完锁就释放了，设置过长的话，可能影响系统的响应速度。因此，自动续期机制可能是一个重要的优化点。 总结一下，RedLock算法的优化方向可能包括：增强时钟同步的可靠性、引入自动续期机制、优化节点间的通信、提高容错能力、结合其他一致性协议等。需要具体分析每个可能的问题点，然后针对性地进行优化。</think>分布式锁是协调分布式系统资源访问的核心机制，RedLock算法是针对Redis集群的改进方案。以下从基础原理、优化方向、实现细节三个层面逐步解析： --- ### **一、基础原理：RedLock算法核心逻辑** 1. **核心目标** 解决单点Redis锁的缺陷（如主从切换导致锁失效），通过多节点投票机制提升可靠性。 2. **算法步骤** - **步骤1**：客户端向N个独立Redis节点依次发送加锁请求（使用`SET resource_name random_value NX PX ttl`）。 - **步骤2**：统计成功加锁的节点数，若超过半数（N/2 +1），且总耗时小于锁有效期（TTL），则认为加锁成功。 - **步骤3**：锁的实际有效时间 = TTL - 获取锁总耗时。 - **步骤4**：释放锁时需向所有节点发送Lua脚本（保证原子性删除）。 3. **数学表达** 设节点总数为$N$，成功加锁数为$k$，则需满足： $$k > \frac{N}{2}$$ --- ### **二、争议与问题分析** 1. **时钟同步问题** - **风险**：若节点时钟发生跳跃，可能导致锁提前释放。 - **数学表达**：假设锁有效期$T$，时钟跳跃$\Delta t$，则实际有效时间为$T \pm \Delta t$。 2. **网络延迟与GC停顿** 客户端或Redis节点的网络延迟、GC停顿可能导致锁状态误判。 3. **容错能力限制** 节点故障可能导致可用节点不足，需动态调整节点数量。 --- ### **三、优化方向与方案** #### **1. 增强时钟同步可靠性** - **方案**：部署NTP服务强制同步时钟，或使用**单调时钟**（Monotonic Clock）替代系统时钟。 - **原理**：单调时钟不受系统时间调整影响，仅计算流逝时间。 #### **2. 锁续期机制（Watchdog）** - **方案**：客户端启动后台线程，定期（如每隔$T/3$）向所有节点发送续期请求。 - **数学表达**：设锁有效期$T$，续期间隔为$\frac{T}{3}$，确保至少两次续期失败后锁才释放。 #### **3. 容错与动态节点管理** - **方案**： - 监控节点健康状态，自动剔除故障节点。 - 动态调整总节点数$N$，确保半数以上可用。 - **数学条件**：存活节点数$M$需满足$M \geq \lceil \frac{N}{2} \rceil +1$。 #### **4. 减少网络开销** - **方案**：并行发送加锁请求（而非串行），用公式优化超时时间。 - **超时公式**：单个节点超时时间$t_{timeout} = \alpha \cdot RTT_{avg} + \beta \cdot RTT_{var}$，其中$\alpha, \beta$为调节系数。 #### **5. 结合一致性协议** - **方案**：引入Raft/Paxos协议管理Redis节点，提升数据一致性。 - **适用场景**：对强一致性要求极高的场景（如金融交易）。 --- ### **四、代码实现示例（优化版RedLock）** ```python import redis import time class RedLockOptimized: def __init__(self, nodes): self.nodes = nodes # 动态节点列表 self.quorum = len(nodes) // 2 + 1 self.lock_ttl = 30000 # 锁有效期30秒 self.watchdog_interval = 10000 # 续期间隔10秒 def acquire(self, resource): start_time = time.monotonic() * 1000 # 使用单调时钟 success_nodes = [] # 并行请求加锁（伪代码） for node in self.nodes: if node.set(resource, random_value, nx=True, px=self.lock_ttl): success_nodes.append(node) elapsed_time = time.monotonic() * 1000 - start_time if len(success_nodes) >= self.quorum and elapsed_time < self.lock_ttl: # 启动看门狗线程续期 self.start_watchdog(resource, success_nodes) return True else: self.release(success_nodes, resource) return False def start_watchdog(self, resource, nodes): def renew(): while self.lock_held: for node in nodes: node.expire(resource, self.lock_ttl) time.sleep(self.watchdog_interval / 1000) threading.Thread(target=renew).start() ``` --- ### **五、总结** - **核心优化点**：时钟同步、锁续期、动态容错、网络开销控制。 - **适用场景**：高并发分布式系统（如秒杀、库存扣减）。 - **权衡**：优化可能增加实现复杂度，需根据业务需求平衡性能与一致性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

范大

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值