# Tidb Server Architecture
__*TiDB Server architecture*__

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

------------------------------------------------------------
In the previous course, we learned that TiDB Server is the SQL layer, exposes the connection endpoint of the MySQL protocol to the outside, and is responsible for accepting client connections, executing SQL parse and optimization, and finally generating distributed execution plans. TiDB Server itself is stateless. Multiple TiDB Server instances can be started to provide a uniform access address to the outside world through load balancing components (such as LVS, HAProxy or F5), and client connections can be evenly distributed across multiple TiDB Server instances to achieve load balancing effects. TiDB Server itself does not store data, but only parses SQL and forwards the actual data read request to the underlying storage node TiKV (or TiFlash).

In this course, we will start with the internal thread pool and cache of TiDB Server and introduce the key functions and hierarchy of TiDB Server. Let's first get to know the core thread pool and cache of TiDB Server.

First, let's take a look at each thread pool module according to the function. We will introduce the details later:
1. The modules Protocol Layer, Parse, Compile, and Execute are mainly responsible for parsing and compiling (optimizing) SQL statements. After processing by these modules, an execution plan for SQL statements is generated.
2. The Executor and DistSQL modules are mainly responsible for executing SQL execution plans in batches.
3. The modules Transaction and KV are responsible for transaction-related writes.
4. The modules PD Client and TiKV Client are responsible for interacting with PD and TiKV, and all interactions with TiDB Server are done through them.
5. The module schema load, worker and start job collaborate to complete the execution of online DDL.

Second, there is a cache area in TiDB Server that is used to cache read result sets, metadata, and login authentication information, etc., which we call MemBuffer. Hotspot subtable cache has been introduced in TiDB Database 6.0 to improve access performance, improve throughput, and reduce access latency

Finally, we will explain the role of the thread pool module and cache mentioned above in this lesson, and their collaboration will be introduced in the SQL statement execution course.