分布式锁 redis与zookeeper

原创 已于 2024-08-26 23:51:30 修改 · 686 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#分布式 #redis #zookeeper

于 2024-08-25 23:51:03 首次发布

redis实现分布式锁

原理

基于redis命令setnx key value来实现分布式锁的功能，只有当key不存在时，setnx才可以设置成功并返回1，否则设置失败返回0。

方案1：

在这里插入图片描述

方案1存在的问题

假如在加锁成功，释放锁之前，服务器宕机了，这个锁就无法释放了，其他线程就永远无法获取到锁了。

改进之后

方案2

在这里插入图片描述

方案2存在的问题

获取锁和设置过期时间是2个命令，两次网络IO和redis交互，不具备原子性，可能出现获取锁成功之后 设置过期时间之前服务器宕机，导致其他线程永远都获取不到锁的现象。

方案3

1、将获取锁和设置过期时间放在lua脚本里面执行，lua脚本可以保证多个命令原子性的执行。
2、redis提供了其他命令在setnx的同时设置过期时间，分别如下所示：

  • set key value PX 多少毫秒 NX
  • set key value EX 多少秒 NX
    在这里插入图片描述
方案3存在的问题

锁过期释放了，但是业务仍没有执行完，等到执行完业务并释放锁的时候，释放的其实是其他线程获取到的锁。

  • 线程A获取到了锁，并设置过期时间10s。
  • 当过了10秒后，线程A仍然没有执行完，但是此时线程A获取到的锁已经达到了过期时间，导致锁被释放了。
  • 此时线程B获取到了锁，并执行业务方法
  • 线程A业务方法执行完，并执行释放锁逻辑（此时释放的是线程B获取到的锁）
  • 由于锁被释放，线程C也获取到了锁，并执行业务，此时线程B、线程C都获取到了同一个锁，并执行相应的业务。
方案4

在这里插入图片描述

方案4存在的问题

方案4中 判断key1的value1是否等于设置的值uuid，如果是则删除，否则不执行删除逻辑，由于是2个命令，不具备原子性导致可能出现以下场景

  • 线程A成功获取锁key1，设置key1的value为uuid1，并设置过期时间10秒。
  • 线程A执行完业务逻辑，准备删除锁
  • 线程A获取到key1的value uuid1。
  • 此时线程A的锁key1刚好到了过期时间
  • cpu时间片切换，线程A停止执行，线程B开始执行
  • 线程B尝试获取分布式锁key1（由于上面线程A设置的锁已经到了过期时间，所以此处可以获取成功）
  • cpu时间片切换，线程A继续执行，由于锁的value == uuid1,所以开始删除锁（此时删除的是线程B设置的分布式锁）。导致出现了删除其他线程设置的分布式锁。
方案五

在这里插入图片描述

方案5存在的问题

当前仍存在锁时间达到了过期时间，但是线程没执行完的问题。
如何解决呢？
watch dog机制（Redisson底层就是基于watch dog机制来实现分布式锁的自动续期，当未设置过期时间时，会默认设置30秒，并起一个看门狗线程，每十秒去检测一次，如果当前线程仍然在执行，就自动续期，当然，如果手动设置了过期时间，就不会自动续期了）。
在这里插入图片描述

方案五存在的问题

redis集群的场景下，redis-master节点设置成功了，但是redis-slave节点未设置成功，如下所示：

  • 当前redis集群有三个节点，分别是redis-master、redis-slave-a、redis-slave-b
  • 线程A尝试获取分布式锁，此时在redis-master上设置key1成功。
  • redis集群采用异步主从复制，但是redis-master上设置的key内容还没有同步到slave时，redis-master节点就宕机了。
  • 此时集群重新选举，因此redis-slave-a变成了mater节点
  • 此时有线程B尝试获取分布式锁key1，由于新的master节点上没有设置key1，因此线程B设置锁成功。
  • 当前线程A和线程B就都持有了分布式锁并执行业务逻辑。
方案6

