【TiDB系列文章】TiDB Server 介绍

最新推荐文章于 2025-02-11 22:23:50 发布

学弟Craze

最新推荐文章于 2025-02-11 22:23:50 发布

阅读量710

点赞数 15

分类专栏： TiDB 文章标签： tidb

本文链接：https://blog.youkuaiyun.com/weixin_67032322/article/details/144233617

版权

TiDB 专栏收录该内容

4 篇文章

订阅专栏

引言

TiDB Server是TiDB分布式数据库架构中的SQL层，负责处理客户端的连接、执行SQL语句、事务处理等。本文将深入探讨TiDB Server的技术细节，包括其主要功能、架构设计和关键特性。

TiDB Server 概述

TiDB Server是TiDB数据库的入口，对外提供MySQL协议的兼容接口，使得用户可以用任何MySQL客户端连接到TiDB，执行SQL语句。TiDB Server主要承担以下角色：

SQL解析与执行：解析客户端发送的SQL语句，并生成执行计划。
事务管理：管理和调度事务，确保ACID属性。
查询优化：优化SQL查询，选择最佳执行计划。
连接管理：管理客户端连接，支持会话和权限控制。

TiDB Server 架构组成

1. 协议层（Protocol Layer）

1.1 协议层主要功能介绍

客户端连接管理

TiDB Server的客户端连接管理是数据库服务的第一步，它涉及到客户端的认证、连接的建立和维护。以下是TiDB Server客户端连接管理的具体步骤和例子：

监听端口

TiDB Server监听特定的端口（默认是4000），等待客户端的连接请求。这个端口在TiDB的配置文件中设置。

客户端连接请求

客户端使用MySQL客户端工具（如命令行工具或图形界面工具）连接到TiDB Server。连接请求包括主机地址、端口、用户名、密码等信息。

例子：

mysql --host <tidb_server_host> --port 4000 -u root -p --comments

在这个例子中，客户端尝试使用用户名root连接到运行在<tidb_server_host>主机上、端口为4000的TiDB Server实例。

认证过程

一旦连接建立，TiDB Server会要求客户端提供用户名和密码进行认证。认证过程涉及到验证用户名和密码是否匹配，以及用户是否有权限连接到数据库。

Session Context 建立

认证成功后，TiDB Server会为每个客户端连接创建一个Session Context，用于保存会话级别的系统变量和用户设置。

处理 SQL 命令

客户端可以开始发送SQL命令，TiDB Server会根据这些命令执行相应的数据库操作。

身份认证

身份认证流程

户端发起连接：客户端使用MySQL客户端工具连接到TiDB Server。
用户名和密码验证：在连接建立后，TiDB Server会要求客户端提供用户名和密码进行身份验证。
权限检查：如果用户名和密码验证通过，TiDB Server会检查该用户是否有权限访问请求的数据库。
SSL/TLS证书认证（可选）：如果TiDB Server配置了SSL/TLS证书，客户端和服务器之间可以进行双向认证，确保连接的安全性。

MySQL 协议解析

MySQL协议是用于MySQL客户端与服务器之间通信的一套规则和格式。它主要规定了以下几个方面：

数据包格式：MySQL数据包的结构和编码方式。
命令格式：客户端发送到服务器的命令格式。
响应格式：服务器返回给客户端的响应格式。

1.1 握手认证阶段

MySQL客户端与服务器之间的交互过程主要分为两个阶段：握手认证阶段和命令执行阶段。

1.1 握手包的结构

握手包是服务器发送给客户端的第一个数据包，其结构如下：

协议版本：标识协议版本。
服务器版本：服务器的版本信息。
线程ID：服务器处理请求的线程ID。
服务器权能标志：服务器的能力，如支持的字符集、SSL等。
服务器状态：服务器的当前状态。
认证插件数据：用于认证插件的数据。
填充：用于填充的数据。

例子：

假设客户端连接到服务器，服务器会发送一个握手包给客户端，包含服务器版本、连接ID等信息。

握手包 = 协议版本(1字节) + 服务器版本(N字节) + 线程ID(4字节) + 服务器权能标志(2字节) + 服务器状态(2字节) + 认证插件数据(N字节) + 填充(10字节)

请求分发

解析完请求后，协议层会将请求分发到TiDB Server内部的其他模块进行处理。例如，SQL查询会被发送到解析器（Parser）和编译器（Compiler），而命令如登录、查询缓存等则由协议层直接处理。

响应编码与发送

处理完请求后，协议层负责将结果编码为MySQL协议数据包，并发送回客户端。这包括查询结果、错误信息或其他数据库操作的反馈。

1.2 协议层的重要性

