背景和介绍
Cheriton提出了利用租约来维护缓存一致性的方法。所谓租约，其实就是一个合同，即服务器给予客户端在一定期限内可以控制修改操作的
权力。如果服务器要修改数据，首先要征求拥有这块数据的租约的客户端的同意，之后才可以修改。客户端从服务器读取数据时往往就同时获取租约，在租约期限 内，如果没有收到服务器的修改请求，就可以保证当前缓存中的内容就是最新的。如果在租约期限内收到了修改数据的请求并且同意了，就需要清空缓存。在租约过 期以后，客户端如果还要从缓存读取数据，就必须重新获取租约，我们称这个操作为“续约”。
因 为租约是基于时间的，因此其有效性需要系统时间来保证。如果服务器的时钟快而客户端时钟慢，那么有可能服务器认为一个租约已经过期而客户端仍然认为其有 效，就可能导致错误。对这种情况就必须通过时钟同步协议来解决了，不过这种情况很少见。一般情况下，我们可以认为一个分布式系统的时间是同步在一个很小的 时间差e之内，只需把这个e考虑到租约期限内即可。（需要保证服务器和客户端时钟同步）
租约属性和管理
一般情况下，应当选择较短的租约期限。与长租约相比，短租约有三个优点。首先，在失效情况下修改操作往往需要等待租约过期，因此短租约就意味着更短的失效延迟。其次，就算一个客户端已经不再需要读取数据，但在其租约过期前，任何的修改操作仍然需要征求它的同意，这种情况叫做“假共享”，显然租约期限越长，这个问题就越严重。最后，短租约也使得服务器要维护的客户端信息更少。然而短租约也意味着更大的续约开销，
因此对于要反复读取却很少修改的数据，长租约会更有效。因此，对租约期的选择要权衡失效延迟、假共享开销和续约开销等多个因素，服务器可以根据数据访问特 性和客户端的性质灵活设置期限。事实上，如果我们把租约期限设为零，就相当与轮询，此时修改操作随时可以进行，而读取数据总是要联系服务器。如果把租约期 限设为无限长，就相当于回调。
除了期限的选择，还有很多管理选项。对客户端来说，可以选择 是否续约、何时续约以及是否同意修改等。比如为了减少读取延迟，客户端可以在租约过期前就续约，不过这样可能加重服务器的负担。对服务器来说，可以选择是 否发放租约、租约覆盖粒度以及对如何进行修改操作。比如在收到修改请求后，服务器可以不征求客户端同意，而是简单的等待所有租约过期（等待时不再发放新租 约以避免无限期的延迟）。对于“安装文件”，也就是修改极少的文件（比如头文件、库文件），服务器可以用一个租约来覆盖一批文件，同时定期广播续约通知来节省开销，如果需要修改数据，就停止广播并等待租约过期即可。
互联网的一致性问题
在互联网环境下，一致性问题更加复杂，因为网络延迟比局域网要大的多，客户端失效和网络分割都很常见。因此很多情况下，我们都只保证缓存的弱一致性，也就是不保证客户端总能读到最新的数据，只是尽量保证其读到的数据还不是非常滞后。相应的，我们把前面使用的一致性称为强一致性。目前最常用的保证弱一致性的方法就是生存期（TTL)，
即读取数据的时候会指定生存期，在生存期内客户端直接从缓存中读取数据，之后必须与服务器通信验证缓存有效性或者获取最新数据。很显然，我们可以给变化较 多的数据分配较短的生存期来尽量减少客户端读取过期数据的几率，而给变化较少的数据分配较长的生存期来减少读取延迟和服务器负载。
租约的其他应用
以上我们只讨论了如何用租约来维护缓存一致性，其实租约的应用范围非常广泛。
在 Frangipani分布式文件系统中实现了一个分布式的锁，客户端在获取锁之前，首先要获取一个租约，并且必须在租约过期前续约。这个客户端获得的锁都 与这个租约相关联，如果租约过期了，锁服务器就会自动的释放这些锁。这里的租约就是对锁有效性的一个保证，通过维护客户端租约，避免了为每个锁维护期限的 开销。这里的租约就相当于心跳。
在gfs中，每个文件块都有多个副本分布在多个chunkserver上，在 并行追加时必须有一个全局统一的追加顺序。当然这个顺序可以由master来确定，但是这样会大大增加master的负荷。另一种方法可以由多个 chunkserver通过一致性协议（比如Paxos）来达成一个一致，但这样开销太大。gfs使用了租约机制，就是对每个文件块，由master向一
个chunkserver发放租约，在租约期限内就由它来负责并行追加操作的顺序。chunkserver正常运行时可以一直续约，如果出现了机器失效或 者网络分割的情况，master就在租约过期以后把租约交给另外一个chunkserver。在某些情况下，master也会联系拥有租约的 chunkserver，请它们提前释放租约。
很多情况下，系统中已经有一个保证一致性的中心服务，如某个单一服务器或者是实现了Paxos协议的一组服务器，但如果所有的功能都需要通过这个中心服务，很容易造成性能瓶颈。为了提高效率和扩展性，可以通过租约把一致性扩展到更多服务上。事实上用租约来维护缓存一致性也是相当于把服务器上的数据一致性扩展到了客户端。
防止多主问题
在通常的集群系统中，我们采用心跳来检测节点状态。但普通的心跳机制是无协议和承诺约定的，所以它的检测结果可能不可靠。很多监控系统采用心跳检测集群中节点的存活性，这种机制存在误报警的可能。
普通心跳通常是在规定的时限内定期向检测节点发送存活性报告，若超出一段时间未能收到心跳报告，那么检测节点则判断节点可能失效，并采取一系列措施（报警、通知节点的使用者）。这种机制存在的问题是，检测节点单方面判定节点失效，在某些业务集群系统中可能存在风险。节点自身并未认识自己已被认定失效，还在继续提供正常的服务。若该节点在集群中承担唯一
primary 节点的职责，而检测节点的失效判定发起了重新选择新的主节点，会引发“双主”问题。
采用 lease 机制的心跳实现，则彻底避免了此类问题。由于网络分割的原因，其实没有任何技术可以可靠的判定节点状态，但采用 lease 机制的状态检测，可以避免出现误判时引入新的问题。