TiDB整体体系架构

水平扩容&缩容
金融机高可用
实时HTAP
云原生的分布式数据库
兼容MySQL 5.7 协议

前端（TiDB Server集群）Stateless
后端（TiKV集群、PD集群）Stateful（Raft）

TiDB Server

TiDB Server主要功能

处理客户端的连接
SQL语句的解析和编译
关系型数据与KV的转化
- region大小：96M～144M
SQL语句的执行
执行online DDL
- 不阻塞线上业务
垃圾回收 GC
热点小表缓存V6.0
- Cache table

TiDB Server架构

无状态，可横向扩展
利用LVS、HAProxy、F5提供统一接入地址，负载均衡
不存储数据，所有数据存在TiKV上
组件作用
- Protocol Layer| Parse | Compile：生成SQL语句的执行计划
- Executor|DistSQL|KV：执行计划的执行
- Transaction|KV：事务
- PD Client：与PD交互
- TiKV Client：与TiKV交互
- Schema load|worker|start job：处理online DDL
- memBuffer：缓存元数据、登录信息等
- cache table：小表缓存

SQL语句的解析和编译

解析

编译

AST：Abstract Syntax Tree，抽象语法树

Key-Value转化

Key的形式：tablePrefix{TableID}_recordPrefixSep
如果声明的主键不是INTEGER数据类型，TiDB会为表创建非聚簇索引
- _tidb_rowid：非聚簇索引的键
如果没有声明主键，TiDB会为表创建一个隐式主键
- _tidb_rowid：隐式键值
主键聚簇索引（Clustered）：表的主键即为聚簇索引，存储一行至少需要一个键值对
主键非聚簇索引（Non-clustered）：行数据的键由隐式分配的_tidb_rowid构成，主键在_tidb_rowid上额外再建立索引，存储一行至少需要2个键值对

Region

SQL读写相关模块

复杂SQL走DistSQL，KV处理简单的请求（如点查）

在线DDL相关模块

DDL不会阻塞
同一时刻只能有一个TiDB Server可以做DDL操作
start job把任务放到job queue中，workers角色是owner时，才会去执行job，执行完放到history queue ，owner有任期，任期结束重新选举
schema load在当workers成为owner后，缓存所有表的元数据，用于执行任务

GC机制与相关模块

safe_point
GC_life_time：数据的存活时间，默认10min

TiDB Server的缓存

缓存组成
- SQL结果
- 线程缓存
- 元数据，统计信息，用户信息
缓存管理
- tidb_mem_quota_query：控制每条SQL占用缓存的大小
- oom-action：决定内存超过阀值后的操作

热点小表缓存

表的数据量不大：64M以下
只读表或者修改不频繁的表
表的访问很频繁

原理

tidb_table_cache_lease：缓存租约，单位秒，默认5
租约时间内，无法进行写操作

租约到期，数据过期
写操作不再被阻塞
读写直接到TiKV节点上执行

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

应用

缓存表限制大小为64MB
适用于查询频繁、数据量不大、极少修改的场景
在租约（tidb_table_cache_lease）时间内，写操作会被阻塞
当租约（tidb_table_cache_lease）到期时，读性能会下降
不支持对缓存表直接做DDL操作，需要先关闭
对于表加载较慢或者极少修改的表，可以适当延长租约（tidb_table_cache_lease）保持读性能稳定

TiKV

主要功能

数据持久化
副本的强一致性和高可用性（分布式一致性）
MVCC（多版本并发控制）
分布式事务支持
Coprocessor（协同处理器）
- 提供算子下推能力，把计算工作下放到TiKV节点进行，节省带宽和IO，过滤/投影/计算

各组件作用
- rocksdbraft：存日志
- rocksdbkv：存数据
- Raft：高可用
- MVCC：多版本控制，读取控制
- Transation：支持事务

持久化

TiKV底层持久化使用了RocksDB，RocksDB针对Flash存储进行优化，延迟极小，使用LSM存储引擎

高性能的Key-Value数据库
完善的持久化机制，同时保证性能和安全性
良好的支持范围查询
为需要存储TB级别数据到本地FLASH或者RAM的应用服务器设计
针对存储在高速设备的中小键值进行优化，可以存储在FLASH或者直接存储在内存
性能随CPU数量线性提升，对多核系统友好

RocksDB写入

sync_log=true：会调用系统fsync直接将日志写入操作系统的磁盘中，而不会通过操作系统的内存
write_buffer_size：控制当memTable内存达到多少时将数据flush进immutable
immutable的存在可以防止memTable直接写磁盘时IO慢导致memTable写阻塞
writeStall：当immutable达到5个时，会限制memTable的写入速度，并记录日志，以保护RocksDB，可以通过优化存储性能或调大参数进行优化

Level 0就是immutable的复刻
磁盘上的是SST（Sort String Table）文件
当文件达到4个时，会进行compaction（压缩&排序），将文件存进下一层，查找时用二分查找法
写入时需要一次磁盘io，一次内存io，顺序写
对写友好，删除时只要写个delete即可，更新同理

RocksDB查询

查询时，先找对应文件里key的最小值和最大值，如果需要查找的key在这个范围，就用二分查找法查找数据，并且利用布隆过滤器查询数据是否存在
- 布隆过滤器判断数据不在就一定不在，判断数据在不一定在

Column Families

列簇（CF），数据分片技术
写入：write（cf1，id，name，age），write（cf2，id，addr，tell）
默认列簇为default
日志WAL不区分，多个列簇共享同一个日志文件

分布式事务

2PC
- prewrite
- commit
分成3个CF
- Deafult：存储超过255字节长度的数据
- Lock：存储锁信息
- Write：存储提交信息和小于255字节长度的数据
只给事务的第一行加锁，其他行的锁指向主锁
在写入之前，别人感知不到，叫做乐观锁；提前将锁写入TiKV节点中，叫做悲观锁。

MVCC

id=1，可读不可写
id=2，可读可写
id=4，可读不可写

Raft

初始化时，会写入同一个region，当region达到96MB时，会写入下一个region，存储的key是左闭右开区间
修改数据过程中，当某个 Region 的大小超过一定限制（默认是 144 MiB）后，TiKV 会将它分裂为两个或者更多个 Region，当某个 Region 因为大量的删除请求而变得太小时（默认是 20 MiB），TiKV 会将比较小的两个相邻 Region 合并为一个

Raft日志复制

过程

propose：将请求转成日志
append：将日志持久化至RocksDB raft中
replicate：leader将日志复制到其他follower节点

append：follower节点将日志持久化到RocksDB Raft
committed：超过50%节点告知leader节点已完成日志持久化

Raft层committed与应用程序事务的committed不一样，这里只是说Raft多副本协议的committed
apply：将数据真正写入到RocksDB KV中

应用程序committed成功

Raft Leader选举

term ：时间段，没有固定长度
follower在特定情况下会变成candidate，candidate会发起投票，只要收到一半以上投票就成为leader，其他follower节点发现condidate节点的term比自己大，就投1票
heartbeat_time_interval：等待leader心跳的最长时间，超过时间收不到心跳就会发起选举
- TiDB参数：raft-heartbeat-ticks，默认10
election_timeout：无主状态下多长时间发起选举，实际上每个节点是随机时间random（100ms-300ms）
- TiDB参数：raft-election-timeout-ticks，不能小于raft-heartbeat-ticks
raft-base-tick-interval：raft每个ticks的大小，默认1s