如何解决方案五仍然存在的问题呢？
使用redlock（红锁）算法，这是一个专门用于解决这种问题的分布式锁协议。
redlock：不能只在一个redis实例上加锁，应该是在多个redis实例上创建锁，当创建成功数量达到(n/2 + 1)时，才能认为加锁成功

在这里插入图片描述
以上方式实现复杂、性能差、运维繁琐。
我们的redis是AP高可用思想、如果要实现强一致性，应该使用CP思想的zookeeper来实现，解决主从一致性问题。
C：Consistency;一致性
A：Availabilit;可用性
P：Partition Tolerance；分区容错性

zookeeper实现分布式锁

zookeeper的节点有以下几种类型；

  • 临时节点
    当客户端和zookeeper服务端断开连接时，临时节点就会被删除
  • 临时有序节点
    临时节点且都是有序的排列
  • 持久节点
    当客户端和zookeeper服务端断开连接时，持久节点也不会被删除
  • 持久有序节点
    持久节点且都有序的排列

zookeeper实现分布式锁就是利用到了临时有序节点。
在这里插入图片描述

区别

分布式锁实现方式(基于Redis的分布式锁+基于ZooKeeper的分布式锁)
m0_66572126的博客
04-25 528
这个示例代码创建了一个 `RedisDistributedLock` 类，它封装了 Redis 的连接和操作方法，并提供了获取锁和释放锁的功能。方法中，创建了一个临时顺序节点，并获取了父节点下的所有子节点，并对这些子节点进行排序。需要注意的是，该示例中使用的是 Redis 的单机模式，如果要在生产环境中使用 Redis 集群，需要使用相应的连接池和集群模式进行连接。需要注意的是，该示例中创建的节点是临时顺序节点，当客户端与 ZooKeeper 断开连接时，该节点会自动删除，从而释放锁。
分布式锁的实现：Redis和Zookeeper
weixin_53840353的博客
07-22 1176
在分布式系统中，确保数据的一致性和避免并发问题是非常重要的。分布式锁是解决这些问题的关键技术之一。本文将详细介绍如何使用Redis和Zookeeper实现分布式锁，并通过Java代码示例帮助读者理解其实现原理。
分布式锁Redis Zookeeper
awesometime的博客
01-20 709
分布式锁用 Redis 还是 Zookeeper？一级目录二级目录三级目录 一级目录 分布式锁用 Redis 还是 Zookeeper？ 二级目录 三级目录
Redis分布式锁和Zookeeper分布式锁的分享
Don0617的博客
05-30 863
1.为什么使用分布式锁 与分布式锁相对应的是单机锁，我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，资源争抢，通常会使用一把锁来互斥，以保证共享变量的正确性，其使用范围是在同一个进程中。 例如，现在的业务应用通常都是微服务架构，这也意味着一个应用会部署多个进程，那这多个进程如果需要修改MySQL中的同一行记录时，为了避免操作乱序导致数据错误，此时，我们就需要引入「分布式锁」来解决这个问题了。 想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上申请「加锁」。 而..
分布式锁（redis、zookeeper）
zhongzhh8的博客
12-28 1616
参考分布式锁用 Redis 还是 Zookeeper？ 分布式锁 当一个单点机器上有多个进程或者多个线程需要互斥访问一个共享资源时，就需要用到锁，这种情况下，只需要用各个编程语言库的锁即可，比如C++的pthread_mutex_lock，Java的synchronized和ReentrantLock等等来加锁。 但是本机的锁只能被本机的进程访问，而现实中的许多业务的访问量一般都比较大，单点机器无法支撑，必须多点部署，此时如果不同机器上的进程/线程仍然需要互斥访问一个全局的共享资源的话，就必须使用分布式锁，
【redis】redis和zookeeper分布式锁的区别(优点、缺点)
m0_45406092的博客
06-24 1万+
文章目录1. 什么是分布式锁1. 1 分布式锁的原理是什么2. 单机2.1 redis可能会丢数据吗2.2 死锁2.3 注意事项3. 集群3.1 redis3.2 zookeeper4. 结论 1. 什么是分布式锁 锁，解决的是多线程或多进程情况下的数据一致性问题；分布式锁，解决的是分布式集群下的数据一致性问题。 为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进
分布式锁--redis和ZooKeeper
clear_0217的博客
11-18 901
第二步:服务B为了得到多，向Redis发起同样的命令，但是由于Redis中存在同名的key，且并未过去，因此执行命令失败，服务B 未能获得锁，服务B进入循环请求的状态，比如每秒向Redis发起请求，直达成功获取到锁。第四步：服务A执行完毕，为了释放锁，服务A会主动向Redis发起删除key的命令，注意：删除key前，一定要判断服务A持有的value与redis内存存储的value是否一致。指的是当且仅当key在Redis中不存在的时候执行成功，否则失败，情况2：加锁后，程序没有执行释放锁，程序挂了。
redis和zookeeper实现分布式锁的区别
01-20
Redis和Zookeeper是两种常用的分布式协调服务，它们都可以用来实现分布式锁，但具体实现方式和特性有所不同。 **Redis分布式锁** Redis作为内存数据库，具有高性能、低延迟的特点，常被用作实现分布式锁。Redis...
分布式锁实现方案--redis、zookeeper、mysql
ljran0612的专栏
08-13 1652
因为我这里是以三个节点为例。锁key的值附加唯一性：针对释放别人锁这种问题，我们可以给每个客户端进程设置【唯一ID】，作为锁（所有客户端锁key相同）的值，这样我们就可以在应用层就进行检查唯一ID。我们了解下什么是【可重入】：指的是同一个线程在持有锁的情况下，可以多次获取该锁而不会造成死锁，也就是一个线程可以在获取锁之后再次获取同一个锁，而不需要等待锁释放。InterProcessMultiLock：将多个锁作为单个实体管理的容器，获取锁的时候获取所有锁，释放锁也会释放所有锁资源（忽略释放失败的锁）。
分布式锁用 Redis 还是 Zookeeper？
Linuxhus的博客
07-14 920
在讨论这个问题之前，我们先来看一个业务场景：系统A是一个电商系统，目前是一台机器部署，系统中有一个用户下订单的接口，但是用户下订单之前一定要去检查一下库存，确保库存足够了才会给用户下单。由于系统有一定的并发，所以会预先将商品的库存保存在redis中，用户下单的时候会更新redis的库存。此时系统架构如下：但是这样一来会产生一个问题：假如某个时刻，redis里面的某个商品库存为1，此时两个请求同时到来，其中一个请求执行到上图的第3步，更新数据库的库存为0，但是第4步还没有执行。而另外一个请求执行到了第2步，发
分布式锁基于Redis和Zookeeper的实现方案
rui920418的博客
05-29 1538
一、为什么要用分布式锁？如果不同的系统之间共享了一组资源，那么访问这组资源的时候，往往就需要通过一些互斥的手段来防止彼此间的干扰，以保证数据的一致性。1、在单机部署的系统中，使用线程锁来解决高并发的问题，多线程访问共享变量的问题达到数据一致性，例如使用synchornized、ReentrantLock等。2、在多机部署的系统中，是在不同的JVM虚拟机中运行的，就无法使用JDK提供的Api来解决并...
Redis 实现分布式锁和Zookeeper实现分布式锁
努力奔跑
05-07 2万+
使用 Redis 实现分布式锁 在 JUC 包中除了阻塞锁外还有一种叫 CAS 的无阻塞锁（具体可以参考：Java 并发编程之美：并发编程基础晋级篇），CAS 操作本身是原子性的，多个线程操作同一个变量的 CAS 时候只有一个线程能进行 CAS 成功，失败的线程接下来那么使用乐观锁机制直接失败要么使用自旋方式使用 CPU 资源重复进行 CAS 尝试。 那么在分布式锁的实现中我们也可以使用类似的方式...
关于分布式锁原理的一些学习与思考-redis分布式锁，zookeeper分布式锁
ت
05-15 186
首先分布式锁和我们平常讲到的锁原理基本一样，目的就是确保，在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。 在一个进程中，也就是一个jvm 或者说应用中，我们很容易去处理控制，在jdk java.util 并发包中已经为我们提供了这些方法去加锁， 比如synchronized 关键字 或者Lock 锁，都可以处理。 但是我们现在的应用程序如果只部署一台服务器，那并发量是很差的，如果同时有上万的请求那么很有可能造成服务器压力过大，而瘫痪。 想想双十一 和 三十晚上十点分支付宝红包等业
分布式锁的几种使用方式（redis、zookeeper、数据库）
热门推荐
南北雪树的专栏
01-08 3万+
Q:一个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费 synchronized lock db lock Q：两个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费 分布式锁 我们需要怎么样的分布式锁？ 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 这把锁要是一把可重入锁（避免死锁） 这把锁最好是一把
redis实现分布式锁问题
qq_37191690的博客
09-27 738
使用Redis作为分布式锁的一些注意点 </div> Redis实现分布式锁 最近看分布式锁的过程中看到一篇不错的文章，特地的加工一番自己的理解： Redis分布式锁实现的三个核心要素： 1.加锁 最简单的方法是使用setnx命令。key是锁的唯一标识，按业务来决定命名，value为当前线程的线程ID。 比如想要给一种商品的秒杀活动加锁，可以给key命名为 “lock_sale_ID” 。而value设置成什么呢？我们可以姑且设置成1。加锁的伪代码如下： ...
基于redis和zookeeper的分布式锁实现方式
weixin_40581617的博客
06-11 1005
先来说说什么是分布式锁，简单来说，分布式锁就是在分布式并发场景中，能够实现多节点的代码同步的一种机制。从实现角度来看，主要有两种方式：基于redis的方式和基于zookeeper的方式，下面分别简单介绍下这两种方式：　一、基于redis的分布式锁实现　　1.获取锁　　redis是一种key-value形式的NOSQL数据库，常用于作服务器的缓存。从redis v2.6.12开始，set命令开始变成...
分布式之抉择分布式锁
derek2538的博客
07-24 1030
引言 为什么写这篇文章？ 目前网上大部分的基于zookeeper，和redis的分布式锁的文章都不够全面。要么就是特意避开集群的情况，要么就是考虑不全，读者看着还是一脸迷茫。坦白说，这种老题材，很难写出新创意，博主内心战战兢兢，如履薄冰，文中有什么不严谨之处，欢迎批评。 博主的这篇文章，不上代码，只讲分析。 (1)在redis方面，有开源redisson的jar包供你使用。 ...
redis和zookeeper分布式锁实现及比对
学习无止境、创作无瓶颈
07-25 6594
一、redis分布式锁 官方支持的一种分布式锁，叫做RedLock算法。 这个分布式锁有3个重要的考量点，互斥（只能有一个客户端获取锁），不能死锁，容错（大部分redis节点或者这个锁就可以加可以释放）！ 1、最普通的实现方式 就是在redis里创建一个key算加锁 SET my:lock 随机值 NX PX 30000，这个命令就ok。 这个的NX的意思就是只有key不存在的时候...
分布式锁redis & zookeeper怎么选
最新发布
09-24
在分布式系统中，**Redis** 和 **ZooKeeper** 均可用于实现分布式锁，但它们的底层机制、适用场景和优缺点不同。选择时需结合业务需求（如性能、一致性、容错性等）。以下是两者的详细对比和选型建议： --- ### **1. Redis 分布式锁** #### **实现方式** - **基于 SETNX（SET IF NOT EXISTS）**： 使用 `SET key value NX PX milliseconds` 命令（Redis 2.6.12+），通过唯一值（如 UUID）标识客户端，避免误删其他客户端的锁。 ```bash SET lock_key unique_value NX PX 30000 # 30秒后自动过期 ``` - **Redlock 算法**（Redis 官方推荐）： 在多个独立的 Redis 节点上尝试加锁，需获得大多数节点的锁才算成功，提高可靠性。 #### **优点** - **高性能**：Redis 是内存数据库，操作耗时在微秒级，适合高并发场景。 - **简单易用**：API 直观，支持自动过期（避免死锁）。 - **灵活扩展**：可通过 Lua 脚本实现更复杂的逻辑（如锁续期）。 #### **缺点** - **非强一致性**：Redis 主从切换或集群分区时，可能导致锁丢失（如主节点未同步数据到从节点就崩溃）。 - **时钟漂移风险**：依赖服务器时间设置过期时间，若时钟不同步可能导致锁提前/延后释放。 - **需要处理锁续期**：若业务执行时间超过锁的 TTL，需手动续期（如 Redisson 的 `WatchDog` 机制）。 #### **适用场景** - 对性能要求高，允许偶尔锁失效（如秒杀系统、库存扣减）。 - 业务执行时间较短（远小于锁的 TTL）。 - 集群规模较小，网络分区概率低。 --- ### **2. ZooKeeper 分布式锁** #### **实现方式** - **临时顺序节点 + Watcher**： 1. 客户端在 `/locks` 目录下创建临时顺序节点（如 `/locks/lock-0000000001`）。 2. 检查自己是否是目录下最小的节点，若是则获取锁；否则监听前一个节点的删除事件。 3. 前一个节点释放时，Watcher 触发，当前节点重新检查是否为最小节点。 #### **优点** - **强一致性**：ZooKeeper 通过 ZAB 协议保证数据一致性，锁的获取和释放是原子性的。 - **天然防死锁**：临时节点在客户端断开连接时自动删除，避免锁残留。 - **顺序性支持**：可实现公平锁（按请求顺序获取锁）。 #### **缺点** - **性能较低**：ZooKeeper 是 CP 系统（优先保证一致性），每次操作涉及磁盘 I/O（写持久化日志），耗时在毫秒级。 - **实现复杂**：需处理节点监听、重试逻辑，代码量比 Redis 多。 - **集群规模受限**：ZooKeeper 适合节点数较少的集群（如 3-5 台），大规模部署成本高。 #### **适用场景** - 对一致性要求极高，不能容忍锁失效（如金融交易、分布式事务）。 - 业务执行时间不确定，需要可靠的锁释放机制。 - 集群规模较大，网络分区概率高。 --- ### **3. 关键对比** | **维度** | **Redis** | **ZooKeeper** | |------------------|------------------------------------|-----------------------------------| | **一致性** | 最终一致（AP 系统） | 强一致（CP 系统） | | **性能** | 高（微秒级） | 低（毫秒级） | | **实现复杂度** | 简单（单条命令或 Lua 脚本） | 复杂（需处理节点监听和顺序） | | **死锁风险** | 需手动续期或依赖 TTL | 临时节点自动释放，无死锁 | | **公平性** | 非公平锁（默认） | 可实现公平锁（按顺序获取） | | **适用场景** | 高并发、短任务 | 强一致、长任务 | --- ### **4. 选型建议** #### **选 Redis 的情况** - 业务允许偶尔锁失效（如日志处理、缓存更新）。 - 需要支持每秒数千次以上的锁请求。 - 团队熟悉 Redis 生态（如使用 Redisson 客户端）。 #### **选 ZooKeeper 的情况** - 业务必须保证锁的强一致性（如支付系统、分布式协调）。 - 任务执行时间较长（如分钟级），需避免锁被误删。 - 已有 ZooKeeper 集群，希望复用基础设施。 --- ### **5. 混合方案（可选）** - **Redis + ZooKeeper**： 用 Redis 实现高性能锁，ZooKeeper 作为后备（如 Redis 锁失效时通过 ZooKeeper 重试）。 - **ETCD**： 类似 ZooKeeper 的强一致系统，性能更优（基于 Raft 协议），适合 Kubernetes 生态。 --- ### **6. 最佳实践** - **Redis 锁**： - 使用 Redisson 等成熟客户端（内置锁续期、异常处理）。 - 锁的 TTL 设置为业务预期最大时间的 2-3 倍。 - **ZooKeeper 锁**： - 使用 Curator 框架简化实现（提供 `InterProcessMutex` 等工具类）。 - 避免在锁内执行耗时操作（如网络请求、磁盘 I/O）。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值