TIDB分享TIDB适用场景TIDB整体架构TIDB特点TIDB-Server内部架构TIDB-Server协议层-ProtocolLay
erTiDB的ProtocolLayer，是与Client交互的接口，目前TiDB只支持MySQL协议，这一层的主
要功能是管理客户端connection，解析MySQL命令并返回执行结果。连接TiDBmysql-uroot-h1
0.216.26.48-P4000TIDBSQL层-一条SQL的前生今世一条SQL语句需要经过，语法解析–>合法性验证–>
制定查询计划–>优化查询计划–>根据计划生成查询器–>执行并返回结果等一系列流程。运行执行器TiDB的执行引擎是以Volca
no模型运行，所有的物理Executor构成一个树状结构，每一层通过调用下一层的Next/NextChunk()方法获取
结果。举个例子，假设语句是?SELECTc1FROMtWHEREc2>1;并且查询计划选择的是全表扫描+过滤一条i
nsert的执行流程TIDB优化器-逻辑算子DataSource这个就是数据源，也就是表，selectfromt里面的
t。Selection选择，例如selectxxxfromtwherexx=5里面的where过滤条件。
Projection投影，selectcfromt里面的取c列是投影操作。Join连接，selectxxf
romt1,t2wheret1.c=t2.c就是把t1t2两个表做Join。Sort就是selectx
xfromxxorderby里面的orderby。Aggregation，在selectsum(xx)from
xxgroupbyyy中的groupby操作，按某些列分组。分组之后，可能带一些聚合函数，比如Max/Min/S
um/Count/Average等，这个例子里面是一个sum。选择，投影，连接（简称SPJ）是最基本的算子。其中Join
有内连接，左外右外连接等多种连接方式。TIDB逻辑算子的执行流程selectxxfromt1,t2wheret1.c
=t2.c变成逻辑查询计划之后，t1t2对应的DataSource，负责将数据捞上来。上面接个Join算子，将两个
表的结果按?t1.c=t2.c连接，再按?t1.a>5?做一个Selection过滤，最后将b列投影。下图是未经优
化的表示：TIDB基于规则的优化器-逻辑优化RBO（rulebasedoptimization）列裁剪（去除不必要的列）最大最
小消除（改写max/min等Aggregation操作）投影消除（消除不必要Projection算子）谓词下推（条件下推，减少I
O）JOIN条件的谓词下推（leftjoin改写innerjoin）构建节点属性（构建uniquekey和MaxOne
Row属性，构建优化过程所需信息）TIDB基于代价的优化器-物理优化（CBO）TiDB物理算子TiDBCBO流程TiDB内存
存储结构-Chunk从TiDB2.0后，引入了叫Chunk的数据结构用来在内存中存储内部数据，用于减小内存分配开销、降低内
存占用以及实现内存使用量统计/控制，其特点如下1.只读2.不支持随机写3.只支持追加写列存储，同一列的数据连续的在内存中存放
，Chunk本质上是Column的集合，它负责连续的在内存中存储同一列的数据TIDB逻辑结构-RowTiDB内存存储结构-C
hunk分类TiDB执行框架简介新的执行框架老的执行框架每次返回一条数据每次返回一批数据TIDB-Server-KV接口层-KV
APILayerTiDB依赖于底层的存储引擎提供数据的存取功能，但是并不是依赖于特定的存储引擎（比如TiKV），而是对存储引
擎提出一些要求，满足这些要求的引擎都能使用（其中TiKV是最合适的一款）。TIDB-TIKV-client带来的问题1.每次读
取数据的时候，都需要先去访问PD，这样会给PD带来巨大压力，同时影响请求的性能解决：设计了RegionCache，采用Map+B
-Tree来在TIDB端缓存Region信息2.TCP连接的建立和关闭有不小的开销，同时会增大延迟解决：使用连接池可以节省这部
分开销，TiDB和tikv-server之间也维护了一个连接池connArray。TIKVTIKV特点1TIKV特点2TI
KV存储-RAFTLEADERFLOLLOWERTIKV存储-MultiRaftRaftGroup处理的数据量有限，将数据切
分成多个RaftGroup，称之为RegionRegion按照range进行切分，每个Region都是一段段联系的keyra
nge，每个keyrange就是一个RegionRegion的range使用的是前闭后开的模式[start,end
)，keystart属于这个Region，end属于下一个Region。TiKV的Region会有最大size
的限制，当超过这个阈值之后，会进行分裂，譬如[a,b)->[a,ab)+[ab,b)，Region数据较少，会和相
邻的Region进行合并，变成一个更大的Region，譬如[a,ab)+[ab,b)->[a,b)分布式事务
-2PC二阶提交协议（TwoPhaseCommitmentProtocol）第一阶段：准备阶段(投票阶段)事务协调者(事务管
理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的
redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。第二阶段：提交阶段（执行阶段）如果协调者收到了参与者的失败
消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交
或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)分布式事务-为什么是Percolator对于相
同的Region，采用Region来保持数据一致性，对于不同Region内的数据，无法使用Raft进行处理如果我们需要同时修改a
=1，b=2，而且a和b属于不同的Region，那么当操作结束后，必须要存在ab同时成功或者失败的情况最通常的分布式事务的
做法就是使用two-phasecommit，也就是俗称的2PC，但传统的2PC需要有一个协调者，而我们也需要有机制来保证
协调者的高可用。这里，TiKV参考了Google的Percolator，对2PC进行了优化，来提供分布式事务支持。分布
式事务-Percolator原理时间戳（timestamp）Percolator需要一个服务timestampor
acle(TSO)来分配全局的timestampTSO需要按照时间单调递增，而且全局唯一任何事务在开始的时候会先拿一个st
arttimestamp(startTS)，然后在事务提交的时候会拿一个committimestamp(commitTS
)。列族（columnfamily）Percolator提供三个columnfamily(CF)，Lock
当写入一个key-value的时候，会将这个key的lock放到LockCF里面Data将实际的value
放到DataCF里面Write，如果这次写入commit成功，则会将对应的commit信息放到入WriteCF
里面。分布式事务-Percolator写入流程TIKV底层存储-RocksDB每个TiKV包含两个RocksDB实例，R
aftRocksDB:用于存储RaftLogKVRocksDB:用于存储用户的实际数据KVRocksDB。PD-元
数据存储TIKV读写流程--APITiKV提供两套API，一套叫做RawKV，另一套叫做TxnKVTxnKV对应的就是上
面提到的Percolator，RawKV则不会对事务做任何保证，而且比TxnKV简单很多，这里我们先讨论RawKV。TI
KV读写流程--RAWKVTIKV读写流程--TxnKVSQLKeyMappingPD调度原理-概念介绍PD调度原理-调度流程
PD调度-BalancePD调度-热点调度热点调度对应的调度器是hot-region-scheduler。目前3.0版本统
计热点Region的方式比较单一，就是根据Store上报的信息，统计出持续一段时间读或写流量超过一定阈值的Region，
然后再用与Balance类似的方式把这些Region分散开来。PD调度-集群拓扑感知让PD感知不同节点分布的拓扑是为了
通过调度使不同Region的各个副本尽可能分散，保证高可用和容灾。例如集群有3个数据中心，最安全的调度方式就是把Regi
on的3个Peer分别放置在不同的数据中心，这样任意一个数据中心故障时，都能继续提供服务。PD会在后台不断扫描所有R
egion，当发现Region的分布不是当前的最优化状态时，会生成调度替换Peer，将Region调整至最佳状态。PD调
度-缩容及故障恢复缩容是指预备将某个Store下线，通过命令将该Store标记为Offline状态，此时PD通过调
度将待下线节点上的Region迁移至其他节点。故障恢复是指当有Store发生故障且无法恢复时，有Peer分布在对应S
tore上的Region会产生缺少副本的状况，此时PD需要在其他节点上为这些Region补副本。PD调度-RegionmergeRegionmerge指的是为了避免删除数据后大量小Region甚至空Region消耗系统资源，通过调度把相邻的小Region合并的过程。Regionmerge由mergeChecker负责，其过程与replicaChecker类似，也是在后台遍历，发现连续的小Region后发起调度。TiDB生态工具我司的TiDB架构设想 |
|