协议层是TiDB Server与外界交互的桥梁，其稳定性和性能直接影响到整个数据库系统的表现。它不仅需要处理大量的并发连接，还要确保协议的兼容性和安全性，以支持广泛的客户端和应用场景。

2. 解析层（Parse）

在TiDB Server中，解析层（Parse）的主要作用是将客户端发送的SQL语句解析成抽象语法树（AST）。这个过程包括词法分析和语法分析两个主要步骤，是SQL语句执行流程中的关键一环。解析层确保了SQL语句的正确性和有效性，为后续的查询优化和执行计划生成打下基础。

2.1 解析层的工作流程

词法分析（Lexical Analysis）

词法分析是解析过程的第一步，它将输入的SQL语句字符串分解成一系列的标记（Tokens）。这些标记是SQL语句中的最小语法单位，例如关键字、标识符、字面量和运算符等。

例子：

SELECT * FROM users WHERE id = 10;

在词法分析阶段，上述 SQL 语句会被分解成一下几个标记：

序号	标记	类型
1	SELECT	关键字
2	*	通配符
3	FROM	关键字
4	users	标识符
5	WHERE	关键字
6	id	标识符
7	=	运算符
8	10	字面量

语法分析（Syntax Analysis）

语法分析是解析过程的第二步，它使用词法分析产生的标记来构建抽象语法树（AST）。AST是一种树状结构，用于表示SQL语句的语法结构。在AST中，每个节点代表一个语法元素，节点之间的连接表示语法元素之间的逻辑关系。

例子：

        SELECT
       /    \
   *       FROM
         /    \
     users   WHERE
                /    \
             id       =
                    /   \
                  10

在这个AST中，每个节点都代表一个语法元素，如SELECT、FROM、WHERE等，而节点之间的连接表示了这些元素之间的逻辑关系。

3. 编译层（Compile）

在TiDB Server中，编译层（Compile）的主要作用是将解析层（Parse）生成的抽象语法树（AST）转换成执行计划（SQL Plan）。这个过程包括验证、逻辑优化和物理优化三个主要步骤。编译层确保了SQL语句的合法性，并优化执行计划以提高查询效率。

3.1 编译层的工作流程

验证

编译层首先验证AST的合法性，包括检查SQL语句中的对象（如表、列）是否存在，以及用户是否具有相应的权限。

逻辑优化

逻辑优化阶段，编译层对SQL语句进行逻辑层面的优化，如：

- 重写规则：应用SQL重写规则，例如将SELECT *重写为具体的列名。
- 表达式简化：简化SQL语句中的表达式。
- 统计信息使用：利用统计信息来决定是否使用索引。

物理优化

物理优化阶段，编译层将逻辑计划转换成物理计划，这个过程包括：

- 选择执行算法：决定使用哪种算法来执行查询，例如决定是使用嵌套循环还是哈希连接。
- 索引选择：选择最佳的索引进行查询。
- 并行执行计划：决定是否可以并行执行某些操作。

执行计划生成

最终，编译层生成执行计划，这个计划详细描述了如何执行SQL语句，包括需要访问的数据表、使用的索引、连接顺序等。

4. 执行层（Executor）

TiDB Server的执行层（Executor）是负责执行由优化器生成的物理执行计划的组件。它将这些计划转换成实际的数据库操作，如读取数据、执行计算和返回结果。执行层是TiDB SQL层的核心，负责将逻辑计划和物理计划转化为具体的数据操作。

4.1 执行层的工作流程

1. 执行计划的接收

执行层接收来自优化器的物理执行计划，这些计划详细描述了如何执行SQL语句，包括需要访问的数据表、使用的索引、连接顺序等。

2. 执行计划的解释

执行层解释执行计划中的各个节点，这些节点定义了需要执行的操作，如表扫描（TableScan）、索引查找（IndexLookUp）、聚合（HashAgg）等。

3. 数据的读取和操作

根据执行计划，执行层开始读取数据，并执行必要的操作。例如，如果计划中包含表扫描，执行层会从TiKV读取相应的数据。

4. 结果的聚合和返回

执行层将操作的结果进行必要的聚合，如排序、聚合计算等，并将最终结果返回给客户端。

4.2 执行层的关键组件

Executors：在TiDB中，Executors是执行层的核心，每个Executor对应执行计划中的一个节点。常见的Executors包括TableScan、IndexLookUp、HashAgg等。
Coprocessor：TiDB通过Coprocessor协议将部分计算下推到TiKV节点，以利用TiKV的计算能力，减轻TiDB服务器的负担。
DAG（Directed Acyclic Graph）：TiDB 4.0引入了DAG执行引擎，它允许更复杂的查询计划，支持MPP（Massively Parallel Processing）查询执行。

5. 事务层（Transaction）

