# データの読み取り：Lease Read

![`smart`](LeaseRead01_aa_002_2022051.png)

------------------------------------------------------------
ReadIndex Readが先ほど紹介されたように、ステップ2の1つが、リードリクエストが現在のノードに到着したとき、現在のノードは他のノードにハートビートを開始する必要があることが判明しました。ほとんどのノードが対応するハートビート応答を返すと、リーダーはまだリーダーであると判断できます。このステップには一定の量のネットワークオーバーヘッドが必要ですが、単一のハートビートのオーバーヘッドは低いです。Lease ReadとLocal Readの最適化もこのステップに基づいて行われます。このように行われます。

最初に、Raft Leader選挙で、ハートビートタイムインターバルという概念を導入しました。つまり、Leaderのハートビート間の間隔です。要件は、ハートビートタイムインターバルがmin（選挙タイムアウト）より小さいことです。つまり、Leaderはハートビートタイムインターバルごとにハートビートを送信し、この時点を開始として記録します。Followersの多数がハートビート応答をした場合（この時点で、Leaderがまだこのノードであるかを決定できます）、Raftの選挙メカニズムにより、Followersは少なくとも選挙タイムアウト後に再選挙を開始します。したがって、選挙が発生しても、新しいLeaderは選挙タイムアウト/クロックドリフトバウンド内で選出されます。そのため、開始から選挙タイムアウト/クロックドリフトバウンドまでの期間中、Leaderはまだこのノードであるということを、我々はリースと呼びます。

このように、リース内では、ノードがリーダーノードであることを確認するためにハートビートを送信する必要がなくなり、効率が向上します。

2番目に、ここで注意する2つのポイントがあります：

1. TiKVサーバーそれぞれのCPUクロック時間は、小さな偏差を含めて正確でなければなりません。そうでないと、各サーバーのクロック周波数が異なる場合、リース機構に問題が発生します。この場合、ReadIndexも使用できます。

2. TiKVは実際にハートビートを介してリースを更新しませんが、書き込み操作を介して行います。書き込み操作はRaftログを介して行われるため、書き込みリクエストを開始するときに現在のタイムスタンプを記録し、その対応するリクエストが適用されたときにリーダーのリースを更新することができます。

最後に、TiKVでは、ReadIndex ReadとLease Readの両方が現在サポートされています。