21 | 分布式锁:为什么基于etcd实现分布式锁比Redis锁更安全?
该思维导图由 AI 生成,仅供参考
从茅台超卖案例看分布式锁要素
- 深入了解
- 翻译
- 解释
- 总结
etcd分布式锁相比Redis锁更安全的原因是什么?本文通过一个茅台超卖案例,对比了基于Redis实现的分布式锁和etcd分布式锁的优缺点。文章首先介绍了分布式锁的背景和重要性,然后通过茅台超卖案例分析了基于Redis实现的分布式锁存在的问题,如NX参数的作用、活性和高性能、高可用性等核心要素。文章指出,基于Redis实现的分布式锁存在安全性问题,如死锁、超卖等,需要注意原子性、唯一性等方面。最后,文章提出了etcd分布式锁相对于Redis锁更安全的原因,包括etcd的强一致性、高可用性和更适合复杂业务场景等特点。文章通过具体案例和技术要点,深入浅出地介绍了分布式锁的实现和安全性问题,对读者了解分布式锁的应用场景、核心原理以及安全性问题具有一定的指导意义。文章还介绍了ZooKeeper分布式锁和etcd分布式锁的实现方式,重点阐述了etcd分布式锁的安全性、互斥性、活性等方面。通过对比分析,文章强调了etcd分布式锁相对于Redis锁的优势,为读者提供了全面的技术视角和实践指导。 etcd自带的concurrency包为了帮助你简化分布式锁、分布式选举、分布式事务的实现,etcd社区提供了一个名为concurrency包帮助你更简单、正确地使用分布式锁、分布式选举。文章通过具体代码示例介绍了如何使用concurrency包创建Session和Mutex对象,并通过Lock和Unlock方法实现分布式锁的获取和释放。同时,文章深入解析了Mutex对象的Lock方法的实现原理,以及未获得锁的client是如何通过Watch机制进行等待的。最后,文章通过对Redis分布式锁实现问题、RedLock分布式锁和etcd分布式锁的技术点进行了总结,强调了etcd分布式锁的安全性、互斥性和活性等优势,为读者提供了全面的技术视角和实践指导。 总的来说,本文通过具体案例和技术要点,深入浅出地介绍了分布式锁的实现和安全性问题,对读者了解分布式锁的应用场景、核心原理以及安全性问题具有一定的指导意义。同时,通过对比分析etcd分布式锁和Redis锁的优劣势,为读者提供了全面的技术视角和实践指导。
《etcd 实战课》,新⼈⾸单¥59
全部留言(17)
- 最新
- 精选
- jeffery老师太厉害了👍etcd和redis 分析的太太透彻了!终于明白了etcd和redis 锁的区别了…….专栏快接近尾声了……真有点不舍!
作者回复: 赞jeffery一直坚持不懈的学习,感谢认可,专栏虽即将结束,但学习与探索未知领域从未有终点,后面有什么有趣的案例、新的体会,我也会通过专栏、微信公众号、博客等各种渠道与大家一起分享交流!
2021-03-1022 - 那时刻老师文中提到的思考题,多个client抢同一把锁与多个client各自抢自己的锁。我的想法是多个client抢同一把锁,在client数目多的时候,同一把锁的竞争比较激烈。而多个client各自抢各自的锁,会有锁饥饿问题,比如新的client因其version比较小,更容易获得锁。
作者回复: 赞,我补充一点,多个client通过写同key抢同把锁,主要有惊群效应,同时获取锁性能也低点,毕竟是需要实时写入相关key的,而后者,revision是按时间全局递增的,因此新的client 写入的key revision会比较大,拿锁的顺序可以理解为按时间顺序排队。
2021-03-107 - 石小唐老师好,etcd有像innodb那样能能控制持久化程度的配置(主要指多久fsync一次磁盘)吗?或者说,etcd可能出现持久化失败(写入磁盘缓存,没fsync)吗?如果持久化失败会有哪些影响?
作者回复: 有的,etcd提供了如下两个参数可以控制事务提交的行为。 --backend-batch-interval '' BackendBatchInterval is the maximum time before commit the backend transaction. --backend-batch-limit '0' BackendBatchLimit is the maximum operations before commit the backend transaction. 在etcd v3.4.9中,backend-batch-interval如果你没指定,默认是100ms,对应的异步goroutine将批量、每隔100ms,将boltdb事务进行提交。 backend-batch-limit默认是10000,当堆积的put/del等操作若超过10000个,则会同步触发boltdb事务提交 ,若boltdb事务持久化失败,则会异常退出,重启时会重放最新WAL日志中已提交的日志条目,再次执行。
2021-03-1724 - types你要注意的是,实现分布式锁的方案有多种,比如你可以通过 client 是否成功创建一个固定的 key,来判断此 client 是否获得锁,你也可以通过多个 client 创建 prefix 相同,名称不一样的 key,哪个 key 的 revision 最小,最终就是它获得锁。至于谁优谁劣,我作为思考题的一部分,留给大家一起讨论。 1. 按照文中介绍concurrency包中用的是prefix 2. 如果使用相同的key,我能够想到存在的问题,在释放锁后,会导致获取锁的事务同时发生,事务数量变得很大
作者回复: 嗯,最主要是惊群效应,所有client都会收到相应key被删除消息,都会尝试发起事务,写入key,性能会比较差
2021-03-114 - 江山如画我最近在做的工作中遇到了分布式锁,这篇文章解决了工作中的很多疑惑,忍不住想要分享给同事们,逻辑合理,切中要害,写的太赞了。
作者回复: 感谢分享,最近我在极客时间直播中也分享了更多k8s最佳实践案例, 后面也将整理到专栏中。
2021-09-11 - @%初%@我理解多个客户端写一个key,与多个客户端写多个key,可以理解为非公平锁与公平锁。主要还是要看业务场景处理。
作者回复: 嗯,性能也要考虑下
2021-04-13 - Geek_604077死锁、脑裂、惊群效应是分布式锁的核心问题,你知道它们各自是怎么一回事吗?ZooKeeper 和 etcd 是如何应对这些问题的呢? 死锁:加锁后由于没有添加锁的过期时间或者锁的时间设置过长,服务异常crash或者服务执行后漏执行释放锁操作,导致锁长时间没有释放 脑裂:分布式体系结构中的集中式结构(也称为 Master/Slave 架构),一个Master节点多个Slave节点,所有的请求数据处理必须先经过Master中央服务器,由Master统一进行资源和任务调度,中央服务器根据这些信息,将任务下达给节点服务器,节点服务器执行任务,并将结果反馈给中央服务器。脑裂是在某些特殊条件下,如主备切换,Slave在与Master的网络出现故障的时候,Slave会认为Master已经故障,从而成为新的master,而原来的master也没有卸任,从而导致存在两个Master在对外服务,存在多master会导致共享资源的互斥性遭到破坏,出现资源争抢,数据不一致等问题 惊群效应:指多进程(多线程)在同时阻塞等待同一个事件的时候(休眠状态),如果等待的这个事件发生,那么他就会唤醒等待的所有进程(或者线程),但是最终却只能有一个进程(线程)获得这个时间的“控制权”,对该事件进行处理,而其他进程(线程)获取“控制权”失败,只能重新进入休眠状态,这种现象和性能浪费就叫做惊群效应。(当你往一群鸽子中间扔一块食物,虽然最终只有一个鸽子抢到食物,但所有鸽子都会被惊动来争夺,没有抢到食物的鸽子只好回去继续睡觉, 等待下一块食物到来。这样,每扔一块食物,都会惊动所有的鸽子,即为惊群。) etcd如何避免死锁:利用Lease的活性检测机制,它提供了检测各个客户端存活的能力。你的业务 client 需定期向 etcd 服务发送"特殊心跳"汇报健康状态,若你未正常发送心跳,并超过和 etcd 服务约定的最大存活时间后,就会被 etcd 服务移除此 Lease 和其关联的数据。通过 Lease 机制就优雅地解决了 client 出现 crash 故障、client 与 etcd 集群网络出现隔离等各类故障场景下的死锁问题。一旦超过 Lease TTL,它就能自动被释放,确保了其他 client 在 TTL 过期后能正常申请锁,保障了业务的可用性。 etcd如何避免集群脑裂:在leader选举上采用了过半机制,即得到一半以上的follow才能成为leader,且新leader就任后旧leader必须卸任,所以etcd不存在脑裂问题 etcd如何避免惊群效应:mutex,通过 Watch 机制各自监听 prefix 相同,revision 比自己小的 key,因为只有 revision 比自己小的 key 释放锁,才能有机会,获得锁2022-02-1620
- Geek_604077若你锁设置的 10 秒,如果你的某业务进程抢锁成功后,执行可能会超过 10 秒才成功,在这过程中如何避免锁被自动释放而出现的安全性问题呢? 加锁时,先设置一个过期时间,然后我们开启一个「守护线程」,定时去检测这个锁的失效时间,如果锁快要过期了,操作共享资源还未完成,那么就自动对锁进行「续期」,重新设置过期时间。 幸运的是,已经有一个库把这些工作都封装好了:Redisson。 Redisson 是一个 Java 语言实现的 Redis SDK 客户端,在使用分布式锁时,它就采用了「自动续期」的方案来避免锁过期,这个守护线程我们一般也把它叫做「看门狗」线程。2022-02-162
- Yangetcd实现的分布式所能保证高性能不2021-12-022
- 雄哼哼redis主备切换过程中,备的数据还没追上的时候 应该是禁止写入的,所以redis的set nx是写不进去的2023-04-16归属地:广东