etcd实战课
唐聪
腾讯云资深工程师,etcd活跃贡献者
立即订阅
2043 人已学习
课程目录
已更新 10 讲 / 共 27 讲
0/3登录后,你可以任选3讲全文学习。
开篇词 (1讲)
开篇词|为什么你要学习etcd?
免费
基础篇 (9讲)
01 | etcd的前世今生:为什么Kubernetes使用etcd?
02 | 基础架构:etcd一个读请求是如何执行的?
03 | 基础架构:etcd一个写请求是如何执行的?
04 | Raft协议:etcd如何实现高可用、数据强一致的?
05 | 鉴权:如何保护你的数据安全?
06 | 租约:如何检测你的客户端存活?
07 | MVCC:如何实现多版本并发控制?
08 | Watch:如何高效获取数据变化通知?
09 | 事务:如何安全地实现多key操作?
etcd实战课
15
15
1.0x
00:00/00:00
登录|注册

08 | Watch:如何高效获取数据变化通知?

唐聪 2021-02-05
你好,我是唐聪。
在 Kubernetes 中,各种各样的控制器实现了 Deployment、StatefulSet、Job 等功能强大的 Workload。控制器的核心思想是监听、比较资源实际状态与期望状态是否一致,若不一致则进行协调工作,使其最终一致。
那么当你修改一个 Deployment 的镜像时,Deployment 控制器是如何高效的感知到期望状态发生了变化呢?
要回答这个问题,得从 etcd 的 Watch 特性说起,它是 Kubernetes 控制器的工作基础。今天我和你分享的主题就是 etcd 的核心特性 Watch 机制设计实现,通过分析 Watch 机制的四大核心问题,让你了解一个变化数据是如何从 0 到 1 推送给 client,并给你介绍 Watch 特性从 etcd v2 到 etcd v3 演进、优化过程。
希望通过这节课,你能在实际业务中应用 Watch 特性,快速获取数据变更通知,而不是使用可能导致大量 expensive request 的轮询模式。更进一步,我将帮助你掌握 Watch 过程中,可能会出现的各种异常错误和原因,并知道在业务中如何优雅处理,让你的服务更稳地运行。

Watch 特性初体验

在详细介绍 Watch 特性实现原理之前,我先通过几个简单命令,带你初体验下 Watch 特性。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《etcd实战课》,如需阅读全部文章,
请订阅文章所属专栏
立即订阅
登录 后留言

精选留言(6)

  • 一步
    当某个 key 发生变化的一定要去 key 的 watcher 区间树去查询是否对应的 watcher 吗? 这样会不会有很大的浪费,当一个系统 监听了一些不经常变的 key, 另一些经常变化的 key 没有对应的 watcher ,这样经常变化的key就会一直去查询key 的 watcher 区间树。 难道 key 不能直接知道是否有对应的 watcher 呢? (比如 key 的结构体记录一个 watcher Id 的数组)

    作者回复: 是的,一定会查,这性能开销很低的。正如我文章中所介绍的,有两类watcher, 一类是监听一个key的watcher,这种直接使用map来保存,也就是检查这个key是否有相关watcher,时间复杂度是o(1),另一类是监听整个区间的watcher,查找这个key落在了哪些watcher监听的范围,一般情况下,时间复杂度o(log n), n是你创建的watcher数。而你建议的方案,使用key结构体记录一个watcher id数组,这在key非常多的情况下,内存开销是非常大,假设一个watcher监听了一个非常大的key范围,那么etcd创建此watcher的时候,还需要遍历这个key范围,给key增加相应的watcher id, 不仅内存,cpu开销也是不可忽略的。

    在哪些场景下watcher事件通知性能会非常慢呢?如果你成千上万个watcher,监听同一个key或者范围时,就会导致性能极差。

    2021-02-06
    6
  • 七里
    如何保证WatchableKV 模块启动的syncVictimsLoop是可靠的呢?机器重启了怎么办?

    作者回复: 好问题,整个watch链路的可靠性,不能光靠server,从业务逻辑正确使用watch api到client watch中断重试机制,再到本讲介绍的server推送机制,层层相连才能尽量保证watch事件可靠性。如果机器重启了,这时就依赖client库的重试机制了,client收到每个watch事件时,会记录收到的版本号,连接到新节点后,再次创建watcher时会带上这个版本号,然后就会进入历史数据同步逻辑。

    2021-02-07
    3
  • 写点啥呢
    请问下老师,如果etcd集群某个节点崩溃或者网络问题导致client/server间连接断开,etcd是如何处理watch重新连接?如果是在另外一个节点重连后,etcd如何确定哪些event已经发送来避免event重复发送呢?

    谢谢老师

    作者回复: etcd clientv3 watch库有中断重连、恢复机制,它会记录上次已收到的watch事件版本号,重启到新节点后,创建watcher的时候会带上这个版本,这样就可以尽量避免event重复发送哈,你可以使用etcd 3.4.9版本自己测试体验下。

    2021-02-05
    3
  • 一步
    watcher key的区间树创建过程是怎么样的?
    2021-02-07
  • akai
    老师,什么应用场景需要使用这种key有多个版本value 的机制呢
    2021-02-06
  • 一步
    带 --rev 版本号的监听,不是从需要监听某个 key 的某个指定的版本开始吗? 文章中怎么写的是集群的版本号

    作者回复: 版本号是集群的逻辑时间,参考07,监听key时,你可以指定任意一个时间点,过去、未来的版本号都可以。

    2021-02-05
    1
收起评论
6
返回
顶部