使用 etcd 的分布式锁进行选主的尝试

最新推荐文章于 2025-03-30 12:03:10 发布
最新推荐文章于 2025-03-30 12:03:10 发布
阅读量1.7k 收藏 1
点赞数 2
CC 4.0 BY-SA版权
分类专栏： etcd 文章标签： etcd 分布式锁
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Koprvhdix/article/details/94593849
项目因有很多定时任务，在实现高可用时需选主，此前用zookeeper选主，但项目已用etcd，再引入zookeeper不合适。本文介绍了etcd的v3lock分布式锁，创建时需绑定租约，获取锁时若已被创建线程会阻塞，还阐述了选主流程及不同执行情况的处理。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

最近做项目在使用 etcd， 由于项目里很多定时任务，在实现高可用的时候需要进行选主，即只执行一次定时任务。之前的项目用的是 zookeeper 进行选主。大概思路是抢一个key，没抢到的就不执行了，抢到的就执行，类似于 redis 的 setnx 。因为项目本身用了 etcd，所以再引入 zookeeper 是不太合适的，同时 zookeeper 选主一旦定时任务如果执行失败，无法重试。

etcd 的分布式锁

  • 本文使用的分布式锁是 etcd 的 v3lock，附上官网文档 。
  • etcd 在创建分布式锁的时候必须绑定租约（Lease）。
  • 在获取分布式锁的时候，如果锁已经被创建，线程会阻塞，直到锁被释放。假设 A、B、C 三个线程租约都是 50 秒，同时去抢锁，然后假设 A 线程抢到了，B、C 就都在阻塞了，必须等租约 50 秒到期，或者 A 释放锁。
  • 如果 A 在执行很顺利，那么执行成功之后，A 需要把自己的租约 ID 写到 SuccessLease 这个 key 里面。这样 B、C 在获取锁之后，可以去查看 SuccessLease ，如果里面对应的租约没有到期，则说明 A 是执行成功了的，即无需再执行一次；如果租约到期了（上一次定时任务写入的），或者这个 key 不存在，则说明之前的执行是失败的，或者无效，那么当前线程可以进行临界区操作。
  • 如果 A 执行失败，比如报错了，或者线程挂了。那么 B、C 只能等租约到期，再获取锁，请注意：这时候 B 和 C 会同时获取锁，所以必须 B、C 必须看一下自己的租约到期了没有，如果到期了，说明获取锁是无效的，要新建一个租约，重新获取锁。

分布式锁选主流程设计
获取成功
到期
没到期
获取成功
过期
获取失败
没过期
Start
创建租约 LeaseA
获取分布式锁 LockB
判断 LeaseA 是否到期
进入临界区
获取 SuccessLease
判断 SuccessLease 是否过期
进行操作
释放 LockB 并退出临界区
将 LeaseA 写入 SuccessLease
结束

结束语

  • 第一次画流程图，有点长，路漫漫其修远兮，加油加油！
