# Reading Data: Lease Read

![`smart`](LeaseRead01_aa_002_2022051.png)

------------------------------------------------------------
Recalling the ReadIndex Read introduced just now, it was found that one of the steps (step 2) is that when the read request arrives at the current node, the current node needs to initiate a heartbeat to other nodes. If most nodes return the corresponding heartbeat response, then the Leader can determine that it is still the Leader. This step requires a certain amount of network overhead, although the overhead of a single heartbeat is low. The optimization of Lease Read and Local Read is also based on this step, which is done in this way:

First, in the Raft Leader Election, we introduced a concept, which is the heartbeat time interval, i.e. the interval of time between Leader heartbeats. The requirement is that the heartbeat time interval is less than min(election timeout). That is, the Leader will send a heartbeat every heartbeat time interval, and we record this time point as start. If the majority of followers give a heartbeat response (at this time, it can be determined whether the Leader is still this node), due to the election mechanism of Raft, the followers will initiate a re-election after at least the election timeout. Therefore, even if an election occurs, the new Leader will be elected within the election timeout / clock drift bound. So, within this period from start to election timeout / clock drift bound, the Leader is still this node, which we call the lease. 

In this way, within a lease, the node does not need to send a heartbeat to determine that it is still the Leader node, thus improving efficiency.

Secondly, there are two points here that we need to take note of:

1. The CPU clock time of each TiKV server must be accurate, with a small deviation, otherwise the lease mechanism will have problems if the clock frequencies of each server are different. In this case, we can also use ReadIndex.

2. TiKV does not actually update the lease through heartbeat, but through write operations. Since any write operation will go through a Raft log, when we initiate the write request, we record the current timestamp start, and then when the corresponding request is applied, we can renew the Leader's lease.

Finally, both ReadIndex Read and Lease Read are currently supported in TiKV.