sheng的学习笔记-tidb框架原理

TiDB作为新一代的NewSQL数据库，在数据库领域已经逐渐站稳脚跟，结合了Etcd/MySQL/HDFS/HBase/Spark等技术的突出特点，随着TiDB的大面积推广，会逐渐弱化OLTP/OLAP的界限，并简化目前冗杂的ETL流程，引起新一轮的技术浪潮。一言以蔽之，TiDB，前景可待，未来可期。

TiDB架构图

组件-TiDB Server

TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑并通过 PD Server找到存储计算所需数据的TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址

架构图

protocol layer：协议层，处理客户端的连接
parse和compile：解析和编译sql，parse输出ast语法书给compile，compile做优化，输出执行计划
executor：compile的输出执行计划给executor，执行sql，根据不同类型，调用transaction,kv,DistSQL
DistSQL：对复杂的sql进行封装，比如多表范围查询，join，子查询等，输出是单表的计算任务
Transaction：处理事务
kv：根据主键，或者唯一索引等的点查，走这里
schema load和worker和start job：处理ddl执行
cache table:缓存写少读多数据
gc：垃圾回收，因为支持mvcc，在事务变更后，会将变更前的数据保存，为了防止这样的数据太多，定期清理

流程

关系型数据转成kv

聚簇表

组件-TiKV Server

TiKV Server 负责存储数据，用于存储 OLTP 数据，采用行存储格式，支持事务机制，TiKV 本身是一个分布式的 Key-Value 存储引擎。

存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region

TiKV 的 API 在 KV 键值对层面提供对分布式事务支持，默认提供了 SI (Snapshot Isolation) 的隔离级别。

TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。

TiKV 支持高可用和自动故障转移，所有数据都会自动维护多副本（默认为三副本）。

架构图

主要功能：

数据持久化：TiKV 在内部选择了基于 LSM-Tree 结构的 RocksDB 引擎（是由 Facebook 开源的一个非常优秀的单机 KV 存储引擎）作为数据存储引擎。可以简单的认为 RocksDB 是一个单机的持久化 Key-Value Map。
分布式事务支持：TiKV 的事务采用的是 Google 在 BigTable 中使用的两阶段提交事务模型：Percolator。在每个 TiKV 节点上会单独分配存储锁的空间，称为 CF Lock。
副本的强一致性和高可用性：采用 Multi-Raft 机制实现了多副本的强一致和高可用。TiKV 中存储的 Region 会自动分裂与合并，实现动态扩展，并借助 PD 节点可使 Region 在 TiKV 节点中灵活调度。
MVCC（多版本并发控制）。
Coprocessor（协同处理器）。

将 SQL 中的一部分计算利用协同处理器，下推到 TiKV 节点中完成（即算子下推）。充分利用 TiKV 节点的计算资源实现并行计算，从而减轻 TiDB Server 节点的计算压力。TiKV 节点将初步计算后的数据返回给 TiDB Server 节点，减少了网络带宽的占用

列簇

列簇（Column Family，简称CF）是一种数据存储结构，用于存储具有相同特征的数据列。

组件-列存储TiFlash

用于存储 OLAP 数据，和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列存储格式，主要的功能是为分析型的场景加速。

tikv通过日志传输，将日志传给tiflash，当tikv的主节点挂了，但是tiflash不参与投票

tidb server接到申请，会根据类型自动路由到tikv或者tiflash,也可以手工指定

组件-分布式协调层：PD

PD (Placement Driver) 是整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。

PD 不仅存储集群元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑” 。

此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

PD架构图

PD集群也是主从结构的，有一个leader，另外的节点是follower。集成了ETCD，其Raft协议保证了数据的一致性。

PD中存储了数据的元数据信息，同时提供Region的调度功能。

PD提供全局时钟TSO的功能。

Store：集群中的存储实例，对应TiKV。

Region：数据的存储单元，负责维护存储的数据。包含多个副本，每个副本叫一个Peer。读写操作在主节点（leader节点）进行，相关信息通过Raft协议同步到follower节点。leader和follower之间组成一个group，就是raft group。

PD的主要功能：

整个集群的TiKV的元数据存储
分配全局ID和事务ID
生成全局时间戳TSO
收集集群中TiKV的信息，进行调度
提供label，支持高可用
提供TiDB Dashboard

路由

TiDB Server接收用户的SQL请求，执行器Executor通过TiKV Client与TiKV进行交互，TiKV Client需要先从PD获取到Region的元数据信息。

Region Cache

TiKV Client从PD获取Region的元数据信息，需要与PD进行交互，这会涉及到网络开销、数据传输，为了提高效率，减少数据的网络传输，TiKV Client本地可以将Region的元数据信息缓存起来，供下次使用，这个缓存是Region Cache。

back off

back off：TiKV Client从PD拿到leader信息后到Region进行读取，如果此时原有leader失效，变成follower了，则Region会反馈信息给TiKV Client，让TiKV Client找PD，获取最新的leader，重新去新的leader节点读取数据，这个过程就是back off。back off越多，读取数据的延迟就越高，效率越低。

TSO分配

概念

TSO = physical time logical time

TSO是一个int64的整数；physical time是物理时钟，精确到毫秒；logical time是逻辑时钟，将1号码的物理时钟划分成262144个逻辑时钟。

tso 请求者发送请求到pd client，
pd client同步立刻返回一个对象
异步请求pd leader ，此时不是单个请求，在一段时间内的批量申请统一请求，减少网络代价
tso 请求者虽然没有获取tso，可以进行解析编译等后续动作
tso做完后续动作，调用wait等待tso的值，等到以后继续动作
如果tso没处理完，pd leader已经返回了tso,pd client先把值存在那，等着tso 请求者调用wait函数获取tso值

解决性能瓶颈

PD节点可能会宕机，PD需要将当前已分配的TSO记录存储到磁盘，防止宕机的时候数据丢失。

写磁盘是有磁盘IO的，每次分配一个TSO、写一次磁盘，性能会比较低。PD采用每次分配3秒钟的TSO，在内存缓存中记录了3秒钟的TSO缓存供高并发的TiDB Server排队取用，存储在磁盘的是时间区间，3秒钟写一次磁盘，以提高效率。写磁盘的数据会通过Raft协议同步到其他PD节点。

高可用设计

PD每次缓存3秒的TSO，磁盘3秒钟写一次，磁盘数据通过Raft协议同步到其他节点。

当leader节点宕机，leader节点的缓存会丢失，但磁盘的数据已同步到其他PD节点。其他PD节点因无主而会重新选举leader节点，新leader节点产生后，仅会知道磁盘中存储的数据，原leader中的缓存数据无法恢复。为了保证TSO的单调递增特性，新leader不会再从磁盘中存储的时间窗口内分配TSO，而是新启动一个3秒钟的时间窗口分配TSO。这会导致TSO不严格连续，但能保证TSO单调递增。