# Overall Architecture Of TiDB Cluster

+ Composed of multiple components, each module communicates with each other to form a complete `TiDB` system
+ A stateless front-end and a stateful back-end based on Raft algorithm
+ Compatible with `MySQL` 
+ Horizontal scalability at every cluster layer

![`smart`](./student-guide/diagram/TiDBClusterArchitectureDetail_aa_001_20221005.png)

------------------------------------------------------------------------------
TiDB Server: The SQL layer, which exposes the connection endpoint of the MySQL protocol, is responsible for accepting connections from clients, executing SQL parse and optimization, and finally generating a distributed execution plan. The TiDB layer itself is stateless. In practice, multiple TiDB instance can be launched, and a unified access address is provided through load balancing components (such as LVS, HAProxy or F5), and client connections can be evenly distributed across multiple TiDB instance to achieve load balancing. The TiDB Server itself does not store data, but only parses the SQL and forwards the actual data read request to the underlying storage node TiKV (or TiFlash).

PD (Placement Driver) Server: metadata management module for the entire TiDB cluster, which stores the real-time data distribution of each TiKV node and the overall topology of the cluster, provides TiDB Dashboard management interface, and supports distributed transaction Assign transaction IDs. PD not only stores metadata, but also issues data scheduling commands to specific TiKV node based on the data distribution status reported in real time by TiKV node, which can be said to be the "brain" of the entire cluster. In addition, the PD itself is made up of at least 3 node and has high availability capabilities. It is recommended to deploy an odd number of PD node.

Storage node
  - TiKV Server: Responsible for storing data. Externally, TiKV is a distributed key-value storage engine that provides transaction. The basic unit for storing data is a region. Each region is responsible for storing data in a Key Range (left, closed and right open range from StartKey to EndKey), and each TiKV node is responsible for multiple Region. TiKV's API provides native support for distributed transaction at the KV key-value pair level. By default, the isolation level of SI (Snapshot Isolation) is provided, which is the core of TiDB's support for distributed transactions at the SQL level. After the SQL layer of TiDB has finished parse the SQL, the execution plan of the SQL is converted into an actual call to the TiKV API. So, the data is stored in TiKV. In addition, data in TiKV automatically maintains multiple replica (three replica by default), naturally supporting high availability and automatic failover.
  - TiFlash: TiFlash is a special class of storage node. Unlike ordinary TiKV node, data is stored in columnar form within TiFlash, and the main function is to accelerate analytical-type scenario.

The SQL layer can be scaled independently, either by scaling in or scaling out, depending on the load on the TiDB servers.

The storage layer can be scaled independently, either by scaling in or scaling out, depending on the load on the TiKV or TiFlash servers.