# Read Data: Lease Read
__*Lease Read*__

![left](./student-guide/diagram/LeaseRead01_aa_001_2022051.png)

------------------------------------------------------------
Let's review the readIndex Read just introduced, and found that one of the steps (step 2) is that when the read request reaches the current node, the node needs to initiate a heartbeat to other nodes. If most nodes return the corresponding heartbeat response (heartbeat response), Then the leader can be sure that he is still a leader. This step requires a certain amount of network overhead, although the cost of a single heartbeat is relatively low. The optimization of Lease Read/Local Read is also based on this step, which is how it works:

First of all, we introduced a concept in "Raft - Leader elect", which is the heartbeat time interval (the leader sends a heartbeat interval), which requires the heartbeat time interval to be less than min (election) timeout). That is, the leader will send a heartbeat every heartbeat time interval. We record this time point as start. If the majority of followers give a heartbeat response (at this time, you can determine if the leader is this node), Due to Raft's elect mechanism, followers will not initiate re-election after at least the elect timeout period, so even if an elect occurs, the new leader will be elect during the election timeout/clock drift bound. Well, from start to election timeout/clock drift bound, the leader is still the node during this time. We call this period a lease, or a lease period. Well, within a lease, the node does not need to issue a heartbeat to determine that it is still the leader node. In this way, we no longer need to send a heartbeat to determine if we are currently a leader like ReadIndex Read, which improves efficiency.

Second, here we have 2 points that we need to be aware of:

1. The CPU clock time of each TiKV server is accurate, and the error should not be too large. If the clock frequency of each server is different, there will be problems with the lease mechanism. If this is the case, we can also use readIndex.

2. TiKV doesn't actually update the lease through heartbeat, but writes. Since the Raft log is sent once for any write operation, we record the current timestamp start when we initiate the write request, and then wait until the corresponding request is applied, so we can renew the lease of the leader.

Finally, IndexRead and Lease Read are currently supported on TiKV.