# Write Data
__*TiKV Write*__
__*Data writing*__

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

------------------------------------------------------------
After we have the Raft consensus algorithm and the RocksDB foundation, we can introduce how TiKV data is written. The process is as follows:

Let's say we want to write key = 100, value = Jack

1. The client (usually TiDB Server) asks PD about the region where key = 100 is located

2. PD informs the Leader about the region location (TiKV node)

3. The client (usually TiDB Server) sends the write command to the TiKV node where the leader is located

4. After the Leader node accepts the write command, it starts the TiKV write process.
Here, we use two components, one called raftstore pool and the other called apply pool, both of which are mechanisms used to write to the Persistent Storage Engine (RocksDB).
As for storage engines, that is, RocksDB instances, we have two RocksDB instances in a TiKV, one of which is responsible for persisting Raft logs, which we call RocksDB Raft, and the other is responsible for persisting the real key value data, which we call RocksDB KV.
When the leader node receives the write command, the raftstore pool serializes it into a raft log (raft log) and submits it to RocksDB Raft for persistence (append). At the same time, the raftstore pool is also responsible for distributing the log (raft log) to the TiKV node (replicate) where the followers are located. When the majority of followers in the cluster receive this log (raft log), we consider this (raft log) ) is committed.
Next, the apply pool parse the committed raft log (raft log) and applies it to the RocksDB KV.

5. Leader applies key = 100, value = Jack to the KV RocksDB and return the write success to the client.

6. After that, our client's commit succeeds, and other sessions can read this data.

The above is the process of writing data in TiKV.