租约

2024-05-04 22:32
文章标签 租约

本文主要是介绍租约,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

背景和介绍

       缓存 是计算机里广泛使用的一种技术,对降低读取延迟、网络流量和服务器负载都非常有效,但也带来了一致性(Consistency)的问题。所谓一致就是客户端总能读到最新的数据,使用缓存后有可能服务器端的数据已经被修改,但客户端仍然从缓存中读取陈旧的数据。为了保证一致性,有两种常见的解决办法,第一种是轮询(Polling),即每次读取数据时都先询问服务器数据是不是最新的,如果不是就从服务器传输新数据,这种方法需要每次读取数据时都与服务器通信。另一种方法就是回调(Callback)或者无效化(Invalidation),就是由服务器记住有哪些客户端读取了数据,对数据做修改时首先通知所有这些客户端数据已经失效,这种方法的问题在于服务器需要记住所有读取过数据的客户端,这是很大的负担,更严重的是,一旦有客户端联系不上或者丢失了客户端的信息,修改操作就无法继续。
       1989年斯坦福大学的Cary G. Gray和David R. Cheriton提出了利用租约来维护缓存一致性的方法。所谓租约,其实就是一个合同,即服务器给予客户端在一定期限内可以控制修改操作的 权力。如果服务器要修改数据,首先要征求拥有这块数据的租约的客户端的同意,之后才可以修改。客户端从服务器读取数据时往往就同时获取租约,在租约期限 内,如果没有收到服务器的修改请求,就可以保证当前缓存中的内容就是最新的。如果在租约期限内收到了修改数据的请求并且同意了,就需要清空缓存。在租约过 期以后,客户端如果还要从缓存读取数据,就必须重新获取租约,我们称这个操作为“续约”。
在租约期限内,客户端可以保证其缓存中的数据是最新的。同时,租约可以容忍各种非拜占庭式失效(机器崩溃、网络分割等)。如果客户端崩溃或者网络中断,服务器只需要等待其租约过期就可以进行修改操作。如果服务器出错丢失了所有客户端的信息,它只需要知道租约的最长期限,就可以在这个期限之后安全的修改数据。与回调方式相比,服务器只需记住还拥有租约的客户端即可。
       因 为租约是基于时间的,因此其有效性需要系统时间来保证。如果服务器的时钟快而客户端时钟慢,那么有可能服务器认为一个租约已经过期而客户端仍然认为其有 效,就可能导致错误。对这种情况就必须通过时钟同步协议来解决了,不过这种情况很少见。一般情况下,我们可以认为一个分布式系统的时间是同步在一个很小的 时间差e之内,只需把这个e考虑到租约期限内即可。(需要保证服务器和客户端时钟同步)

租约属性和管理

       一般情况下,应当选择较短的租约期限。与长租约相比,短租约有三个优点。首先,在失效情况下修改操作往往需要等待租约过期,因此短租约就意味着更短的失效延迟。其次,就算一个客户端已经不再需要读取数据,但在其租约过期前,任何的修改操作仍然需要征求它的同意,这种情况叫做“假共享”,显然租约期限越长,这个问题就越严重。最后,短租约也使得服务器要维护的客户端信息更少。然而短租约也意味着更大的续约开销, 因此对于要反复读取却很少修改的数据,长租约会更有效。因此,对租约期的选择要权衡失效延迟、假共享开销和续约开销等多个因素,服务器可以根据数据访问特 性和客户端的性质灵活设置期限。事实上,如果我们把租约期限设为零,就相当与轮询,此时修改操作随时可以进行,而读取数据总是要联系服务器。如果把租约期 限设为无限长,就相当于回调。

       除了期限的选择,还有很多管理选项。对客户端来说,可以选择 是否续约、何时续约以及是否同意修改等。比如为了减少读取延迟,客户端可以在租约过期前就续约,不过这样可能加重服务器的负担。对服务器来说,可以选择是 否发放租约、租约覆盖粒度以及对如何进行修改操作。比如在收到修改请求后,服务器可以不征求客户端同意,而是简单的等待所有租约过期(等待时不再发放新租 约以避免无限期的延迟)。对于“安装文件”,也就是修改极少的文件(比如头文件、库文件),服务器可以用一个租约来覆盖一批文件,同时定期广播续约通知来节省开销,如果需要修改数据,就停止广播并等待租约过期即可。


互联网的一致性问题

       在互联网环境下,一致性问题更加复杂,因为网络延迟比局域网要大的多,客户端失效和网络分割都很常见。因此很多情况下,我们都只保证缓存的弱一致性,也就是不保证客户端总能读到最新的数据,只是尽量保证其读到的数据还不是非常滞后。相应的,我们把前面使用的一致性称为强一致性目前最常用的保证弱一致性的方法就是生存期(TTL), 即读取数据的时候会指定生存期,在生存期内客户端直接从缓存中读取数据,之后必须与服务器通信验证缓存有效性或者获取最新数据。很显然,我们可以给变化较 多的数据分配较短的生存期来尽量减少客户端读取过期数据的几率,而给变化较少的数据分配较长的生存期来减少读取延迟和服务器负载。


