“你还活着吗?” “我没死,只是网卡了!”——来自分布式世界的“生死契约”

简介: Lease机制是分布式系统核心协调技术,通过带时限的授权确保一致性与可靠性,广泛用于领导者选举、状态判定等场景。授权者承诺在Lease有效期内不变更权限,接收方需在到期后重新申请。基于Lease可避免“双主”问题,提升容错能力。ETCD等协调服务内置Lease支持,允许多key绑定同一Lease,降低刷新开销,提升性能。

租约(Lease) 机制是分布式系统中一种至关重要的协调工具,广泛应用于节点状态判定、领导者选举、分布式锁、资源管理等场景。其核心思想是通过一个带有时间限制的授权(Time-bounded Promise) 来确保在不确定环境下的行为一致性和系统可靠性。
Lease机制的运行逻辑主要包括以下要点。
1)Lease的本质:Lease是由授权者(Issuer,例如一个中心协调服务或当前Leader)授予接收方(Holder/Receiver,例如一个工作节点或候选Leader)的一种承诺。该承诺规定接收方在Lease的有效期内拥有特定的权限(如作为Leader的权利、访问某资源的权利)。
2)授权者的责任:一旦授权者发出了一个Lease,只要该Lease尚未过期,授权者就必须严格遵守其承诺。例如,如果授予了一个Leader Lease,那么在它过期前,授权者不能再授予给其他节点相同的Leader Lease。
3)接收方的权利与义务:接收方在Lease有效期内可以行使其被授予的权限。一旦Lease过期,接收方必须主动放弃该权限,并通常需要重新向授权者申请新的Lease才能继续。
4)Lease的失效机制:Lease可通过版本号号(Version)更新、时间周期(Time Period)到期或到达固定时间点(Fixed Timestamp)等方式失效,确保生命周期可控。
image.png

基于 Lease 机制确定节点状态
在分布式系统中确定一个节点是否处于正常工作状态是一个困难的问题,由于可能存在网络分化,节点的状态是无法通过网络通信来确定的。
最直观的办法是在Leader与Follower之间维持一个心跳(Heartbeat)。比如节点Q作为一个中心节点, A、B、C作为副本节点,A作为Leader,B、C作为Follower, 同一时刻只能有一个Leader节点。节点Q通过与 A、B、C的心跳来判断节点状态,从而判断Leader节点是否需要切换,但如果只通过心跳判断,是有问题的。
节点A、B、C周期性地向Q发送心跳信息,假如超过一段时间,节点Q收不到节点A的心跳,除了节点A本身甚至是节点Q的异常外,也有可能是因为节点Q与节点A之间的网络异常导致的(比如网络拥塞导致的“瞬断”)。
假设节点A本身工作正常,节点A与节点B、C之间的网络正常。但此时节点Q认为节点A异常,重新选择节点B作为新的Leader,并通知节点A、B、C新的 Leader是节点B。由于节点Q的通知消息到达节点 A、B、C的顺序无法确定,假如先到达节点B,则在这一时刻,系统中同时存在两个工作中的Leader,一个是节点A、另一个是节点B。假如此时节点A、B 都接收外部请求并与节点C同步数据,会产生严重的数据错误。上述即所谓“双主”问题。
image.png

上面的例子中,如果要保证系统的正确性,依赖于对节点状态认知的全局一致性,即一旦节点Q认为节点A异常,则节点A也必须认为自己异常,从而节点A停止作为Leader,避免出现“双主”的问题。下面讨论利用Lease机制确定节点状态:
1)节点A、B、C周期性地发送心跳报告自身状态,节点 Q收到心跳后发送一个Lease,表示节点Q确认了节点A、B、C的状态,并允许节点在Lease有效期内正常工作。
2)节点Q可以给节点A一个特殊的Lease,表示节点A可以作为Leader工作。一旦节点Q希望切换新的 Leader,则只需等前一个Leader的Lease过期,则可以安全的颁发新的Lease给新的Leader节点,而不会出现“双主”问题。

