# Read Data (Continue...)

![left](./student-guide/diagram/03-Lease-Read-01-01.png)

------------------------------------------------------------
Let's review the readIndex Read introduced earlier and find that one of the steps (step 2) is that when the read request reaches the current node, this node needs to initiate a heartbeat to the 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 some 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, and it works like this:

First of all, we introduced a concept in “Raft - Leader elect”, which is the heartbeat time interval (the heartbeat interval sent by the leader), which requires the heartbeat time interval to be less than min (election) timeout). That is, the leader will send a heartbeat at every heartbeat time interval. We record this time point as start. If the majority of followers have given heartbeat response (you can determine whether the leader or this node is the node at this time), Due to Raft's elect mechanism, the follower will initiate a re-election after at least the elect timeout period. Therefore, even if an elect occurs, the new leader will be elect during the election timeout /clock drift bound period. Well, from start to election timeout/clock drift bound, the leader is still the current node during this period. We call this period of time lease, or lease period. Then, 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 like readIndex Read to determine if the current leader is, thus improving efficiency.

Second, here are 2 points we need to pay attention to:
  - 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, the lease mechanism will have problems. If this is the case, we can also use readIndex.
  - TiKV doesn't actually update the lease via heartbeat, but by writing. Since the Raft log is run once for any write operation, we record the current timestamp start when we initiate (initiate) this write request, and then wait until the corresponding request is applied, we can renew the leader's lease.

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