TiDB-从0到1-分布式存储

TiDB从0到1系列
TiDB-从0到1-体系结构
TiDB-从0到1-分布式存储
TiDB-从0到1-分布式事务
TiDB-从0到1-MVCC
TiDB-从0到1-部署篇
TiDB-从0到1-配置篇
TiDB-从0到1-集群扩缩容
TiDB-从0到1-数据导出导入
TiDB-从0到1-BR工具
TiDB-从0到1-sync-diff-inspector数据校验工具
TiDB-从0到1-DM工具
TiDB-从0到1-TiCDC数据同步工具

一、TiDB-DML语句执行流程（增删改）

DML流程概要

1、协议验证
用户连接到TiDB Server后首先工作的是Protocol Layer模块，该模块会对用户身份、连接进行验证。
2、获取TSO
TSO是由PD Leader节点进行分配，TiDB在事务开始时会获取TSO作为start_ts，提交时再次获取TSO作为commit_ts，其最重要的目的是实现分布式事务的MVCC。
TSO为64位整型数值，由物理部分和逻辑部分组成，高48位为物理部分是unixtime的毫秒时间，低18位为逻辑部分是一个数值计数器。理论上每秒钟可产生2^18*1000=262144000个TSO。
3、SQL解析

• Parse：词法分析（lex）和语法分析（yacc）
  
• Compile：优化器
  
  以插入数据为例，最终效果就是将关系型数据转变为KV型
  
  
  4、日志落盘
  当用户侧执行commit提交数据后，会优先日志落盘（wal文件）
  5、数据落盘
• 数据最先写入内存的memtable中
• 当memtable到达一定量时会刷写到内存的immutable中
• 当immutable到达一定量时会刷写到磁盘的rocksdb中
• rocksdb底层也是以level 0向-level n不断聚合下推

以上就是一条DML在TiDB中的完整生命周期。

二、分布式存储

TiDB架构中的分布式存储主要是在TiKV中实现。
注意：一个TiKV中有两个RocksDB实例，一个存储Raft_Log，一个存储真正的KV数据

假设有三个TiKV节点，当用户commit后：
1、Propose阶段
在Leader节点形成Raft_Log

2、Append阶段
Leader节点将Raft_Log写入Raft_DB

3、Replicate阶段
Leader节点的Raft_Log复制到其他节点

4、Committed阶段
需要判断是否超半数阶段接受raft_log成功

5、Apply阶段
各个节点将Raft_Log转化为Raft_DB

到此用户端commit成功。

彩蛋

优秀的 LSM-Tree-KV数据库有很多，为什么TiDB选择了RocksDB？
其中很大一部分原因是因为RocksDB社区活跃度很好，正如之前说到“一个产品的社区生态可以更直接的反应产品力”。