# 阅读数据：租赁阅读

![`smart`](LeaseRead01_aa_001_2022051.png)

------------------------------------------------------------
回想起刚才介绍的ReadIndex Read，发现其中一个步骤（步骤2）是：当读取请求到达当前节点时，当前节点需要向其他节点发起心跳。如果大多数节点返回相应的心跳响应，那么Leader就可以确定它仍然是Leader。这一步需要一定的网络开销，尽管单次心跳的开销很低。Lease Read和Local Read的优化也是基于这一步，是这样做的：

首先，在Raft领导者选举中，我们引入了一个概念，即心跳时间间隔，即领导者心跳之间的时间间隔。要求是心跳时间间隔小于min（选举超时）。也就是说，领导者将每个心跳时间间隔发送一次心跳，我们将此时间点记录为开始。如果大多数追随者给出心跳响应（此时可以确定领导者是否仍然是此节点），由于Raft的选举机制，追随者将在至少选举超时后启动重新选举。因此，即使发生选举，新的领导者也将在选举超时/时钟漂移边界内被选举出来。因此，从开始到选举超时/时钟漂移边界的这段时间内，领导者仍然是此节点，我们称之为租

这样，在租约中，节点不需要发送心跳来确定它仍然是领导节点，从而提高效率。

其次，我们需要注意这里的两点：

1. 每个TiKV服务器的CPU时钟时间必须准确，允许有小的偏差，否则如果每个服务器的时钟频率不同，租约机制会出现问题。在这种情况下，我们也可以使用ReadIndex。

2. TiKV 实际上不是通过心跳来更新租约，而是通过写操作。由于任何写操作都会通过Raft日志，当我们发起写请求时，我们记录当前时间戳开始，然后当相应的请求被应用时，我们就可以续租Leader的租约。

最后，TiKV 目前支持 ReadIndex Read 和 Lease Read 两种操作。