TiDB的事务层负责提供ACID（原子性、一致性、隔离性、持久性）保证，处理所有读和写请求。它由TiDB服务器中的协调器部分和TiKV服务器中的参与者部分组成。以下是事务层的详细说明，结合TiDB官方文档。

5.1 事务层概述

在TiDB中，事务的写入流程如下：

事务启动：在会话中启动事务后，所有的读写操作都会使用一个快照来获取数据，写入的内容会缓冲在事务的内存中。
事务提交：当从客户端接收到commit语句时，使用Percolator协议将这些变更提交到存储系统。

5.2 事务层的接口

TiDB中的Transaction接口定义了常用的事务操作，例如：

Commit：提交当前进行中的事务。
Rollback：撤销事务操作。
LockKeys：尝试在KV存储中锁定键。
SetOption和GetOption：设置和获取事务选项。

5.3 事务的执行

执行语句时，首先会“激活”相关事务。TiDB默认提供快照隔离级别，因此在每个新事务中，首先会获取一个新的全局强一致快照，然后执行语句。

读操作：使用快照提供全局一致的视图，所有读取都会根据这个快照检查数据可见性。
写操作：数据会临时写入事务内存缓冲区，直到触发commit操作。

5.4 两阶段提交（2PC）

在语句执行阶段之后，commit语句会触发当前事务的提交执行。TiDB使用Percolator协议作为分布式事务协议，这是一个两阶段协议：

准备阶段：协调器向所有参与者发送准备请求，参与者执行事务操作并锁定必要的资源。
提交阶段：如果所有参与者都准备成功，协调器向所有参与者发送提交请求，参与者将更改持久化到存储系统中。

5.5 事务层的关键点

MVCC：TiDB使用MVCC机制来处理并发控制和快照读。
TSO：TiDB从PD服务器获取全局唯一的时间戳（TSO），作为事务的唯一标识符。
乐观锁和悲观锁：TiDB支持乐观事务和悲观事务两种模式，TiDB 3.0.8及以后版本，默认采用悲观事务模式。

6. PD Client

PD Client是TiDB Server内部的一个关键组件，它负责与Placement Driver（PD）进行通信。PD是TiDB集群中的中心总控节点，负责集群的调度、全局ID生成、全局时间戳（TSO）生成等。PD Client作为TiDB Server与PD之间的桥梁，承担着获取集群信息、数据定位、Leader选举、负载均衡、故障处理等重要功能，保障了TiDB集群的高可用性、高性能和稳定性。

6.1 PD Client 的关键功能

集群元信息管理：PD Client从PD获取集群的元信息，包括集群的拓扑结构、TiKV节点状态和数据分布等。
在线DDL操作：PD Client参与在线DDL（Data Definition Language）操作，如创建表、添加索引等，这些操作需要PD进行全局的调度和元信息更新。
负载均衡和分区管理：PD Client根据PD的调度策略，对集群进行负载均衡和分区管理，以优化集群的性能。
全局事务管理：PD Client负责向PD请求全局唯一的时间戳（TSO），用于协调分布式事务中的时间顺序，确保事务的ACID特性。
配置更新与同步：PD Client从PD获取集群配置信息，并在TiDB和TiKV之间同步这些配置。
健康检查与故障切换：PD Client参与集群的健康检查和故障切换流程，确保集群的高可用性。

6.2 PD Client 的工作流程

启动和初始化：TiDB Server启动时，PD Client会初始化并建立与PD的连接。
请求TSO：在事务提交时，PD Client向PD请求TSO，以获取全局唯一的时间戳。
获取Region位置：当TiDB Server需要访问数据时，PD Client从PD获取Region的Leader信息，以便直接与TiKV通信。
配置更新：PD Client定期从PD获取最新的集群配置，并应用到TiDB Server。
故障检测和恢复：PD Client参与故障检测和恢复流程，当TiKV节点发生故障时，PD Client会协助进行故障转移。

7. TiKV Client

TiKV Client是TiDB Server内部的一个组件，它负责与TiKV进行通信，处理数据的读写请求。在TiDB架构中，TiKV Client作为TiDB Server与TiKV之间的桥梁，确保数据操作的顺利进行。

7.1 TiKV Client 的工作原理

与TiKV通信：

TiKV Client和TiKV Server的通信主要采用gRPC协议进行传输。gRPC是一个高性能的开源RPC框架，可以实现快速的数据传输和低延迟的数据交互。

请求转发：

当TiDB Server接收到客户端的SQL请求后，它会将这些请求转换为对TiKV的键值操作，然后通过TiKV Client发送给TiKV Server。

处理TiKV响应：

TiKV Client接收TiKV Server的响应，并将这些响应转换回TiDB Server可以理解的格式，最终返回给客户端。

错误处理和重试：

