TiDB从0到1系列
- TiDB-从0到1-体系结构
- TiDB-从0到1-分布式存储
- TiDB-从0到1-分布式事务
- TiDB-从0到1-MVCC
一、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社区活跃度很好，正如之前说到“一个产品的社区生态可以更直接的反应产品力”。