第09课：基于 Etcd 的分布式锁实现原理及方案
Jin_Kwok的博客
10-28 1312
Etcd 最新版本已经提供了支持分布式锁的基础接口（可见官网说明），但本文并不局限于此。 本文将介绍两条实现分布式锁的技术路线： 从分布式锁的原理出发，结合 Etcd 的特性，洞见分布式锁的实现细节； 基于 Etcd 提供的分布式锁基础接口进行封装，实现分布式锁。 两条路线差距甚远，建议读者先看路线 1，以便了解 Etcd 实现分布式锁的细节。 1. 为什么选择 Etcd 据官网介绍，Etcd...
基于Etcd的分布式锁是一种利用Etcd键值存储系统实现的分布式锁机制
BLOG域名:programb.blog.youkuaiyun.com
12-05 646
基于Etcd的分布式锁是一种利用Etcd键值存储系统实现的分布式锁机制。Etcd是一个高可用的键值存储，它提供了一种可靠的方式在分布式系统中进行配置共享和服务发现。通过Etcd实现的分布式锁可以保证在多个进程或服务间对共享资源的安全访问。Etcd是一个分布式键值存储系统，它通过Raft一致性算法来保证数据的一致性。Raft算法是一种用于管理复制日志的一致性算法，它确保在分布式系统中多个节点之间的数据副本保持一致。
Java开发高级工程师面试，etcd：一款比Redis更骚的分布式锁的实现方式
m0_60732427的博客
08-07 606
Watch 机制支持 Watch 某个固定的 key，也支持 Watch 一个范围（前缀机制）。 当被 Watch 的 key 或范围发生变化，客户端将收到通知；在实现分布式锁时，如果抢锁失败， 可通过 Prefix 机制返回的 Key-Value 列表获得 Revision 比自己小且相差最小的 key（称为 pre-key）， 对 pre-key 进行监听，因为只有它释放锁，自己才能获得锁，如果 Watch 到 pre-key 的 DELETE 事件， 则说明 pre-key 已经释放，自己将持有锁。
Etcd教程 — 第九章 Etcd之实现分布式锁
Mr_XiMu的博客
06-29 1659
Etcd教程 — 第九章 Etcd之实现分布式锁
etcd实现分布式锁
liuyuede123的博客
09-04 1264
当并发的访问共享资源的时候，如果没有加锁的话，无法保证共享资源安全性和正确性。这个时候就需要用到锁1、需要具备的特性需要保证互斥访问（分布式环境需要保证不同节点、不同线程的互斥访问）需要有超时机制，防
【etcd】go etcd实战二：分布式锁
SauryN的博客
11-01 1199
基于etcd实现的分布式锁的使用及封装
etcd之etcd分布式锁及事务(四)
YIYIYI
10-24 849
etcd之etcd分布式锁及事务(四)
go etcd分布式锁的方案代码
leijmdas的专栏
03-30 431
的分布式锁的完整 Go 代码实现，包含锁的获取、自动续租、释放锁等核心功能，并附有详细注释和注意事项。fmt.Printf("协程 %d 获取锁失败: %v\n", id, err)return fmt.Errorf("创建租约失败: %v", err)return fmt.Errorf("事务提交失败: %v", err)return fmt.Errorf("释放租约失败: %v", err)return fmt.Errorf("续租失败: %v", err)
【ETCD】【实操篇（十一）】用 Go 搭建基于 ETCD 的分布式锁，秒懂分布式同步
zhangshenglu1的博客
12-24 951
ETCD 是一个高可用的分布式键值存储系统，常用于配置管理和服务发现。ETCD 的分布式一致性和租约机制，使得它非常适合用来实现分布式锁。
分布式锁实现解析：几种简单方式的对比与选择
热门推荐
张彦峰的博客
12-25 172万+
本文分析了几种常见的分布式锁实现方式，包括基于Redis、ZooKeeper和数据库的方案。通过对每种方式的原理、优缺点进行深入剖析，本文旨在帮助开发者根据不同的应用场景选择合适的分布式锁实现。同时，文章还讨论了分布式锁的使用建议和最佳实践，为解决分布式系统中的并发控制问题提供了有效的参考。
分布式锁实现（基于etcd）
wzbwzt的博客
03-18 420
地址：github.com/wzbwzt/dlock 下载库： go get -u github.com/wzbwzt/dlock 使用事例： etcd := etcd.NewRegister(etcd.WithTimeOut(time.Second * 5)) lock := dlock.NewDlock(dlock.WithRegister(etcd)) //获取etcd的客户端 // etcdclient:=etcd.GetEtcdClient() path := "/lock/a" lock.L
ETCD实现分布式锁
m0_62969222的博客
05-15 2126
基于etcd实现的分布式锁基本上使用到了etcd的全部性质，并且保证了分布式锁的互斥性，安全性和可用性。官方实现的分布式锁并不支持可重入性，但是要实现可重入性锁也很简单，对这个锁在封装一层，并增加一个计数器。参考资料极客时间- etcd实战课etcd分布式锁的实现原理。
etcd 笔记（08）— 基于 etcd 实现分布式锁
wohu1104的专栏
05-10 924
1. 为什么需要分布式锁？ 在分布式环境下，数据一致性问题一直是个难点。分布式与单机环境最大的不同在于它不是多线程而是多进程。由于多线程可以共享堆内存，因此可以简单地采取内存作为标记存储位置。而多进程可能都不在同一台物理机上，就需要将标记存储在一个所有进程都能看到的地方。 例如秒杀场景就是一个常见的多进程场景。订单服务部署了多个服务实例，如秒杀商品有 4 个，第一个用户购买 3 个，第二个用户购买 2 个，理想状态下第一个用户能购买成功，第二个用户提示购买失败，反之亦可。而实际可能出现的情况是，两个用户都得
分布式锁(3)--基于Etcd的分布式锁实现
aobulaien001的博客
10-27 659
当我学到一定基础，有自己的理解能力的时候，会去阅读一些前辈整理的书籍或者手写的笔记资料，这些笔记详细记载了他们对一些技术点的理解，这些理解是比较独到，可以学到不一样的思路。Python所有方向的技术点做的整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照下面的知识点去找对应的学习资源，保证自己学得较为全面。实现分布式锁会非常的方便，同时它是通过HTTP/gRPC提供对应的API，所以它的客户端实现也比较方便，当然如果当前系统依赖的是。的作用，实现的分布式锁默认带有了公平锁的功能，接下来开始手撸。
etcd 分布式锁
weixin_30784945的博客
10-29 565
1.安装etcd。如果是cluster至少要三个节点,在官网上下载二进制包解压,编写配置文件,如果使用阿里云或腾讯云等，记得安全组里面开放端口2379、2380。 name: 'node001' data-dir: /data/etcd/cluster listen-peer-urls: http://172.200.101.1:2380 listen-client-urls: htt...
还活在上个时代，Etcd 3.0 实现分布式锁竟如此简单
04-19 1733
传统 Python 单机系统部署中，由于 GIL 的存在，相同进程中我们可以不用处理并发问题。但是随着业务发展需要，原有单机系统演变成分布式或多进程系统后。这将使原有的单机单进程并发控制策略失效。为了解决该问题需要引入一种跨进程、跨机器的互斥锁机制来控制共享资源的访问，这也就是分布式锁的由来。 所以，分布式锁的引入是为了保障多台机器或多个进程对共享资源读写的同步，保证数据的最终一致性。...
用Etcd实现分布式锁和选主
weixin_33937913的博客
02-22 539
Etcd的v3版本官方client里有一个concurrency的包，里面实现了分布式锁和选主。本文分析一下它是如何实现的。 先贴一下锁的code (https://github.com/coreos/etcd/blob/master/clientv3/concurrency/mutex.go#L26)。 在code中注释介绍了具体的实现。 //m.pf...
卖的意思分布式锁怎么加的？
最新发布
07-18
<think>首先，用户的问题是关于分布式锁的实现：他们想知道分布式锁是如何实现的，以及如何在分布式系统中添加分布式锁。我需要基于提供的引用内容来构建一个结构清晰的回答。 关键引用： - 引用[1]：提到Redis非常适合作为分布式锁使用，并讨论了七个方案。 - 引用[2]：解释了为什么单机锁不能用于分布式系统，并提到了使用Redis实现分布式锁。 - 引用[3]：讨论了ZooKeeper如何实现分布式锁，包括临时节点、顺序节点和监听机制。 - 引用[4]：提到了常见的分布式锁类型，包括Redis的Redlock算法，并指出了Redis主从同步的缺点。 用户意图是了解如何在分布式系统中实现或添加分布式锁的机制。所以，我需要覆盖实现原理和添加方法。 回答结构： 1. **介绍分布式锁的概念**：简要解释什么是分布式锁，为什么它在分布式系统中重要。 2. **实现原理**：讨论常见的实现方式，如Redis和ZooKeeper。 3. **如何添加分布式锁**：提供步骤或示例，展示如何在系统中添加分布式锁。 4. **相关问题**：生成相关问题作为结尾。 系统指令： - 使用中文回答。 - 行内数学表达式用$...$，例如变量。 - 独立公式用$$...$$。 - 引用段落末尾添加引用标识，例如[^1]。 - 生成相关问题。 - 回答结构清晰，逐步解决问题。 回答大纲： 1. **引言**：解释分布式锁的必要性。 2. **实现方式**： - 基于Redis的实现：描述使用SET命令（如SETNX）和Redlock算法。 - 基于ZooKeeper的实现：描述使用临时顺序节点和监听机制。 - 其他方式（如数据库），但引用中主要提到Redis和ZooKeeper。 3. **添加分布式锁的步骤**： - 通用步骤：选择锁服务、实现锁获取、释放、处理超时和故障。 - 具体示例：伪代码或简单代码示例（如Python或Java），但引用中有Java，所以可能用Java。 4. **优缺点和注意事项**：讨论Redis和ZooKeeper的优缺点，如Redis的性能但存在主从同步问题，ZooKeeper的可靠性但复杂性。 5. **相关问题**：生成3-5个相关问题。 引用处理： - 在回答中自然地引用参考内容。例如，当提到Redis时，引用[1]和[2]；当提到ZooKeeper时，引用[3]；当讨论缺点时，引用[4]。 - 引用标识如[^1]，放在相关句子末尾。 数学表达式：用户问题不涉及数学，所以可能不需要。如果有变量，用$...$。 相关问题生成： - 基于主题，生成类似示例的问题： 1. Redis分布式锁的常见问题有哪些？ 2. ZooKeeper分布式锁是如何保证一致性的？ 3. 分布式锁在微服务架构中的应用场景？ 4. 如何选择Redis和ZooKeeper作为分布式锁？ 确保回答真实可靠：基于引用内容，不添加虚构信息。引用是站内引用，所以使用它们来支持论点。 最终回答结构： - 开头：直接回答问题。 - 主体：分步解释。 - 结尾：相关问题。</think>### 分布式锁的实现与添加方法 在分布式系统中，分布式锁是一种用于协调多个节点访问共享资源的机制，确保在并发环境下资源操作的互斥性和一致性。由于分布式系统涉及多台服务器，单机锁（如Java的`synchronized`）无法满足需求，因为请求可能被分发到不同节点，导致锁失效[^2]。以下我将逐步解释分布式锁的实现原理，并指导如何在系统中添加它。内容基于可靠的技术实践，包括Redis和ZooKeeper等常见方案。 #### 1. **分布式锁的实现原理** 分布式锁的核心是确保在分布式环境中，只有一个节点能持有锁。实现方式多样，主要分为两类：基于存储系统（如Redis）和基于协调服务（如ZooKeeper）。以下是主流方法的原理： - **基于Redis的实现**： Redis通过原子命令（如`SET key value NX PX timeout`）实现分布式锁。其中： - `NX` 确保键不存在时才设置（获取锁）。 - `PX` 设置锁的超时时间，防止死锁。 - 锁释放时，客户端需删除键（但需处理误删问题，例如使用Lua脚本保证原子性）。 例如，获取锁的命令可表示为：$SET \ lock\_key \ unique\_value \ NX \ PX \ 10000$，这表示如果`lock_key`不存在，则设置一个10秒超时的锁[^1][^2]。 然而，Redis的主从同步是异步的，如果主节点在同步前故障，可能导致锁失效（例如，新主节点未同步锁状态，其他节点可获取锁）。为解决此问题，可使用Redlock算法：它要求客户端向多个独立Redis实例获取锁，多数成功才算获取锁，提高可靠性[^4]。 - **基于ZooKeeper的实现**： ZooKeeper利用临时顺序节点和监听机制实现锁： - 客户端在指定路径（如`/locks`）下创建临时顺序节点（如`/locks/lock_000001`）。 - 节点序号最小的客户端获取锁；其他客户端监听前一个节点的删除事件。 - 当锁释放时（客户端断开或显式删除节点），ZooKeeper自动触发监听，通知下一个节点获取锁。 这种方式强一致性高，因为ZooKeeper保证所有节点状态一致，但性能低于Redis[^3]。 其他方式如数据库锁（基于唯一索引）或etcd，但Redis和ZooKeeper是工业界主流。选择时需权衡：Redis高性能但可能不保证强一致；ZooKeeper强一致但引入额外复杂度。 #### 2. **如何在分布式系统中添加分布式锁** 添加分布式锁涉及选择锁服务、集成锁逻辑到应用代码、处理异常和超时。以下是通用步骤和示例： - **步骤1：选择锁服务** 根据系统需求选择： - 高并发、低一致性要求：用Redis（推荐Redlock算法避免单点故障）[^1][^4]。 - 强一致性、高可靠场景：用ZooKeeper[^3]。 例如，在秒杀系统中，Redis更合适；在金融交易中，ZooKeeper更可靠。 - **步骤2：实现锁获取与释放逻辑** 以Redis为例（使用Java和Jedis客户端）： ```java import redis.clients.jedis.Jedis; import java.util.UUID; public class DistributedLock { private static final String LOCK_KEY = "resource_lock"; private static final int LOCK_TIMEOUT = 10000; // 10秒超时 public String acquireLock(Jedis jedis) { String lockValue = UUID.randomUUID().toString(); // 唯一标识，防止误删 // 尝试获取锁：NX表示不存在才设置，PX设置超时 String result = jedis.set(LOCK_KEY, lockValue, "NX", "PX", LOCK_TIMEOUT); if ("OK".equals(result)) { return lockValue; // 获取成功 } return null; // 获取失败 } public boolean releaseLock(Jedis jedis, String lockValue) { // 使用Lua脚本保证原子性：比较值匹配才删除 String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) " + "else return 0 end"; Object result = jedis.eval(script, 1, LOCK_KEY, lockValue); return result.equals(1L); // 删除成功返回true } } ``` 关键点： - **获取锁**：调用`acquireLock`，使用唯一值（如UUID）避免其他客户端误删。 - **释放锁**：调用`releaseLock`，用Lua脚本确保原子操作[^1][^2]。 - **超时处理**：设置超时（如10秒），防止客户端崩溃导致死锁。可添加重试机制（如指数退避）。 对于ZooKeeper，使用Curator框架简化代码： ```java import org.apache.curator.framework.CuratorFramework; import org.apache.curator.framework.recipes.locks.InterProcessMutex; public class ZkDistributedLock { private InterProcessMutex lock; public ZkDistributedLock(CuratorFramework client, String lockPath) { lock = new InterProcessMutex(client, lockPath); // 路径如"/locks/resource" } public boolean acquireLock() throws Exception { return lock.acquire(10, TimeUnit.SECONDS); // 尝试获取锁，最多等10秒 } public void releaseLock() throws Exception { lock.release(); // 释放锁，ZooKeeper自动删除临时节点 } } ``` 这里，`InterProcessMutex`自动处理节点创建和监听，简化开发[^3]。 - **步骤3：集成到业务逻辑** 在分布式应用中，锁用于保护临界区资源。例如，在秒杀下单场景： ```java public void handleOrder(String productId) { Jedis jedis = new Jedis("redis-host"); // 连接Redis String lockValue = acquireLock(jedis); if (lockValue != null) { try { // 临界区：检查库存、减库存、创建订单 if (checkStock(productId) > 0) { reduceStock(productId); createOrder(productId); } } finally { releaseLock(jedis, lockValue); // 确保释放锁 } } else { // 锁获取失败，重试或返回错误 } } ``` 注意事项： - **故障恢复**：添加日志和监控，处理Redis或ZooKeeper故障（如使用集群）。 - **性能优化**：锁粒度要细（如按资源ID加锁），避免全局锁瓶颈[^1]。 - **测试**：模拟节点故障和高并发，验证锁的正确性。 #### 3. **优缺点总结** - **Redis**：优点高性能、易用；缺点主从同步可能导致锁失效（需Redlock缓解）[^4]。 - **ZooKeeper**：优点强一致、可靠；缺点性能较低、部署复杂[^3]。 实际添加时，评估系统需求：如果每秒处理上万请求，优先Redis；如果需强一致性（如银行交易），选ZooKeeper。 通过以上步骤，您可以在分布式系统中有效添加分布式锁机制。如果需要更具体的语言实现（如Python或Go），或针对特定场景优化，请提供更多细节。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值