tidb 原理与架构101 (PCTA 笔记分享)

最新推荐文章于 2025-05-29 11:55:54 发布

qq_18810345

最新推荐文章于 2025-05-29 11:55:54 发布

阅读量612

点赞数 10

CC 4.0 BY-SA版权

文章标签： tidb 架构笔记

本文链接：https://blog.csdn.net/qq_18810345/article/details/135674598

ptcp-v6 认证题库 - 墨天轮文档 ptca v6 题库

TPCAv6考试题目准确率百分99-tidb认证答案 - 墨天轮文档 ptcp v6 题库

整体架构

TiDB 大体可以分为三个模块TiDB Server, PD Cluster 和 Storage Cluster。

TiDB Server 的功能类似于Mysql中的Server端，用于 处理客户端的连接、解析和优化SQL语句、生成执行计划 等等。除此之外，因为TiDB底层存储是LSM-Tree而不是B+ Tree，所以还需要将关系型数据转换成KV格式。此外还有GC、DDL执行、缓存和热点小表等功能。
PD Cluster 是 TiDB 相比于传统数据库独有的一个模块，这个模块也是 TiDB 作为分布式系统的核心。主要的功能有元数据的存储、TiDB 集群中微服务的注册和调用、分布式事务/全局ID(TSO)的生成和集群的负载均衡。为了实现这些，PD集成了 etcd。
Storage Cluster 是TiDB 的存储模块，为了实现 HTAP(OLAP + OLTP)，这部分又被分成两个存储模块——TiKV(行式存储) 和 TiFlash (列式存储)。
TiKV 为了支持OLTP业务，类似传统数据库引擎会有MVCC多版本并发管理、锁机制、算子下堆、事务隔离、ACID等等功能，底层的存储结构使用的是rocksdb实现的LSM-Tree。
TiFlash 是为了支持OLAP业务，TiFlash的数据是基于TiKV异步复制过来的。

分模块梳理

上面我们对三个模块进行了梳理，下面我们具体剖开每个模块，看看具体的细节

TiDB Server

编译、优化、执行

Protocol Layer 是协议层，用于管理客户端的连接和身份认证

SQL的解析和编译是 Parse 和 Compile 模块处理的，主要的作用是：SQL → AST语法树 → 执行计划(Plan)

Parse 模块会将SQL语句解析成AST语法树，AST语法树是pkg/parser/ast 目录中定义的基于 Node 的一组用于存储SQL语句信息的对象，比如 DMLNode对象中会包含读写字段(FieldList)、表名(TableName)、条件信息(OnCondition)等等。

Compile 模块会将 AST语法树转换成执行计划(SQL Plan)，这部分对应的代码在pkg/planner 目录下，Plan 对象会根据 ast.Node 即AST语法树来生成，并在创建Plan的过程中会进行验证、逻辑优化 和 物理优化，也会创建对应的session上下文。

还有一点需要注意，Compile 模块中提供了将Plan对象转为对应存储类型(StoreType)的执行器(Executor)，在执行器中包含KV结构数据，即Compile 模块会将解析SQL生成的关系型数据转换成对应的KV结构数据。

经过上面的解析和编译，我们来到了执行Executor模块，它更像是一个 TiDB Server 中的调度模块，用于调度 Transaction、KV 和 DistSQL 模块。

每个 Exec 中会包含对应的从Plan计划中传递过来的 session 上下文 (sessionctx)，session中会包含事务管理器(TxnManager)的调用方法，以便在执行过程中管理事务。

事务具体的实现都是封装在 Transaction 模块，对应代码中则是在 pkg/sessiontxn 目录下。

拿到 Executor 后，之后就是具体的执行阶段，针对比较简单的仅 根据主键或者唯一索引的等值查询 都是通过 KV 模块处理的；相对复杂的任务(job)会通过 DistSQL 将其转换成基于单表的子任务(subjob)。

不论是KV还是 DistSQL 最终都会通过调用TiKV Client 来获取引擎层的数据。

Executor模块既然负责了执行的调度，那有关 算子下推 的调度也是在此模块做的。具体的代码在pkg/executor/coprocessor.go

算子下推 指的是将一部分函数计算交给引擎层(TiKV和TiFlash)，以减轻Server层和引擎层在网络IO上的开销，它将本需要Server层处理的工作交给了引擎层，Server层只需要对引擎层的结果进行聚合即可。由此可见，为了支持算子下推，引擎层也需要支持一部分函数执行。
- TiKV可以支持 TopN 和 Limit 的算子下推
- TiFlash可以支持 TableScan、Selection、Hash/Stream Aggregation、TopN、Limit、Project、HashJoin、Windows等算子，支持了几乎所有的SQL函数的下推

online DDL

online DDL 相关模块——start job, workers 和 schema load

online DDL 仅在TiDB v6.2.0之前有效，这之后采取了并发DDL框架，详见 DDL 语句的执行原理及最佳实践

TiDB Server集群中所有实例的start job 模块都可以接收DDL语句，并将其放入 TiKV 中的 job queue
在 TiDB Server 的集群中，只有一个 Leader节点，也可以称为 Owner 节点，只有Owner节点的workers 模块会生效，从TiKV中获取持久化的队列( 物理DDL队列general job queue 和 逻辑DDL队列add index job queue)，执行job，并在直接结束后记录到历史队列 history queue
schema load 是 TiDB 中表结构schema的缓存，主要用于DDL语句的查询

缓存

缓存模块——memBuffer 和 cache table

TiDB Server的缓存主要是存储在 membuffer 模块，会缓存下面三个数据：SQL结果、线程缓、元数据和统计数据，可以通过tidb_mem_quota_query阈值参数限制每条SQL的缓存占用大小，如果超过此阈值，可以通过oom-action参数设置返回ERROR或打印日志等oom动作。

cache table 主要是用于热点小表缓存，此功能主要用于查询频繁、数据量不大、极少修改的场景，因此想使用热点小表的功能需要满足以下几个条件：

表的总数据量不大 (小于64M)
表的读取频繁 (查询频繁、数据量小、极少修改)
不做DDL，热点小表支持DDL操作，进行DDL需要先关闭热点小表缓存

针对极少的写场景，热点小表缓存如何保证一致性？设定 缓存租约 参数 tidb_table_cache_lease ，默认5s。① 租约时间内，读操作直接读缓存，无法进行写操作 ② 租约到期时，缓存中的数据过期，写操作不在堵塞，读写操作都直接请求TiKV ③ 数据更新完毕后后，租约继续开启，回到步骤1

GC

GC机制——GC主要是清理 TiKV 中由 MVCC 产生的历史版本。GC操作是仅由TiDB Server集群中 Leader节点 发起，执行GC前，Server会找到一个safe point，小于safe point 时间的数据将会被请求，默认是safe point是当前减去十分钟，可以通过 GC Left Time 设定，即 GC Left Time 默认是10分钟。
TiDB Server集群每10分钟会进行一次GC操作。首先清除 表或者字段被drop 的数据，其次清除被delete的数据，最后清除这些数据相关的 锁信息。