租约的其他应用

       以上我们只讨论了如何用租约来维护缓存一致性,其实租约的应用范围非常广泛。

       在 Frangipani分布式文件系统中实现了一个分布式的锁,客户端在获取锁之前,首先要获取一个租约,并且必须在租约过期前续约。这个客户端获得的锁都 与这个租约相关联,如果租约过期了,锁服务器就会自动的释放这些锁。这里的租约就是对锁有效性的一个保证,通过维护客户端租约,避免了为每个锁维护期限的 开销。这里的租约就相当于心跳。

       在gfs中,每个文件块都有多个副本分布在多个chunkserver上,在 并行追加时必须有一个全局统一的追加顺序。当然这个顺序可以由master来确定,但是这样会大大增加master的负荷。另一种方法可以由多个 chunkserver通过一致性协议(比如Paxos)来达成一个一致,但这样开销太大。gfs使用了租约机制,就是对每个文件块,由master向一 个chunkserver发放租约,在租约期限内就由它来负责并行追加操作的顺序。chunkserver正常运行时可以一直续约,如果出现了机器失效或 者网络分割的情况,master就在租约过期以后把租约交给另外一个chunkserver。在某些情况下,master也会联系拥有租约的 chunkserver,请它们提前释放租约。

      很多情况下,系统中已经有一个保证一致性的中心服务,如某个单一服务器或者是实现了Paxos协议的一组服务器,但如果所有的功能都需要通过这个中心服务,很容易造成性能瓶颈。为了提高效率和扩展性,可以通过租约把一致性扩展到更多服务上。事实上用租约来维护缓存一致性也是相当于把服务器上的数据一致性扩展到了客户端。


防止多主问题

     在通常的集群系统中,我们采用心跳来检测节点状态。但普通的心跳机制是无协议和承诺约定的,所以它的检测结果可能不可靠。很多监控系统采用心跳检测集群中节点的存活性,这种机制存在误报警的可能。

     普通心跳通常是在规定的时限内定期向检测节点发送存活性报告,若超出一段时间未能收到心跳报告,那么检测节点则判断节点可能失效,并采取一系列措施(报警、通知节点的使用者)。这种机制存在的问题是,检测节点单方面判定节点失效,在某些业务集群系统中可能存在风险。节点自身并未认识自己已被认定失效,还在继续提供正常的服务。若该节点在集群中承担唯一 primary 节点的职责,而检测节点的失效判定发起了重新选择新的主节点,会引发“双主”问题。

     采用 lease 机制的心跳实现,则彻底避免了此类问题。由于网络分割的原因,其实没有任何技术可以可靠的判定节点状态,但采用 lease 机制的状态检测,可以避免出现误判时引入新的问题。




这篇关于租约的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/960226

相关文章

分布式系统理论进阶:选举、多数派和租约

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 选举(election)是分布式系统实践中常见的问题,通过打破节点间的对等关系,选得的leader(或叫master、co

思考(六十八):租约机制在登录与路由中的应用

背景 在游戏登录过程中,涉及分配玩家的服务器资源 同时,这个信息也会用于后续的某些路由 考虑到登录过程的复杂性与一些切实的需求: 重复登录 保持会话与服务资源的亲和性问题新旧会话创建与销毁的并发问题 强行切换服务资源 服务节点失效,维持高可用性进行切换服务节点如,某些硬性规定,接外部 SLB 系统,导致服务节点每次分配不一样 路由缓存一致性 以上各种情况下,路由缓存的正确性问题 本人

HDFS租约机制详解

1、租约机制简介 2、租约状态操作  判断租约释放结果 3.2.2.1、租约释放成功 Lease recovery initiated for /user/hive/warehouse/ufoto_bigdata_src.db/src_api_hour_game_square_log/day_part=20190630/hour_part=03/log_game_square_201906

Eureka客户端续约及服务端过期租约清理源码...

Eureka客户端续约及服务端过期租约清理源码解析 在之前的文章:EurekaClient自动装配及启动流程解析中,我们提到了在构造DiscoveryClient时除了包含注册流程之外,还调度了一个心跳线程: scheduler.schedule(                    new TimedSupervisorTask(

网络协议:DHCP协议工作原理,DHCP分配方式,DHCP租约,Wireshark抓包分析DHCP报文

「作者主页」:士别三日wyx 「作者简介」:CSDN top100、阿里云博客专家、华为云享专家、网络安全领域优质创作者 「专栏简介」:此文章已录入专栏《计算机网络零基础快速入门》 DHCP协议 一、简介二、分配方式1)自动分配2)手工分配3)动态分配 三、工作原理四、抓包分析五、租约 计算机想要 「通信」必须要有一个IP地址,IP协议只是提供了IP,想要使用IP,你得自己

成集云 | 维格表会员/租约/合同到期同步企微提醒 | 解决方案

源系统成集云目标系统 方案介绍 维格表是一种新一代的团队数据协作和项目管理工具,由深圳维格智数科技有限公司研发。它结合了可视化数据库、电子表格、实时网络协同、低代码开发技术四项功能,且支持API与可视化看板,操作简单,能提升中小企业的数字化生产力。在维格表中,用户可以轻松管理项目、任务、客户、销售等数据,实时同步信息,实现团队高效协作。同时,维格表也能打破传统

分布式理论基础(二)选举、多数派和租约

1 选举 1.1 简述 一致性问题(consistency)是独立的节点间如何达成决议的问题,选出大家都认可的leader本质上也是一致性问题,因而如何应对宕机恢复、网络分化等在leader选举中也需要考量。   1.2 Bully算法 Bully算法是最常见的选举算法,其要求每个节点对应一个序号,序号最高的节点为leader。leader宕机后次高序号的节点被重选为leader,过程如