在上一篇文章2.3节primary副本切换中，我们提到了利用Lease机制进行节点状态判断；在这篇文章中，我们围绕Lease机制进行阐述。
1. Lease机制介绍
首先，先认识发音和基本含义，英[li:s]，美[lis]；n. 租约; 租契; 租赁物; 租赁权。
我们首先介绍一种问题背景，并利用Lease机制来进行解决。在上节提到的中心化的分布式系统中，节点的元数据信息需要一个中心化的节点进行维护，该节点容易成为整个系统的瓶颈。为此，设计一种在各节点中缓存（Cache）元数据信息的分布式系统，降低对中心元数据节点的访问，分散压力。同时，系统的正确运行依赖于各个节点cache中的数据与中心节点数据的一致性。而且，系统也需要具有一定的容错性和可用性。
利用Lease机制设计分布式Cache系统，基本原理：中心节点在向各节点发送数据的同时发送一个Lease，Lease具有一个有效时长，一旦超过该时长，Lease失效。假设系统全局时钟一致，在发出Lease后的有效时长内，中心节点保证不对相应的数据进行修改。 节点在收到数据与Lease之后，将数据置于本地Cache，当对应Lease超时，删除相应Cache数据。当中心节点需要修改数据时，先阻塞所有的读请求，并等待之前为该数据发出的Lease超时，然后对数据进行修改。
1.1 Lease机制读取和修改数据流程
基于Lease的分布式Cache系统，当客户端读取元数据时：
if（元数据在本地cache && Lease有效）{
return 本地cache中元数据
}else{
request read 元数据 from 中心节点
if(客户端成功接收中心节点元数据及对应Lease){
将元数据与对应Lease置于本地Cache
return 本地cache中元数据
}else{//失败或者超时
读取失败，重试
}
}当客户端节点修改元数据时：
1. 当前节点向中心节点发起修改元数据请求
2. 中心节点收到修改请求后，阻塞所有的读请求（接收但不返回）
3. 中心节点等待所有与该元数据相关的Lease超时//（约束：Lease有效时长内，中心节点保证不会修改对应数据）
4. 中心节点修改元数据并通知客户端节点修改成功容错关键点：在中心节点发出Lease后，无论客户端是任意情况（宕机，网络分化），中心节点只需等待Lease超时，就可以保证客户端不会再继续cache数据，同时保证修改数据不会破坏cache一致性。
在上述的流程中，系统任存在着一些问题：
1. 在中心节点修改元数据时需要阻塞所有读请求，造成没有读服务。 这样做是为了防止读请求时发出新Lease从而引起不断有新客户端节点持有Lease并缓存数据，形成“活锁”。解决方案：当进入修改流程，中心节点颁发的Lease有效期为已发出Lease剩余最大有效期（最大Lease倒计时）。
2. 修改中心节点元数据需要等待所有Lease超时，操作时延较大。解决方案：中心节点在修改后主动通知所有Lease节点放弃存放在cache中的相应数据，中心节点收到客户端返回的确认放弃消息，则跳过该Lease超时。
Lease机制依赖于有效期，这要求中心节点与客户端的时钟始终是同步的。
2. 基于Lease机制确定节点状态
在上一篇文章《分布式系统之中心副本控制协议（Primary-secondary协议）》中，2.3节提到了利用Lease机制确定节点状态。在这一节我们给出如何利用Lease机制来确定节点状态。首先需要明确的内容是：节点的状态是无法通过网络通信来确定的，因为网络通信存在不可靠的问题（如网络分化）。网络分化问题在primary-secondary协议系统中可能引出“双主”问题。针对该问题，有两种解决方案：
1. 容忍双主问题；实质是弃用中心化协议，改用去中心化协议
2. 利用Lease机制；举例：X为中心节点，X向A、B、C节点发送Lease，节点持有Lease，则认为可以正常提供服务。
节点A、B、C周期性地发送“心跳”报告自身状态，中心节点X收到心跳后发送一个Lease，允许节点在Lease有效期正常工作。中心节点X给primary节点颁发特殊的Lease，一旦中心节点X希望切换新primary，则只需要等待primary的Lease过期，即可颁发新的Lease给新primary节点，从而可以避免双主问题。
与此同时，单个的中心节点X颁发Lease存在风险，一旦中心节点X宕机，则系统停服务；工程实践中，中心节点X将转变为中心集群，节点互为副本，提供Lease颁发服务。
3.Lease有效时长
Lease有效期是一个确定的时间点，中心节点颁发Lease时将当前时间加一个固定时长得出Lease有效期。工程实践中，Lease固定时长一般在10秒级别，该时长可供参考选用。
参考：
- 《分布式系统原理介绍》