etcd实战课
唐聪
腾讯云资深工程师,etcd活跃贡献者
立即订阅
2369 人已学习
课程目录
已完结 28 讲
0/3登录后,你可以任选3讲全文学习。
开篇词 (1讲)
开篇词|为什么你要学习etcd?
免费
基础篇 (11讲)
01 | etcd的前世今生:为什么Kubernetes使用etcd?
02 | 基础架构:etcd一个读请求是如何执行的?
03 | 基础架构:etcd一个写请求是如何执行的?
04 | Raft协议:etcd如何实现高可用、数据强一致的?
05 | 鉴权:如何保护你的数据安全?
06 | 租约:如何检测你的客户端存活?
07 | MVCC:如何实现多版本并发控制?
08 | Watch:如何高效获取数据变化通知?
09 | 事务:如何安全地实现多key操作?
10 | boltdb:如何持久化存储你的key-value数据?
11 | 压缩:如何回收旧版本数据?
实践篇 (13讲)
12 | 一致性:为什么基于Raft实现的etcd还会出现数据不一致?
13 | db大小:为什么etcd社区建议db大小不超过8G?
14 | 延时:为什么你的etcd请求会出现超时?
15 | 内存:为什么你的etcd内存占用那么高?
16 | 性能及稳定性(上):如何优化及扩展etcd性能?
17 | 性能及稳定性(下):如何优化及扩展etcd性能?
18 | 实战:如何基于Raft从0到1构建一个支持多存储引擎分布式KV服务?
19 | Kubernetes基础应用:创建一个Pod背后etcd发生了什么?
20 | Kubernetes高级应用:如何优化业务场景使etcd能支撑上万节点集群?
21 | 分布式锁:为什么基于etcd实现分布式锁比Redis锁更安全?
22 | 配置及服务发现:解析etcd在API Gateway开源项目中应用
23 | 选型:etcd/ZooKeeper/Consul等我们该如何选择?
24 | 运维:如何构建高可靠的etcd集群运维体系?
特别放送 (1讲)
特别放送 | 成员变更:为什么集群看起来正常,移除节点却会失败呢?
结课测试 (1讲)
结课测试题|这些相关etcd知识你都掌握了吗?
结束语 (1讲)
结束语 | 搞懂etcd,掌握通往分布式存储系统之门的钥匙
etcd实战课
15
15
1.0x
00:00/00:00
登录|注册

21 | 分布式锁:为什么基于etcd实现分布式锁比Redis锁更安全?

唐聪 2021-03-10
你好,我是唐聪。
在软件开发过程中,我们经常会遇到各种场景要求对共享资源进行互斥操作,否则整个系统的数据一致性就会出现问题。典型场景如商品库存操作、Kubernertes 调度器为 Pod 分配运行的 Node。
那要如何实现对共享资源进行互斥操作呢?
锁就是其中一个非常通用的解决方案。在单节点多线程环境,你使用本地的互斥锁就可以完成资源的互斥操作。然而单节点存在单点故障,为了保证服务高可用,你需要多节点部署。在多节点部署的分布式架构中,你就需要使用分布式锁来解决资源互斥操作了。
但是为什么有的业务使用了分布式锁还会出现各种严重超卖事故呢?分布式锁的实现和使用过程需要注意什么?
今天,我就和你聊聊分布式锁背后的故事,我将通过一个茅台超卖的案例,为你介绍基于 Redis 实现的分布锁优缺点,引出分布式锁的核心要素,对比分布式锁的几种业界典型实现方案,深入剖析 etcd 分布式锁的实现。
希望通过这节课,让你了解 etcd 分布式锁的应用场景、核心原理,在业务开发过程中,优雅、合理的使用分布式锁去解决各类资源互斥、并发操作问题。

从茅台超卖案例看分布式锁要素

首先我们从去年一个因 Redis 分布式锁实现问题导致茅台超卖案例说起,在这个网友分享的真实案例中,因茅台的稀缺性,事件最终定级为 P0 级生产事故,后果影响严重。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《etcd实战课》,如需阅读全部文章,
请订阅文章所属专栏
立即订阅
登录 后留言

精选留言(4)

  • jeffery
    老师太厉害了👍etcd和redis 分析的太太透彻了!终于明白了etcd和redis 锁的区别了…….专栏快接近尾声了……真有点不舍!

    作者回复: 赞jeffery一直坚持不懈的学习,感谢认可,专栏虽即将结束,但学习与探索未知领域从未有终点,后面有什么有趣的案例、新的体会,我也会通过专栏、微信公众号、博客等各种渠道与大家一起分享交流!

    2021-03-10
    7
  • 那时刻
    老师文中提到的思考题,多个client抢同一把锁与多个client各自抢自己的锁。我的想法是多个client抢同一把锁,在client数目多的时候,同一把锁的竞争比较激烈。而多个client各自抢各自的锁,会有锁饥饿问题,比如新的client因其version比较小,更容易获得锁。

    作者回复: 赞,我补充一点,多个client通过写同key抢同把锁,主要有惊群效应,同时获取锁性能也低点,毕竟是需要实时写入相关key的,而后者,revision是按时间全局递增的,因此新的client 写入的key revision会比较大,拿锁的顺序可以理解为按时间顺序排队。

    2021-03-10
    3
  • types
    你要注意的是,实现分布式锁的方案有多种,比如你可以通过 client 是否成功创建一个固定的 key,来判断此 client 是否获得锁,你也可以通过多个 client 创建 prefix 相同,名称不一样的 key,哪个 key 的 revision 最小,最终就是它获得锁。至于谁优谁劣,我作为思考题的一部分,留给大家一起讨论。
    1. 按照文中介绍concurrency包中用的是prefix
    2. 如果使用相同的key,我能够想到存在的问题,在释放锁后,会导致获取锁的事务同时发生,事务数量变得很大

    作者回复: 嗯,最主要是惊群效应,所有client都会收到相应key被删除消息,都会尝试发起事务,写入key,性能会比较差

    2021-03-11
    1
  • 石小
    唐老师好,etcd有像innodb那样能能控制持久化程度的配置(主要指多久fsync一次磁盘)吗?或者说,etcd可能出现持久化失败(写入磁盘缓存,没fsync)吗?如果持久化失败会有哪些影响?
    2021-03-17
收起评论
4
返回
顶部