如果TiKV Server返回错误，如NotLeader错误或StaleCommand错误，TiKV Client会根据错误类型进行相应的处理，可能包括更新本地缓存的元信息或重试请求。

8. 在线 DDL 模块

TiDB的在线DDL模块是负责处理数据库模式变更的关键组件。它允许用户在不停止数据库服务的情况下，对数据库结构进行变更，如添加或删除表、添加或删除索引等。这种在线异步模式的DDL变更是TiDB区别于传统数据库的一个重要特性，它提供了不停机变更业务的服务能力

8.1 在线 DDL 模块的工作原理

1. DDL Owner选举

TiDB DDL模块引入了DDL Owner（简称Owner）角色来代理执行所有进入到TiDB集群中的DDL语句。通过etcd的选举功能，从多个TiDB节点中选举出一个节点来担任Owner的宿主节点。当选Owner后，TiDB节点中启动的worker才能处理集群中的DDL任务。

2. 异步变更模式

TiDB DDL模块从设计之初就选择了在线异步变更的模式，这意味着DDL操作不会立即执行，而是被放入一个后台任务队列中，由DDL Owner异步执行。这种设计减少了DDL操作对业务的影响，提供了更高的可用性。

3. 执行流程

逻辑DDL语句：首先被解析并生成对应的物理DDL语句。
物理DDL语句：被DDL Owner节点的worker线程异步执行。
变更操作：包括但不限于添加索引、删除索引、修改表结构等。
状态更新：DDL操作的状态会被记录在TiDB的元数据中，可以通过ADMIN SHOW DDL语句查看。

9. 垃圾回收（GC）

TiDB的GC（垃圾回收）机制是维护数据一致性和优化存储空间的核心功能。由于TiDB采用MVCC（多版本并发控制）机制，旧数据版本与新数据版本共存，GC的主要任务是清理不再需要的旧数据版本，以释放存储空间并维护数据一致性。

9.1 GC 流程

TiDB集群中会有一个TiDB实例被选举为GC leader，由它来控制GC的运行。GC被定期触发，每次GC时，TiDB会计算一个称为safe point的时间戳，然后删除更早的过期数据。GC流程分为以下三个步骤：

Resolve Locks（清理锁）：

- 在这个阶段，TiDB会扫描所有Region中safe point之前的锁，并清理这些锁。这一步确保了不会删除任何可能被当前活跃事务访问的数据。

Delete Ranges（删除区间）：

- 快速删除由于DROP TABLE/DROP INDEX等操作产生的整区间的废弃数据。

Do GC（进行GC清理）：

- 每个TiKV节点扫描该节点上的数据，并对每一个key删除其不再需要的旧版本。

10. 缓存（memBuffer）

TiDB中的缓存模块主要负责存储SQL结果、线程缓冲、元数据和统计数据等。这些缓存数据被存储在TiDB Server的内存中，被称为memBuffer。通过合理配置和管理缓存，可以显著提高TiDB的性能，尤其是在处理大量读请求时。

10.1 缓存模块的关键特性

1. Region Cache

缓存概述：TiDB中的每个KV请求都需要根据Key定位到能处理该Key请求所在的Store地址。TiDB通过维护一个内存Cache来缓存映射信息，避免重复查询PD获取Region信息。
缓存填充：TiDB的Region Cache更新机制类似于Cache Aside Pattern。TiDB进程启动后Cache为空，在通过Key查询Cache时，首先查询Cache，如果Cache Miss，则向PD获取Region信息并回填到Cache中。
缓存清理：信息被填充到缓存后，在以下三种情况需要清理：Region在10分钟内没有任何访问、TiKV提示Region信息发生变更、Region给出的TiKV节点不可达。

2. 缓存表（Cache Table）

使用场景：TiDB v6.0.0版本推出了缓存表功能，主要用于解决小表读热点问题。缓存表适用于数据量不大、只读表或几乎很少修改、表的访问频繁的场景。
缓存一致性：缓存表采用lease机制保证从各个TiDB Server缓存读取跟从TiKV读取数据的一致性。lease代表租约，在对应的lease周期内，尤其是WRITE操作，只在WRITE lease内允许。
参数配置：可以通过tidb_table_cache_lease变量设置缓存表的租约时间，默认为5秒。在这个租约时间内，用户可以从TiDB缓存中读取表数据。

3. Coprocessor Cache

下推计算结果缓存：Coprocessor Cache的配置位于TiDB的tikv-client.copr-cache配置项中。缓存仅存储在TiDB内存中，TiDB重启后缓存会失效。不同TiDB实例之间不共享缓存。
缓存效果检查：可以通过执行EXPLAIN ANALYZE或查看Grafana监控面板来检查Coprocessor的缓存效果。用户可以通过查看读表算子中的缓存命中率来评估缓存的效果。