分布式理论(4):Leases 一种解决分布式缓存一致性的高效容错机制(转)
作者:Cary G.Gray and David R. Cheriton 1989
译者:phylips@bmy 2011-5-7
出处:http://duanple.blog.163.com/blog/static/70971767201141111440789/
[
序:所谓租约(leases),其实就是一个合同,即服务端给予客户端在一定期限内可以控制修改操作的权力。如果服务端要修改数据,首先要征求拥有这块数据的租约的客户端的同意,之后才可以修改。客户端从服务端读取数据时往往就同时获取租约,在租约期限内,如果没有收到服务端的修改请求,就可以保证当前缓存中的内容就是最新的。如果在租约期限内收到了修改数据的请求并且同意了,就需要清空缓存。在租约过期以后,客户端如果还要从缓存读取数据,就必须重新获取租约,我们称这个操作为“续约”{!引用自<<租约机制简介>>}。租约是一个很形象的叫法。虽然最初租约是被用于解决分布式文件缓存的一致性,随着时间的推移,该机制逐步被应用于更多的场景下,比如在GFS,Chubby中都可以看到它的应用,当然这也是翻译本文的重要原因,为深入理解GFS,chubby,租约是一个基础。关于整个租约机制的更多介绍及扩展可以通过译考文献1租约机制简介得到更多信息。本文只是提出租约机制的最初的那篇论文的内容。
]
摘要
缓存机制也同时带来了需要保证一致性的开销和复杂性,这在一定程度上降低了所获得的性能优势。而在一个分布式系统中,缓存系统还必须处理由通信和主机失败带来的额外复杂性。
租约机制(Leases)作为一种基于时间的机制,为分布式系统中的缓存数据提供高效的一致性访问。通过使用它,可以确保非拜占庭式的失效只会影响到性能,但是不会破坏正确性,同时通过使用短租约可以将这种影响减少到最低。我们的分析模型及在system V里的文件访问评测结果表明短租约可以提供很好的性能。随着系统规模的增大和处理器性能的提升,租约对于性能的影响就更显著。
1. 导引
缓存引入了一致性问题,即需要保证缓存数据与主版本数据的一致性。一致性在这里是指,缓存除可以带来性能的提升之外,其他行为应该等价于只有一份数据的情况。对于大缓存来说,用于维护一致性的开销是影响缓存性能的主要因素。
在共享存储多处理器结构中,缓存一致性已经被深入地研究;这些研究建立在一个系统总线提供的可靠的同步广播通信方式之上。但是,在分布式系统中,可能会出现局部的失败:一个主机可能crash,消息可能会丢失。现有的针对文件缓存的一致性策略,可以分为两类:其中一些假设广播是可靠的,因此就无法容忍通信失败,另外一些要求每次读操作都需要执行一次一致性检查,因此不可能有好的性能。
在本文中,我们提出了租约这样一种通过物理时钟来处理主机和通信失败的一致性协议。分析模型及在system v里的文件访问评测结果表明短租约可以在容错的前提下为大系统提供近乎最优的性能。同时随着处理器性能与网络延时之间差距的提高及整体失败率的提升,租约的优势会更明显。
下一节我们会描述下租约机制及如何使用它实现缓存一致性。第3节,引出了一个用于确定租约期限的简单的分析模型,同时将它应用于V系统中。第4节,描述了一些租约管理中的优化。第5节,检验下该机制的容错性。第6节,将leases与其他的分布式缓存一致性相关研究成果及有关问题进行了对比。最后的结论总结了关于租约机制的一些可能应用及未来的一些研究方向。
2. 租约与缓存一致性
租约,实际上就是授予它的持有者,在一定的时间期限内在某些方面的权利的契约。放在缓存的上下文中就是:租约授予它的持有者在租约期限内,对于对应数据的写控制权利,要求服务端在写数据前,必须获得它的租约持有者的许可。当一个租约持有者为一个写操作授权,它会同时使它的本地数据副本失效。
使用租约机制的缓存系统在为响应一个读操作而返回数据或者响应一个写操作而修改数据前,需要获取一个针对该数据的租约(除了具有该数据之外)。当数据项从服务端(数据项的主版本存储处)获取后,服务端也会返回一个租约来保证在租约期限内该数据不会被任何客户端修改,除非服务端事先获得租约持有者的授权。如果数据项在租约期限内被再次读到(并且数据仍在缓存中),缓存就可以直接提供对该数据项的访问而无需与服务端通信。租约过期后,对于该数据项的读取首先需要缓存延长针对该数据项的租约,如果在租约过期之后该数据项已经改变,则需要更新缓存。当客户端修改一个数据项时,服务端必须延迟该操作,直到所有的租约持有者已经做出授权或者它的租约已经过期。
在这里为了方便解释,我们只考虑写直达(write-through)缓存;将它扩展到非写直达的情况也很容易。写直达给出了很明确的失败语义:不允许任何客户端已经观察到的写操作的丢失。尽管某些研究指出,针对文件缓存的写直达花费应当尽量避免,通过对热点文件进行特殊处理可以大大降低这种花费,因为它们集中了大部分的write操作。
为了解释使用租约机制的文件缓存如何操作,考虑一个用于文档生成的无硬盘工作站。当工作站首次执行latex时,它会获取一个针对latex的二进制文件的某个期限(比如10秒钟)的租约。5秒后针对该文件的访问就可以直接使用该文件的缓存版本,而不需要与文件服务器通信。当10秒的租约期限到期之后,针对该文件的访问就需要缓存与服务器通信检查文件是否变化。当一个新版本的latex被安装时,对该文件的write操作会被延迟到所有的租约持有者对该write授权之后。如果某些持有该租约的主机不可达,那就需要等到租约过期。
在前面的例子中,相关的读写操作对象并没有限制必须是文件内容。为了能够支持一个重复的open操作,缓存必须持有到文件名称到文件的绑定及权限信息,而且需要一个针对这些信息的租约来使用这些信息执行open操作。类似,这些信息的修改,比如重命名文件,都会导致一个write操作。
短租约(指有效期限很短)有几个优势。一个是它们最小化了由于客户端及服务端失败(以及由于网络分区产生的失败)产生的延时。当服务端无法与客户端通信时,服务端必须将针对某文件的write操作延迟到持有租约的客户端过期为止。当一个服务器从crashing中恢复时,它必须承认它crash之前所签出的租约。如果它能够记住它已经签出的租约的最大期限就很简单了,它只需要让所有的write操作等待这个期限结束即可,因此完全恢复的时间取决于最大的那个租约期限。另外,服务端也可以通过持久性的存储来维护一个更细节性的租约信息,但是这会产生额外的IO开销,除非租约期限远大于恢复时间才有必要这样做。
短租约也能够最小化“伪共享”的发生。就算一个客户端已经不再需要读取数据,但在其租约过期前,任何的修改操作仍然需要征求它的同意,这种情况叫做“伪共享”。尤其是,当一个客户端对一个文件进行write操作,但是该文件的租约被另一个客户端持有,而该客户端此时并没有访问该文件。“伪共享”引入了针对租约持有者的回调开销(进而增加了客户端的请求延时及租约持有者及服务端的负载),而在这种情况下如果没有租约根本就不会有冲突。在极端情况下,如果某客户端在另一个客户端修改文件之前根本不会访问它,那么租约期限应该设为0。{!短租约也意味着更大的续约开销,因此对于要反复读取却很少修改的数据,长租约会更有效。因此,对租约期的选择要权衡失效延迟、假共享开销和续约开销等多个因素,服务器可以根据数据访问特性和客户端的性质灵活设置期限。事实上,如果我们把租约期限设为零,就相当于轮询,此时修改操作随时可以进行,而读取数据总是要联系服务器。如果把租约期限设为无限长,就相当于回调,每次写都需要通知客户端以使其缓存无效。}
最后,短租约降低了服务端的存储需求,因为过期租约的相关记录可以被重复使用。但是,服务器用于追踪已发出的租约需要的存储开销并不是很大。服务端需要记录每个租约持有者的标识符,以及每个租约持有者持有的租约列表;每个租约只需要记录一对指针。假设每个客户端持有大概100个租约,这样每个客户端大概需要1k字节。即使存储是个问题,还可以通过增大记录租约的粒度来降低存储,这样每个客户端只需要存储更少的租约,只是这可能会带来竞争的增加。后面,我们还会说明如果为那些共享的最广泛的文件减少这种开销。
如果对于客户端和服务端,文件经常被访问同时写共享(write-sharing)又相对很少发生,那么长租约就会更有效。这可以在Andrew文件系统项目看到,在该系统的最初原型中使用一个期限为0的租约,而在其修订版中,则使用了一个无穷大的租约。下一节,将会描述一个租约性能模型,并基于V分布式系统的数据参数来看如何确定合适的租约期限。
3. 租约期限的选择
租约期限的选择需要在最小化续约开销与最小化伪共享之间进行权衡。这种权衡最终是为了最小化服务端负载和客户端响应延时。存储空间是一个次要的考虑因素,通常会被忽略。另外,假设失败率很低不会对平均响应时间有明显的影响,尤其是使用短租约时这种影响就更小。最后,我们在这里只考虑按需续约方式而不是周期性的续约或者是在第4节里提到的其他方式。
3.1 一个简单的分析模型
考虑一个由单个服务端组成的系统,各项性能参数如表1所示:
即服务端只有一个文件,针对该文件存在N个客户端,每个客户端的读写操作服从频率为R,W的泊松分布。文件内容会通过S个缓存共享。每个客户端最多有一个对于该文件的租约。
我们假设每个发送者和接收者的消息处理时间均为Mproc,对于所有主机来说都具有相同的消息传输延迟Mprop。因此,一个消息从发送到接受需要的时间为Mprop+2Mproc,这样一个单播的请求和响应就需要花费2Mprop+4Mproc。组播消息只会被发送一次,之后接收端会通过组播机制接受,因此发送一个组播消息及收到n个响应需要2Mprop+(n+3)Mproc。{!组播的开销实际上是这样算出来的,整个过程相当于1->1 1->n。即发送端首先并行发送1个消息给n个接收端,这样发送时的耗费为Mprop+2Mproc,接收端收到之后,再返回响应时,需要Mproc的时间处理,Mprop的时间传输,而发送端此时需要挨个处理n个响应,因此就是nMproc。这样总共就是Mprop+2Mproc+Mproc+Mprop+nMproc,即2Mprop+(n+3)Mproc。}
对于一个期限为Ts的租约,对于该缓存的真正有效期Tc实际上是:
Tc=max(0,Ts-(Mprop+2Mproc)-e)
对于该缓存来说,Tc必须要减去租约传输时间Mprop+2Mproc以及时钟误差e{!比如说服务器发出一个期限为10秒的租约,但是该租约传到缓存处就用了2秒,而缓存处的时钟又比服务端的时钟慢了1秒,那么对于缓存处来说真正有效的时间应该是7秒,因为如果缓存处还认为该租约是10秒的话,那么当服务端已经认为它过期的时候,而缓存处依然认为它是有效的,这时如果有写请求,那么服务端就可以不取得该缓存处的授权,因为它已过期,但是当有请求来到该缓存处时,它却还以为租约有效,就会导致访问已过期的数据,所以这是不行的}。因此,如果系统中存在比较大的传输延迟及时钟偏差,那么服务端必须要提供一个足够大的租约期限Ts,以保证客户端实际有效的租约期限仍是大于0的。
如果一个缓存在一个租约期限内处理了期望的RTc个读操作,再算上引起租约请求的那一次读操作,那么一次租约请求的开销就平摊到了1+RTc个读操作上。那么服务端续约相关的消息处理速率就是:
2NR/(1+RTc)
{!总共N个客户端,每个客户端的读请求率为R,再加上响应,所以如果服务器挨个响应的话就是2NR的速率,但是因为现在有缓存及租约机制,每1+RTc个才需要进行一次续约处理,因此它的压力就变成了2NR/(1+RTc)}
以及一个针对每个读请求的平均延时:
2(Mprop+2Mproc) /(1+RTc)
当收到一个write请求时,服务端就向所有的租约持有者发送一个组播请求,然后处理这些响应。假设writer是其中一个租约持有者,如果write请求本身隐含了对自身持有的缓存的授权,那么还可以再省掉一个授权信息{!即服务端无需再取得writer的授权,因为正是它请求进行write的}。因此就只需要一个多播请求+S-1个授权信息,总共就是S个消息。这样获取授权的时间就是:
Ta=2Mprop+(S+2)Mproc
.{!对照之前的组播花费,只是此时n=S-1}。因此延时最多是Ta,负载最多是NSW。
在文件缓存这个应用环境中,我们通常认为租约期限以秒级来算,消息传输时间(包括Ta)以毫秒计。因此我们并不考虑Ta与Ts很接近的情况。比较特殊的情况,是Ts=0:需要知道的是0租约比短租约要好,因为一个非零的Ts和为零的Tc意味着写操作受罚而读操作却未获利。{!即当Ts很小时,会导致Tc=0,这样租约已经没有意义了,因为缓存虽然存在但一直是无效的,所以读无法获利,相反写操作却还需要继续获得租约持有者的授权,因此反而不如没有租约。}
当租约期限为0,或者不存在共享时,负载和延时就完全取决于续约开销。在S>1且Ts>0时,服务端每单位时间将会接受和发送:
个一致性相关的消息,并且每个读写操增加的平均延迟为:
对于0期限租约,负载是2NR{!写时不需要获取租约授权};如果满足如下条件,那么一个时长大于Ta的租约就能产生更小的负载:
2NR>2NR/(1+Rtc)+NSW
定义租约获利因子为:
阿尔法 = 2R/(SW)
如果 阿尔法>1 并且 Tc>1/R(a-1)
那么前面的条件就能成立。
{!可以看到如下推导过程
2NR>2NR/(1+Rtc)+NSW
2R>2R/(1+Rtc)+SW
2R-SW >2R/(1+Rtc)
1+Rtc > 2R/(2R-SW)
Rtc>2R/(2R-SW)-1
Rtc>SW/(2R-SW)
Tc>SW/(2RR-RSW)
Tc>1/(2RR/SW-R)
Tc>1/(aR-R)
Tc>1/R(a-1)
}
因此只要使用一个足够长的租约就肯定可以降低服务端负载。阿尔法或者R值越大,意味着短租约性能越好。直观上看,阿尔法标示了读写比率与共享引起的额外开销之间的比例{!即阿尔法=(2R/W):S}。
将这些分析扩展到多个文件的情况时,我们发现负载基本上就是多个租约的简单和。缓存可以批量处理它们的续约请求,这样一个单一的请求实际上可能包含了多个租约。R,W要对应到所有相关文件的比率,因此它们的值会更大。读操作所占的比率的增加会增大阿尔法的值,因此效果会更好。通常情况下,缓存应该为它持有的所有租约进行续约操作。
服务端用于解决一致性的负载基本上取决于它所处理的消息数目。如果我们知道了在0租约情况下服务端用于解决一致性的负载比例,那我们就能根据一致性负载来计算整体负载。此外,实际的响应时间除了用于保证一致性的时间外还要加上其他的处理时间。
如果给定适当的参数,上面的那些公式就可以用来预测一个系统的性能。这就是下面一节的内容。
3.2 V系统中的性能预测
我们使用上面的公式来预测租约在V文件缓存机制中的性能,系统性能参数通过测量收集,见表2。
图1给出了使用3.1节中的公式1,得到的用于一致性的服务端相对负载随租约期限的变化曲线。
标为Trace的曲线是通过对缓存和服务进行模拟追踪得到的结果,该曲线与我们的分析模型中S=1的那条曲线十分接近,这也验证了在该情况下的模型的正确性。可以看到,在term值很低的时候,Trace这条曲线很sharper,这种情况是正常的,因为实际的文件访问与我们假定的泊松分布相比,肯定有差异。这种差异表明,短租约的性能甚至比我们预想的还要好。
根据图1,可以看到非零租约的优势基本上只需要使用一定的秒数就可以获得。比如,在S=1时,在10秒钟的时候,一致性开销已经降低0租约时的10%。还需要考虑用于一致性的负载对于整个服务端的整体负载的影响。在0租约期限时,一致性占据了整个服务端开销的30%,因此实际上的获益是27%{!即30%的90%,也就是说之前的10%是指,一致性开销降低为原来的10%,但是一致性开销本身只占总开销的30%,因此实际上是降低了总开销的27%},这样算下来,仅比当租约期限无穷大时多了4.5个百分点。在S=10时,在租约期限为10秒时,整个服务端负载比0租约时降低了20%,比无穷大时多个百分点。可以看到随着租约时间的增长,所能带来的负载降低程度相对变小,同时又会引入长租约的种种缺点。因此一个短租约(比如10秒钟)看起来更划算些,因为它既得到了前面我们所描述的短租约的优点,又一定程度上降低了服务端负载。
图2展示了由于一致性而增加到每个读写操作上的平均延迟与租约期限的变化关系。因为写操作只占了所有操作中的一小部分,因此对共享部分的写操作所带来的延迟对整个平均延迟的影响很小。如图所示,从S=1到S=40,曲线几乎没有变化。同时,租约所带来的大部分好处在10秒钟这个边界上基本上都可以得到了。因为很多程序在文件访问之间都有一定的计算时间,因此对于更长租约期限的响应时间的改进就显得没有必要了。
我们希望这个结论可以应用到类Unix系统上,尽管我们的访问频率的测量结果与已公布的关于Unix的测量结果不同。比如我们的读写比率几乎比它们的结果大了一个数量级。有几个因素导致了这种不同,首先我们这里没有出现中间文件操作,因为它们已经被V文件缓存系统处理,通过一种类似于使用本地磁盘做缓存文件的方式。第二,与很多测量不同,我们的测量结果包含了程序加载及文件信息访问(比如目录查找),这些都会被认为是读操作。最后,读写操作的次数对应于文件因读而打开或因写而关闭的次数,而不是数据块被读写的次数;而目录操作也占了读写操作中的一大块。
考虑到这些因素,所以这个结果基本上与Unix系统还是很接近的。如果按照Unix的语义,读写对应于块级别的操作,这会让读的绝对频率更高,但是读写的比率会有所下降。租约机制在这种系统下的性能依然是类似的,更高的读频率会导致曲线具有一个更sharper的走向,更适用短租约,更高的写频率则会使它对于共享更敏感。
3.3 在未来分布式系统中的应用
未来的分布式系统将会有如下的几个趋势:系统会在更广域的网络上扩展,通信延迟会增加。处理器的速度会继续提升。在一个系统中,将会包含更多数目的主机,无论是客户端还是服务端。
客户端与服务端之间更大的传输延迟意味着租约续约以及失效的时间会变长。图3展示了在网络往返时间变为100ms时的额外延迟,所有其他参数保持之前的值不变。在这种情况下,一个10秒的租约可以将响应降低到10.1%,而一个30秒的租约则可以降低到3.1%。因此,随着传输延迟的显著增加,稍微长些的租约会更合适些,但是一个10-30秒的租约基本上就足够了。
更快的客户端处理器会降低在读写请求间的计算时间,这样在一个租约期间内发生的读写操作数目就会增加。频率越高,就会使得负载曲线压的更低。
客户端服务端数目的增加没有很明显的影响,除非这会增加写共享(write-sharing)的级别,我们期望这种情况不会发生。事实上,根据Multics在过去的12年里测量表明,写共享的级别并没有明显的增加。
4. 租约管理配置
服务端的租约管理允许一些可能可以提高性能的配置。服务端控制它所签出的租约的期限,它也可以自由的选择等待一个租约过期而不是为一个write操作请求授权。客户端可以自由决定何时申请续约,何时放弃续约,以及何时同意一个写操作。这些配置组合起来,就可以在负载与响应时间中间提供不同的权衡。
比如,客户端可以预料到租约的过期以及在对应的文件被访问前进行续约。这样就可以通过减少读操作的延迟而提高响应时间,但是会增加服务端负载。尤其是一个空闲的客户端可能会持续的请求续约,即使它的文件没有被访问,但是由于缓存持续的持有租约这可能会增加由于伪共享导致的竞争。
服务端可以使用下面这些配置来优化已安装文件,已安装文件通常会有大量的共享访问。已安装文件通常是指那些比如命令行程序,头文件,标准库,它们通常都是系统的标配。这些文件被广泛的共享,经常被读但是很少被写。V系统的统计结果显示,它们几乎占据了一半的读操作,但是几乎没有写操作。对于这种已安装文件的处理,通过在它们之上使用很少数量的租约可以达到优化的目的,比如一个目录一个租约,并且周期性的主动向所有客户端发送针对这些已安装文件的续约授权,以减少客户端针对这些租约的续约请求。另外如果某租约对应的文件将要修改时,服务端只要在周期性的组播中去掉这个租约即可。当租约过期时,写操作就可以执行了。通过这种方法,即使文件更新了,服务端也不需要与大量的客户端通信,也不会导致响应的聚集。如果服务端有很高的概率会因某个客户端不可达而等待租约的过期,通过这种优化,也可以减少不必要的延时。这种优化,还能减少服务端需要保存的针对已安装文件的租约持有者的信息数量。最后,它还能降低针对这些已安装文件的读操作在客户端缓存的延时,因为如果文件没有被更改,它们的租约就不会过期。
最后,除了到客户端的传输延迟,服务端还可以根据文件访问特点设置租约期限。尤其是一个存在重度写共享的文件,它的租约期限应该设为0。对于一个较远的客户端,应该延长其租约期限,以补偿因传输延迟及客户端续约导致的额外延迟造成的租约实际有效期限的降低。更一般的说,如果可以监控各种必要的性能参数,那么服务端可以基于分析模型为每个文件和客户端缓存动态选择合适的租约期限。
5. 容错性
如果主机和网络不会遭遇拜占庭式的失效以及时钟失效,那么租约机制就可以保证一致性,尤其是即使存在消息丢失(包括网络分区),客户端或服务端失败(假设写操作可以保证服务端在crash时仍能处于一致状态)。然而可用性并不会因为缓存而降低,因为一个不可达的客户端最多会让其他客户端的写操作产生一个简短的delay。
租约依赖于良好的时钟。尤其是,如果服务端时钟走的太快可能产生错误,因为这可能会在客户端持有的租约还未过期前就允许一个写操作。类似的,如果客户端时钟走的太慢,它就可能会仍然持有一个服务端认为已经过期的租约。与之相反的—一个慢的服务端时钟和快的客户端时钟—都不会引起不一致。但是可能会产生额外的开销,因为客户端可能会提前认定一个租约的过期。这种错误与进程crash或者通信失败相比,比较少见,它们可以通过一个同步协议或者在租约相关信息中包含一个明确的时间戳来快速检测出来。
我们认为分布式系统中,节点的时钟误差通常保证落在一个数值e之内,相对小于租约期限的秒级长度。这种同步时钟,通常还会被其他的文件访问需求所需要,比如Unix的make工具。最低限度的,如果要保证租约机制的正确性,至少需要时钟误差有一个已知的上界,根据它可以再来调整租约期限的长短。
6. 相关研究
略。
7. 结论
租约机制是分布式系统中一种维护缓存一致性的高效容错的方式。在本文中,我们已经分析了它的性能并在一个真实的系统环境下进行了评测,验证了它的容错性,并思考了它在其他的分布式系统中的应用,尤其是未来的大规模高性能系统。
分析模型以租约期限、读写比例、共享度及消息传输时间为参数估计了服务端的一致性负载以及由于一致性引入的缓存请求延时。该模型为基于文件访问特点动态确定租约期限提供了一个基础。
短租约与长租约相比有很多优点,可以降低在客户端crash时导致的写入延时,还可以降低服务端crash时的恢复时间,此外还能减少伪共享。租约机制可以很好的应用于大规模分布式系统。它对于响应时间的改进对于快速处理器和高延迟网络效果更好,在这种情况下,与客户端之间的往返延迟成为一个主要的开销,同时会影响租约期限的选择。处理大规模客户端产生的租约开销可以通过根据文件访问特点对其进行分类来降低。比如对于安装文件—被高度共享和访问,但是很少被写-可以在服务端通过周期性组播来对不同文件目录续约,以及延迟更新来避免显示地使租约失效的开销。
租约机制提供了在非拜占庭失效下的严格的一致性。某些组件的失效只会降低性能,通过短租约可以最小化这种影响。还有一个关键假设,就是时钟有一个合适的精确度,在没有时间同步机制的情况下至少能保证它是在一定范围内浮动。我们认为同步化的物理时钟对于使用这种租约机制的系统还是至关重要的。
对于目前的工作,还有一些不足。首先,我们使用了一个关于文件sharing的简化模型,同时只是重点关注共享度比较低的情况。虽然大部分系统的共享度都比较低,但是也可能还有一些特殊情况。第二,我们的分析模型只是一个近似模型,忽略了很多重要因素比如排队延迟(queueing delays)。最后一点,租约机制在实际系统中的应用经验还十分有限。目前我们正在用它扩展V系统的文件缓存服务,未来通过该服务可以获得更多的数据。我们也计划探索一种自适应机制来改变租约的期限及覆盖文件以取代目前的静态方式。
除了文件一致性,租约机制还有一些其他应用。尤其是,也可以把它应用在大规模共享内存多处理器。当然,效果如何还要看在内存及缓存的开销,以及容错能力。
租约作为一种通信协调及判定机制,它依赖于计时、消息传输测量精度、以及在通信中断后仍能得到结论的能力。我们正在将这种机制应用于其他领域,比如分布式事务管理协议、传输协议。除此之外,我们认为租约将会作为各种分布式系统的基础被应用在更多的地方。
译考文献:
1. http://blog.csdn.net/kevinfankai/archive/2009/03/25/4024937.aspx 租约机制简介
参考文献:
略。
原文地址:http://duanple.blog.163.com/blog/static/70971767201141111440789/
分布式理论(4):Leases 一种解决分布式缓存一致性的高效容错机制(转)的更多相关文章
- 【分布式事务】使用atomikos+jta解决分布式事务问题
一.前言 分布式事务,这个问题困惑了小编很久,在3个月之前,就间断性的研究分布式事务.从MQ方面,数据库事务方面,jta方面.近期终于成功了,使用JTA解决了分布式事务问题.先写一下心得,后面的二级提 ...
- 分布式消息队列RocketMQ--事务消息--解决分布式事务
说到分布式事务,就会谈到那个经典的”账号转账”问题:2个账号,分布处于2个不同的DB,或者说2个不同的子系统里面,A要扣钱,B要加钱,如何保证原子性? 一般的思路都是通过消息中间件来实现“最终一致性” ...
- 搞懂分布式技术19:使用RocketMQ事务消息解决分布式事务
搞懂分布式技术19:使用RocketMQ事务消息解决分布式事务 初步认识RocketMQ的核心模块 rocketmq模块 rocketmq-broker:接受生产者发来的消息并存储(通过调用rocke ...
- 解决分布式事务基本思想Base和CPA理论、最终一致性|刚性事务、柔性事务
在学习解决分布式事务基本思路之前,大家要熟悉一些基本解决分布式事务概念名词比如:CAP与Base理论.柔性事务与刚性事务.理解最终一致性思想,JTA+XA.两阶段与三阶段提交等. 如何保证强一致性呢? ...
- 6种.net分布式缓存解决方式
6种.net分布式缓存解决方式 1. 使用内置ASP.NET Cache (System.Web.Caching) : https://msdn.microsoft.com/en-us/lib ...
- 分布式理论之一:Paxos算法的通俗理解
维基的简介:Paxos算法是莱斯利·兰伯特(Leslie Lamport,就是 LaTeX 中的"La",此人现在在微软研究院)于1990年提出的一种基于消息传递且具有高度容错特性 ...
- 【转】分布式理论-CAP理论
一 CAP理论简述 CAP (Consistency, Availability, Partition Tolerance,) 理论是NoSQL数据库管理系统构建的基础. 强一致性:等同于所 ...
- 分布式理论(三)—— 一致性协议之 2PC
前言 为了使系统尽量能够达到 CAP,于是有了 BASE 协议,而 BASE 协议是在可用性和一致性之间做的取舍和妥协. 人们往往需要在系统的可用性和数据一致性之间反复的权衡.于是呢,就产生我们标题中 ...
- 分布式理论系列(三)ZAB 协议
分布式理论系列(三)ZAB 协议 在学习了 Paxos 后,接下来学习 Paxos 在开源软件 Zookeeper 中的应用. 一.Zookeeper Zookeeper 致力于提供一个高性能.高可用 ...
随机推荐
- HDUOJ----The Number Off of FFF
The Number Off of FFF Time Limit: 2000/1000 MS (Java/Others) Memory Limit: 32768/32768 K (Java/Ot ...
- Hadoop分布式文件系统使用指南
原文地址:http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_user_guide.html 目的 概述 先决条件 Web接口 Shell命令 DFSAdmin命 ...
- 学习WCF笔记之二
一.学习文章http://www.cnblogs.com/iamlilinfeng/archive/2012/09/25/2700049.html 二.步骤 学习WFC,按照大神的文章一步步学习,不过 ...
- Maven + Eclipse + Tomcat - 开启项目调试之旅(转载)
本文的读者需要拥有一些Maven基础知识和实践,如果没有,请直接绕过或者先看一些关于Maven教程,比如Juven翻译的<Maven权威指南>,google一下便知. 开门见山,首先抛出一 ...
- RAC安装重新运行root.sh
rac1执行root.sh成功,rac2执行失败. 在重新执行root.sh前,在rac2上把crs等配置信息删除: # /u01/app//grid/crs/install/rootcrs.pl - ...
- PLSQL_统计信息系列04_统计信息的锁定和删除
20150506 Created By BaoXinjian
- 局域网不同用户同时登录同一个网站,会出现session乱窜的问题
出现这种问题的情景再现: 1.有一部分人访问网站会出现session乱窜的问题. 2.这部分人是在同一个局域网中. 3.不同菜单看到的信息是不同人的,或者同一个菜单翻页时有的时候看到的是自己的数据,有 ...
- 修改oracle数据库的编码为utf-8
1.查看数据库字符集 ? 数据库服务器字符集select * from nls_database_parameters,其来源于props$,是表示数据库的字符集. 客户端字符集环境select * ...
- DevExpress下拉多选框 CheckComboboxEdit、CheckedListBoxControl
CheckComboboxEdit //清空项 checkedComboBoxEdit1.Properties.Items.Clear(); //自定义数组 ...
- 【Unity3D游戏开发】NGUI之DrawCall数量 (四)
看了非常多关于NGUI drawCall的文章.见得比較多的一个观点是:一个 Atlas 相应一个Drawcall. 但事实上NGUI内部有自己的一套对DrawCall的处理规则. 相关的规则有: 1 ...