etcd 实战课
唐聪
腾讯云资深工程师,etcd 活跃贡献者
28449 人已学习
新⼈⾸单¥59
登录后,你可以任选3讲全文学习
课程目录
已完结/共 28 讲
开篇词 (1讲)
etcd 实战课
15
15
1.0x
00:00/00:00
登录|注册

06 | 租约:如何检测你的客户端存活?

重建Lease可能触发的问题
CheckPointScheduledLeases任务
Leader通知Follower节点淘汰Lease
最小堆的实现方法
淘汰过期Lease的工作
etcd v3版本的优化
影响续期性能的因素
关联key到Lease
创建Lease
Grant、Revoke、LeaseTimeToLive、LeaseKeepAlive API
Lessor模块
Lease的TTL特性
实现活性检测
保证Leader的唯一性
思考题
为什么需要checkpoint机制
如何高效淘汰过期Lease
如何优化Lease续期性能
key如何关联Lease
Lease整体架构
什么是Lease
租约

该思维导图由 AI 生成,仅供参考

你好,我是唐聪。
今天我要跟你分享的主题是租约(Lease)。etcd 的一个典型的应用场景是 Leader 选举,那么 etcd 为什么可以用来实现 Leader 选举?核心特性实现原理又是怎样的?
今天我就和你聊聊 Leader 选举背后技术点之一的 Lease, 解析它的核心原理、性能优化思路,希望通过本节让你对 Lease 如何关联 key、Lease 如何高效续期、淘汰、什么是 checkpoint 机制有深入的理解。同时希望你能基于 Lease 的 TTL 特性,解决实际业务中遇到分布式锁、节点故障自动剔除等各类问题,提高业务服务的可用性。

什么是 Lease

在实际业务场景中,我们常常会遇到类似 Kubernetes 的调度器、控制器组件同一时刻只能存在一个副本对外提供服务的情况。然而单副本部署的组件,是无法保证其高可用性的。
那为了解决单副本的可用性问题,我们就需要多副本部署。同时,为了保证同一时刻只有一个能对外提供服务,我们需要引入 Leader 选举机制。那么 Leader 选举本质是要解决什么问题呢?
首先当然是要保证 Leader 的唯一性,确保集群不出现多个 Leader,才能保证业务逻辑准确性,也就是安全性(Safety)、互斥性。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

