文章目录

• • TiDB Server架构
  • TiDB Server作用
  • TiDB Server的进程
  • • SQL语句的解析和编译
    • SQL读写相关模块
    • 在线DDL相关模块
    • GC机制与相关模块
  • TiDB Server的缓存
  • • 热点小表缓存

TiDB Server架构

Protocol Layer、Parse、Compile负责sql语句的解析编译和优化，然后生成sql语句执行计划交给Executor

Executor、DistSQL和KV负责分批的执行sql的执行计划

Transaction和KV负责和事务相关的

PD Client和TiKV Client负责与PD TiKV之间的交互

schema load、worker、start job实现DDL语句不会阻塞读写

TiDB Server作用

• 处理客户端的连接（由Protocol Layer完成）
• SQL语句的解析和编译（由Parse、Compile完成）
• 关系型数据与KV的转化
• SQL语句的执行
• Online DDL的执行
• 垃圾回收
• 热点小表缓存 V6.0（由cache table实现）

TiDB Server的进程

SQL语句的解析和编译

生成树形结构，称为AST抽象语法树

表结构转化为KV的过程

聚簇表：

SQL读写相关模块

执行计划执行的时候分为两种：

• 比较复杂的SQL：比如范围查询、表连接、相关的嵌套查询等等，为了避免这些复杂的sql和下面的TiKV存取相关进行耦合度太高，抽象出一个接口DistSQL模块，它负责把对于TiKV的请求封装起来，提供一个简单的select方法，因此不管是什么负责的SLQ经过DistSQL都会变成单表的计算任务
• 点查：走KV模块，简单的获取单行数据的请求，例如根据主键或者唯一索引的等值查询等等都是由KV来实现的

在线DDL相关模块

在进行DDL的时候是不会阻塞读写的，在整个集群中会有多个TiDB Server，对于整个TiDB数据库来讲，同一时刻只能有一个TiDB Server进行DDL操作，同一时刻只有一个TiDB Server中的worker可以做操作

用户发送一个DDL语句，首先由start job接收，然后会把它作为一个job放在任务队列中，同一时间只有一个Server在执行，称之为owner，owner中的workers负责从队列中取第一个执行，执行完放在历史队列，然后去取下一个

每一个Server都有一个任期，超出时间段就会重新发起选举，可能会有一个新的owner

schema load用于在当前TiDB Server成为onwer角色之后，会将最新的所有表的信息同步到内部的缓存之中

GC机制与相关模块

定期清理历史版本

会有一个 TiDB Server会被选为GC leader，由它控制整个GC，会计算出一个时间戳safe point，这个时间以前的数据会被回收

TiDB Server的缓存

• TiDB Server缓存的组成

  • SQL结果
  • 线程缓存
  • 元数据，统计信息

• TiDB Server缓存管理

  • tidb_mem_quota_query：控制每条SQL语句能够默认使用的存储量
  • oom-action：如果SQL的内存使用超过上面设置的tidb_mem_quota_query之后，它是中断这条SQL，返回error，还是记录日志等等行为

热点小表缓存

• 表的数据量不大
• 只读表或者修改不频繁的表
• 表的访问很频繁

表的大小不能超过64M

放进去之后为了保证读写一致，设置了一个参数tidb_table_cache_lease，也就是租约，默认5s

在这5s之内用户可以直接读这张表，租约时间内，无法进行写操作

租约到期后，这张小表就过期了，这个时候就可以直接去写TiKV，这个时候从TiKV中读取

数据更新完毕，租约继续开启