image.png

Lease的容错
1)Leader节点宕机/网络分区: Lease机制天然容忍这种情况。Leader无法续约,Lease过期后其权限自动失效。系统不可用的最长时间(在等待Lease过期期间)受Lease有效期限制。
2)授权者(中心节点)异常: 若颁发Lease的单点授权者Q宕机,所有节点都无法获取或续约Lease,系统可能整体不可用。解决方案是使用一个高可用的小集群作为Lease的授权者。
3)时钟同步问题:授权者和接收者之间的时钟如果存在较大偏差,可能导致Lease的实际有效期与预期不符。授权者在计算Lease的到期时间时,需要考虑一个安全窗口(Guard Band或Clock Drift Bound)来容纳潜在的时钟误差。
按照工程经验,Lease的时间差一般取1-10s。太短,则太容易回收承诺,抖动频繁。太长,则太不容易回收承诺,可能导致可用性问题。

ETCD Lease机制
直接在应用中完整实现一套可靠的Lease机制相当复杂。幸运的是,像ETCD、ZooKeeper这类成熟的分布式协调服务已经内置了高可用的Lease功能,应用开发者可以直接使用。

image.png

如上图所示,创建了一个10秒的Lease。 如果在创建Lease后不进行任何操作,则该租约将在10秒后自动过期。 将key1和key2绑定到前Lease,以便在Lease到期时ETCD自动清除key1和key2。
如果希望保留Lease,则需要定期调用KeyAlive方法来刷新它。 例如,要检查分布式系统中的某个节点是否处于活动状态,可以在该节点中创建一个Lease,并定期调用该节点中的KeepAlive方法。 如果进程正常,则保留该节点的Lease。 如果节点崩溃,Lease将自动到期。
但是,如果大量的Key需要支持类似的Lease机制,并且必须为每个Key独立刷新Lease,这将给ETCD带来很大的压力。 因此,ETCD允许将多个Key(例如,具有相似过期时间的Key)绑定到同一个Lease,这可以大大减少Lease刷新的开销并提高ETCD性能。

未完待续

很高兴与你相遇!如果你喜欢本文内容,记得关注哦!!!

目录
相关文章
|
存储 智能网卡 API
智能网卡在分布式 SDN 网络的应用与实践 | 龙蜥技术
智能网卡加速原理和以及在浪潮分布式 SDN 网络加速的应用。
|
5月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
440 2
|
5月前
|
存储 缓存 NoSQL
【📕分布式锁通关指南 12】源码剖析redisson如何利用Redis数据结构实现Semaphore和CountDownLatch
本文解析 Redisson 如何通过 Redis 实现分布式信号量(RSemaphore)与倒数闩(RCountDownLatch),利用 Lua 脚本与原子操作保障分布式环境下的同步控制,帮助开发者更好地理解其原理与应用。
395 6
|
6月前
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。
|
10月前
|
数据采集 存储 数据可视化
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
1102 0
分布式爬虫框架Scrapy-Redis实战指南
|
4月前
|
NoSQL Java 调度
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
分布式锁是分布式系统中用于同步多节点访问共享资源的机制,防止并发操作带来的冲突。本文介绍了基于Spring Boot和Redis实现分布式锁的技术方案,涵盖锁的获取与释放、Redis配置、服务调度及多实例运行等内容,通过Docker Compose搭建环境,验证了锁的有效性与互斥特性。
367 0
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
|
4月前
|
缓存 NoSQL 关系型数据库
Redis缓存和分布式锁
Redis 是一种高性能的键值存储系统,广泛用于缓存、消息队列和内存数据库。其典型应用包括缓解关系型数据库压力,通过缓存热点数据提高查询效率,支持高并发访问。此外,Redis 还可用于实现分布式锁,解决分布式系统中的资源竞争问题。文章还探讨了缓存的更新策略、缓存穿透与雪崩的解决方案,以及 Redlock 算法等关键技术。

热门文章

最新文章