# Tikv server

+ Persistence of data
+ Distributed transaction support
+ Strong consistency and high availability of replicas
+ MVCC (multi-version concurrency control)
+ Coprocessor (operator push down)


![right](./student-guide/diagram/01-TiKV-01-01.png)
------------------------------------------------------------
- Persistent data
  - TiKV chose the RocksDB engine based on the LSM-tree data structure as the persistent storage engine for the data, and the RocksDB engine ensures that data is not lost, that is, persisted through mechanisms such as WAL.

- Distributed transaction support
  - During the 2-phase commit process of the TiDB database based on the Percolator transaction model, the storage lock space is allocated separately on each TiKV, called CF Lock (column cluster), so that the decentralization 2-phase commit is realized in conjunction with the global TSO scheduling of the TiDB Server and PD.
  - In addition, the TiDB database also supports two lock modes: optimistic lock and pessimistic lock, and after TiDB 5.0 version, the asynchronous commit function of the second stage of the two-stage commit is realized. For the common high-concurrency small SQL write scenarios in OLTP scenarios, the write latency is greatly reduced, and the transaction model chapter will be introduced later.

- Strong consistency and high availability for multiple replicas
  - TiKV clusters use the Multi-Raft mechanism to achieve strong consistency and high availability of multiple replicas. Meanwhile, regions stored in TiKV are automatically split and merged to achieve dynamic scale. Finally, regions in TiKV can be flexibly scheduled with PD nodes, avoiding common problems of distributed databases such as hotspots .

- MVCC (multi-version concurrency control)
  - MVCC (Multi-Version Concurrency Control) is essential for high concurrent database reads and writes requirements. It is the basis for implement functions such as concurrency control, SI isolation level, distributed transaction, and fast data recover. The MVCC implement of TiKV is done by adding a version number after the Key, and the historical version data is cleaned up by garbage collection (GC) by TiDB Server after a certain time period.

- Coprocessor (operator push down)
  - The coprocessor function enables TiKV to complete data filtering, partial aggregation, etc. at the local node, so that SQL calculations can be pushed down to distributed storage nodes. This mechanism not only reduces network interaction costs, TiDB server computing resources (CPU, cache, and memory), but also makes full use of the distributed storage node's The ability to process in parallel.