TiDB从0到1系列

• TiDB-从0到1-体系结构
• TiDB-从0到1-分布式存储
• TiDB-从0到1-分布式事务

一、TiDB体系结构图

TiDB基础的体系架构中有4大组件

• TiDB Server：用于处理客户端的请求
• PD：体系的大脑，存储元数据信息
• TiKV：存储数据
• TiFlash：用于数据分析（非必要组件）

二、TiDB Server

• 处理客户端的连接
• SQL语句的解析和编译
• 关系型数据结构与KV数据结构的转换
• SQL语句的执行
• DDL语句执行
• 垃圾回收（GC清除历史版本）

基础功能模块

Protocol Layer：主要用于连接协议、身份验证等。
Parse：词法分析、语法分析
Compile：逻辑优化、物理优化
Executor：执行计划
这几部分的整体逻辑还是非常清晰的，基本和传统关系型数据库模型相同。

MVCC版本回收功能模块

GC：垃圾回收、定时清理过期数据上的锁信息和历史版本数据。
后期讲到TiDB分布式事务的时候会详细说明。

在线DDL功能模块

schema load：记录并同步各个节点的元信息
worker：负责读取队列并执行
TiDB中DDL的执行流程是：
客户端提交DDL语句->TiDB Server将DDL发送到TiKV队列中->workers模块读取队列消息并执行
这里有两个细节：

• 1、TiDB会将DDL队列分为三种，非加索引语句、加索引语句、执行过的语句
• 2、并不是每个TiDB Server节点都能执行DDL，只有被设置为owner的节点才行

三、TiKV

• 实现数据持久化
• 保证副本的强一致性和高可用性
• MVCC多版本并发控制
• 提供分布式事务支持
• 实现Coprocessor（算子下推）

其实TiKV底层真正存储数据的是rocksdb。rocksdb是一款高性能的kv数据库，有完善的持久化机制。当然这里不是说TiDB Server将关系型数据转为KV型数据后就直接丢进了rocksdb，其中间过程涉及到transaction，mvcc，raft等多个逻辑结构。

四、PD

• 存储整个集群TiKV的元数据
• 分配全局ID和事务id
• 生成全局时间戳TSO
• 收集集群信息进行调度
• 提供TiDB Dashboard服务

PD就相当于TiDB的大脑，可以理解为存储了整个集群的数据字典（但不是数据结构，而是数据位置），同时还负责生成全局时间戳，该时间戳也直接作用于TiDB的分布式事务。

五、TiFlash

• 异步复制实现最终一致性
• 列式存储提高分析查询效率
• 实现业务隔离
• 支持智能选择

TiFlash不属于TiDB最基础组件，是否需要部署TiFlash完全由业务需求决定。
个人认为TiFlash存在的意义是为了支持“TiDB是一款支持HTAP的数据库”这一概念，说白了，就目前数据库的发展阶段下，任何数据库在精准度、实时性、大数据只能满足其2，所谓的都满足大多也都是通过原生“挂件”来实现，例如Oracle、PG等亦是如此。
说回TiFlash，是TiDB原生的列式存储，其属于TiKV的副本，当有大数据统计计算类的SQL时，TiDB Server会自动判断是否去TiFlash节点进行计算。

彩蛋

TiDB官方简介中说到“TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 NewSQL 数据库。”，不过猜测TiDB多少也借鉴了Mongodb-sharding的模型（MongoDB于2010年8月发布了1.6版本，该版本引入了sharding特性）。