# `Raft` Log Replication

![`smart`](RaftLogReplication01_aa_002_20220511.png)

----------------------------------------------------------------------------
以下に、ログレプリケーションについて説明します。

クライアント（例えばTiDBサーバー）がデータを書き込む必要がある場合、その操作はTiKVでは`Propose`と呼ばれるリーダー役のリージョンに送信されます。

リーダーは操作をエントリーにエンコードし、自身のRaft Logに書き込みます。このプロセスを`Append`と呼びます。

TiKVは複数のリージョンを持ち、リージョンのIDをキーの接頭辞として、Raft Log IDを追加してRaft Logを一意に識別することで、Raft Logのフォーマットを単純に理解できます。
- 例えば、２つのリージョンがあり、それぞれのIDが4と5であるとしたら、Raft Log のフォーマットは以下の通りです：

```
4_1, log { PUT key = 1, name = tom }
4_2, log { PUT key = 2, name = andy }
4_3, log { PUT key = 1, name = jack }
...
4_N, log { DEL key = 3 }
5_1, log { PUT key = 100, name = tim }
5_2, log { PUT key = 100, name = jim }
5_3, log { PUT key = 200, name = tony }
...
5_N, log { PUT key = 100, name = mark }
```

リーダーは、`Replicate`と呼ばれるRaftアルゴリズムを介して、他のフォロワーにもエントリーを複製することになります。

フォロワーがエントリーを受け取った後、`Append`操作も行い、リーダーに成功を伝えます（`Append`はエントリーを自身のRaft Logに書き込むことを指し、適用することではありません）。

リーダーが、このエントリーが多数のノードによって`Append`edされたことを発見したとき、そのエントリーは既にコミットされたものとみなし、それからそのエントリー内の操作をデコードし、データ永続性ストレージエンジンに適用するために実行することができます。これを`Apply`と呼びます。