# データを読む：`Readindex Read`

![`smart`](ReadIndexRead01_aa_002_2022051.png)

---------------------------------------------------------------------
TiKVが読み取りに関して最初に確保する必要があるのは、線形一貫性です。例えば、10:00:00 AMに(key = 1,value = Tom)を(key = 1,value = Jack)に変更して提出した場合、10:00:00 AM以降に(key = 1,value = Tom)を読み取ることはできないということです。

ここでは、リーダーからの読み取りの場合を最初に議論しましょう。簡略化されたプロセスを見てみましょう：

key = 1 を読みたいと仮定したら、
1. クライアントは、キーが1の位置がどのリージョンにあるかPDに尋ねました。
2. PDはリージョンのリーダーにノードの位置（TiKVノード）を知らせます。
3. TiDBサーバーは、リーダーが配置されているTiKVノードに読み取りコマンドを送信します。
4. リーダーノードがリードコマンドを受け取った後、RocksDB KVを読み取り、そのデータをクライアントに返します。

現在唯一の課題は、リーダーを確認する（ステップ2）からリーダーを読み取る（ステップ4）までの間、ノードがリーダーの役割を変更せずにリーダーを維持することを確実にすることです。

この問題の解決策として、いわゆるReadIndex Readがあります。具体的なプロセスを見てみましょう。

1. TiKVは読み取りリクエストを受け取ると、現在のログ（Raft Log）シーケンス番号、コミットインデックスとして知られているものを変数ReadIndexに記録します。
2. その後、このノードは他のノードにハートビートを開始します。もしほとんどのノードが対応するハートビート応答を返した場合、リーダーは自分がまだリーダーであることを決定できます。そうでない場合、ノードはもはやリーダーではないと考えられ、TiDBサーバーを再読み込みする必要があります。
3. もし現在のノードがリーダーであることが確認された場合、Raft Log のインデックスであるapply index が ReadIndex を超えるまで、Raft Log の適用を待つことで、安全な一貫した読み取りを提供します。
4. リーダーノードのRocksDBを読み取り、その結果をTiDBサーバーに返します。

ここで、ReadIndex Readを紹介しました。そして、後でフォロワーリード機能もそれを使って実装されていることを説明します。次に、ReadIndex Readの最適化手法であるLease ReadまたはLocal Readを紹介します。