etcd是一个分布式键值存储系统,本文介绍了其Lease(租约)的概念及应用。Lease是etcd中用于实现Leader选举等功能的核心特性,通过Lease可以实现活性检测、自动淘汰故障节点等功能。文章首先介绍了Lease的概念和作用,然后详细解析了Lease的整体架构和如何将key与Lease关联。此外,文章还探讨了Lease续期的性能优化,包括TTL设置、Lease数控制以及etcd v3版本对Lease特性的优化。通过本文,读者可以深入了解Lease的原理和应用,以及如何利用Lease解决实际业务中的问题,提高业务服务的可用性。 Lease的淘汰机制经历了从时间复杂度O(N)到O(Log N)的演进,核心是轮询最小堆的Lease是否过期,若过期生成revoke请求,清理Lease和其关联的数据。另外,文章还介绍了Lease的checkpoint机制,用于解决Leader异常情况下TTL自动被续期可能导致Lease永不淘汰的问题。这一机制通过定期同步Lease剩余的TTL信息,尽量确保续期后集群各个节点的Lease剩余TTL一致性。 总的来说,本文通过实际案例深入解读了Lease的创建、关联key、续期、淘汰、checkpoint机制,突出了Lease在etcd中的重要性和应用价值。同时,文章还提出了思考题,引发读者对Lease的更深层次思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《etcd 实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(22)

  • 最新
  • 精选
  • 写点啥呢
    请教老师,对于Lease操作,请求是否必须有Leader接收处理。这种写请求路由是通过client3客户端直接发到leader还是通过可以通过follower转发? 谢谢

    作者回复: 非常好的问题,从原理上我们知道lease是leader在内存中维护过期最小堆的,因此续期操作client是必须要直接发送给leader的,如果follower节点收到了keepalive请求,会转发给leader节点。续期操作不经过raft协议处理同步,而leaseGrant/Revoke请求会经过raft协议同步给各个节点,因此任意节点都可以处理它。

    2021-02-01
    5
    12
  • kaizen
    您好,有个疑问,关于这句话:"一方面不同 key 若 TTL 相同,可复用同一个 Lease, 显著减少了 Lease 数。" 这句话其实不太理解,相同TTL的k-v可以用同一个lease,但lease过期,会删除所有k-v,是不是这里虽然是多个k-v,且TTL相同,但其实他们是有事务关系的,既要么都可用,要么都过期,并不是因为TTL相同而放在一个lease下面呢

    作者回复: 从实际使用场景上来,我认为是TTL几乎相同,为了降低etcd server的压力而把多个kv关联在一个lease上的,比如kubernetes场景中,有大量的event, 如果一个event,一个lease, lease数量是非常多的,lease过期会触发大量写请求,这对etcd server压力非常大,为了解决这个问题对etcd server性能的影响,lease过期淘汰会默认限速每秒1000个。因此kubernetes场景为了优化lease数,会将最近一分钟内产生的event key列表,复用在同一个lease,大大降低了lease数。

    2021-02-01
    7
    10
  • mmm
    老师,您好,我有几个概念理解的不知是否准确: 1、淘汰过期租约的最小堆中保存的时间是租约到期时间的时间戳,对吧 2、checkpoint中说“按 Lease 过期时间构建一个最小堆时,...,并未持久化存储 Lease 剩余 TTL 信息,因此重建的时候就会自动给所有 Lease 自动续期了”,这里Lease过期时间是指Lease的租约时长600s这个概念,而不是上面1中所说的到期时间戳,对吗? 3、checkpoint同步的剩余TTL是指Lease租约的剩余时间,如还剩10秒过期,而不是同步的1中最小堆中保存的到期时间戳,对吗? 4、如果同步的是剩余时间而不是到期时间戳,那这么设计是为了要保证Follower和Leader时钟不一致时也要正确处理租约过期吗?etcd对Leader和Follower的时钟是否有同步的要求,不同步会有什么问题吗?

    作者回复: 感谢你的精彩提问,我分别回答下: 1. 淘汰过期lease最小堆中保存的时间是lease到期时间,比如lease TTL是600秒/10分钟,当前时间是00:00:00, 那么到期时间00:10:00。 2和3. checkpoint最小堆中保存的时间是定时触发lease剩余TTL的同步的间隔时间, 默认是每隔5分钟触发一次同步,如果leader在00:05:00 crash了,也没开启lease剩余TTL同步操作(还剩余5分钟),那么新的leader重建后的租约时长又是10分钟了,如果你开启checkpoint机制,那么同步的就是lease剩余TTL(5分钟)。 4. 我个人认为同步剩余TTL有助于减少时钟不一致的情况下的导致各种问题,etcd和raft里面大量使用的都是逻辑时钟,至于不同步会产生哪些问题,我后续抽空测试验证下我的一些猜测,也欢迎你自己测试下。

    2021-02-01
    3
    9
  • lease 代表 过期的一个 ttl ,多个 key 复用一个 lease 的时候,lease 是不是没有办法保存每个 key 的具体过期时间点是多少,因为每个 key 的创建时间不一样,所以过期时间也不一样。 还有就是当多个 key 复用同一个 lease 的时候, 某个客户端再发送 keepalive 请求的时候,是可以直接修改lease 的剩余 ttl吗? 若能修改的话,不就把关联到该 lease 上所有 key 的 ttl 都修改了?

    作者回复: 第一个问题,一般情况下不要求每个key过期时间完全一致,比如kubernetes的event,就是误差1分钟内的event key,可以复用同一个lease. 第二个问题,keepalive请求就是更新lease在最小堆中的过期时间(now + ttl),可简单理解为关联到此lease上的所有key ttl都延长了。

    2021-02-03
    3
    6
  • Geek_5a8405
    续期操作不通过raft协议同步到follower,那如果读带lease的key是不是得经过leader处理?因为只有leader的lease过期时间是最准确的(虽然会定时checkpoint同步ttl到follower,但是我理解这个不是非常准确到)。

    作者回复: 不需要经过leader处理哈,etcd对过期时间要求没那么严格,不需要精准到毫秒级。如果lease关联的key过期了,leader会立刻发送撤销租约请求给follower,正常etcd负载情况下,这个请求同步到follower延时大概是毫秒级的,高负载、磁盘IO异常等情况下,的确可能出现比较大的延迟。

    2021-02-15
    3
  • Fone
    可以手动执行etcdctl命令让lease续期吗?

    作者回复: 可以的,etcdctl lease keep-alive命令,另外给你个小建议,当遇到不熟悉命令的时候可以输入--help看看相关命令,如下所示,无论是etcd还是其他任何工具,都可以获得一些帮助信息: % etcdctl lease --help NAME: lease - Lease related commands USAGE: etcdctl lease <subcommand> [flags] API VERSION: 3.5 COMMANDS: grant Creates leases keep-alive Keeps leases alive (renew) list List all active leases revoke Revokes leases timetolive Get lease information

    2021-09-06
  • 花晨少年
    如果只是因为旧版本,才会导致重建,而使得lease永远不会过期,而使用checkpoint机制可以解决这个问题。那新版本就没必要用checkpoint机制了吧?

    作者回复: 这个问题没怎么理解哈,leader异常可发生在任何瞬间,你说的新旧版本怎么区分呢

    2021-04-17
  • 田奇
    1.lease 过期以后,删除关联的 key,这个删除动作也只能 leader 触发吗?也就是说 Follower 的 lessor 模块其实不会运行? 2. 我能理解put key 这种写操作有一致性日志复制,但是 del key的这种数据同步,看文中没有描述走 raft 协议,他是直接发送 lease 过期给所有的 Follower,然后Follower自己处理删除数据,那这个删除的key应该也得记录日志吧,不然状态机恢复没法恢复,这块比较模糊疑惑

    作者回复: 1. 是的,由Leader触发过期的Lease淘汰操作,Follower节点的lessor模块的根据从Leader收到的请求,执行相关操作 2. 删除lease关联的key是通过lease revoke操作发起的,它是经过了raft协议的,会记录在WAL中

    2021-03-24
  • mckee
    思考题:etcd lease 最小的 TTL 是多少? 可能为了确保发生leader选举时,lease不会过期,最小ttl应该比选举时间长,看代码 minTTL := time.Duration((3*cfg.ElectionTicks)/2) * heartbeat minTTLSec := int64(math.Ceil(minTTL.Seconds())) 默认的情况下应该是2s,
    2021-02-03
    6
  • lewis
    请教老师,lease的续期操作不会经过raft模块,follower是怎么知道lease的具体的过期时间内的呢? 请求lease的过期时间 timetolive 命令也是由leader执行吗?
    2021-07-30
    2
    2
收起评论
显示
设置
留言
22
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部