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社區活躍度很好，正如之前說到“一個產品的社區生態可以更直接的反應產品力”。