1. 程式人生 > >TiDB 原始碼閱讀系列文章(二)初識 TiDB 原始碼

TiDB 原始碼閱讀系列文章(二)初識 TiDB 原始碼

本文為 TiDB 原始碼閱讀系列文章的第二篇,第一篇文章介紹了 TiDB 整體的架構,知道 TiDB 有哪些模組,分別是做什麼的,從哪裡入手比較好,哪些可以忽略,哪些需要仔細閱讀。

這篇文章是一篇入門文件,難度係數比較低,其中部分內容可能大家在其他渠道已經看過,不過為了內容完整性,我們還是會放在這裡。

TiDB 架構

本次 TiDB 原始碼之旅從這幅簡單的架構圖開始,這幅圖很多人都看過,我們可以用一句話來描述這個圖:『TiDB 是一個支援 MySQL 協議,以某種支援事務的分散式 KV 儲存引擎為底層儲存的 SQL 引擎』。從這句話可以看出有三個重要的事情,第一是如何支援 MySQL 協議,與 Client 互動,第二是如何與底層的儲存引擎打交道,存取資料,第三是如何實現 SQL 的功能。本篇文章會先介紹一些 TiDB 有哪些模組及其功能簡要介紹,然後以這三點為線索,將這些模組串聯起來。

程式碼簡介

TiDB 原始碼完全託管在 Github 上,從專案主頁可以看到所有資訊。整個專案使用 Go 語言開發,按照功能模組分了很多 Package,通過一些依賴分析工具,可以看到專案內部包之間的依賴關係。

大部分包都以介面的形式對外提供服務,大部分功能也都集中在某個包中,不過有一些包提供了非常基礎的功能,會被很多包依賴,這些包需要特別注意。

專案的 main 檔案在 tidb-server/main.go,這裡面定義了服務如何啟動。整個專案的 Build 方法可以在 Makefile 中找到。

除了程式碼之外,還有很多測試用例,可以在 xx_test.go 中找到。另外 cmd

目錄下面還有幾個工具包,用來做效能測試或者是構造測試資料。

模組介紹

TiDB 的模組非常多,這裡做一個整體介紹,大家可以看到每個模組大致是做什麼用的,想看相關功能的程式碼是,可以直接找到對應的模組。

Package Introduction
ast 抽象語法樹的資料結構定義,例如 SelectStmt 定義了一條 Select 語句被解析成什麼樣的資料結構
cmd/benchdb 簡單的 benchmark 工具,用於效能優化
cmd/benchfilesort 簡單的 benchmark 工具,用於效能優化
cmd/benchkv Transactional KV API benchmark 工具,也可以看做 KV 介面的使用樣例
cmd/benchraw Raw KV API benchmark 工具,也可以看做不帶事務的 KV 介面的使用樣例
cmd/importer 根據表結構以及統計資訊偽造資料的工具,用於構造測試資料
config 配置檔案相關邏輯
context 主要包括 Context 介面,提供一些基本的功能抽象,很多包以及函式都會依賴於這個介面,把這些功能抽象為介面是為了解決包之間的依賴關係
ddl DDL 的執行邏輯
distsql 對分散式計算介面的抽象,通過這個包把 Executor 和 TiKV Client 之間的邏輯做隔離
domain domain 可以認為是一個儲存空間的抽象,可以在其中建立資料庫、建立表,不同的 domain 之間,可以存在相同名稱的資料庫,有點像 Name Space。一般來說單個 TiDB 例項只會建立一個 Domain 例項,其中會持有 information schema 資訊、統計資訊等。
executor 執行器相關邏輯,可以認為大部分語句的執行邏輯都在這裡,比較雜,後面會專門介紹
expression 表示式相關邏輯,包括各種運算子、內建函式
expression/aggregation 聚合表示式相關的邏輯,比如 Sum、Count 等函式
infoschema SQL 元資訊管理模組,另外對於 Information Schema 的操作,都會訪問這裡
kv KV 引擎介面以及一些公用方法,底層的儲存引擎需要實現這個包中定義的介面
meta 利用 structure 包提供的功能,管理儲存引擎中儲存的 SQL 元資訊,infoschema/DDL 利用這個模組訪問或者修改 SQL 元資訊
meta/autoid 用於生成全域性唯一自增 ID 的模組,除了用於給每個表的自增 ID 之外,還用於生成
metrics Metrics 相關資訊,所有的模組的 Metrics 資訊都在這裡
model SQL 元資訊資料結構,包括 DBInfo / TableInfo / ColumnInfo / IndexInfo 等
mysql MySQL 相關的常量定義
owner TiDB 叢集中的一些任務只能有一個例項執行,比如非同步 Schema 變更,這個模組用於多個 tidb-server 之間協調產生一個任務執行者。每種任務都會產生自己的執行者。
parser 語法解析模組,主要包括詞法解析 (lexer.go) 和語法解析 (parser.y),這個包對外的主要介面是 Parse(),用於將 SQL 文字解析成 AST
parser/goyacc 對 GoYacc 的包裝
parser/opcode 關於操作符的一些常量定義
perfschema Performance Schema 相關的功能,預設不會啟用
plan 查詢優化相關的邏輯
privilege 使用者許可權管理介面
privilege/privileges 使用者許可權管理功能實現
server MySQL 協議以及 Session 管理相關邏輯
sessionctx/binloginfo 向 Binlog 模組輸出 Binlog 資訊
sessionctx/stmtctx Session 中的語句執行時所需要的資訊,比較雜
sessionctx/variable System Variable 相關程式碼
statistics 統計資訊模組
store 儲存引擎相關邏輯,這裡是儲存引擎和 SQL 層之間的互動邏輯
store/mockoracle 模擬 TSO 元件
store/mockstore 例項化一個 Mock TiKV 的邏輯,主要方法是 NewMockTikvStore,把這部分邏輯從 mocktikv 中抽出來是避免迴圈依賴
store/mockstore/mocktikv 在單機儲存引擎上模擬 TiKV 的一些行為,主要作用是本地除錯、構造單元測試以及指導 TiKV 開發 Coprocessor 相關邏輯
store/tikv TiKV 的 Go 語言 Client
store/tikv/gcworker TiKV GC 相關邏輯,tidb-server 會根據配置的策略向 TiKV 傳送 GC 命令
store/tikv/oracle TSO 服務介面
store/tikv/oracle/oracles TSO 服務的 Client
store/tikv/tikvrpc TiKV API 的一些常量定義
structure 在 Transactional KV API 上定義的一層結構化 API,提供 List/Queue/HashMap 等結構
table 對 SQL 的 Table 的抽象
table/tables 對 table 包中定義的介面的實現
tablecodec SQL 到 Key-Value 的編解碼,每種資料型別的具體編解碼方案見 codec
terror TiDB 的 error 封裝
tidb-server 服務的 main 方法
types 所有和型別相關的邏輯,包括一些型別的定義、對型別的操作等
types/json json 型別相關的邏輯
util 一些實用工具,這個目錄下面包很多,這裡只會介紹幾個重要的包
util/admin TiDB 的管理語句( Admin 語句)用到的一些方法
util/charset 字符集相關邏輯
util/chunk Chunk 是 TiDB 1.1 版本引入的一種資料表示結構。一個 Chunk 中儲存了若干行資料,在進行 SQL 計算時,資料是以 Chunk 為單位在各個模組之間流動
util/codec 各種資料型別的編解碼
x-server X-Protocol 實現

從哪裡入手

粗看一下 TiDB 有 80 個包,讓人覺得無從下手,不過並不是所有的包都很重要,另外一些功能只會涉及到少量包,從哪裡入手去看原始碼取決於看原始碼的目的。

如果是想了解某一個具體的功能的實現細節,那麼可以參考上面的模組簡介,找到對應的模組即可。

如果是相對原始碼有全面的瞭解,那麼可以從 tidb-server/main.go 入手,看 tidb-server 是如何啟動,如何等待並處理使用者請求。再跟著程式碼一直走,看 SQL 的具體執行過程。另外一些重要的模組,需要看一下,知道是如何實現的。輔助性的模組,可以選擇性的看一下,有大致的印象即可。

重要模組

在全部 80 個模組中,下面幾個模組是最重要的,希望大家能仔細閱讀,針對這些模組,我們也會用專門的文章來講解,等所有的文章都 Ready 後,我將下面的表格中的 TODO 換成對應的文章連連結。

Package Related Articles
plan TODO
expression TODO
executor TODO
distsql TODO
store/tikv TODO
ddl TODO
tablecodec TODO
server TODO
types TODO
kv TODO
tidb TODO

輔助模組

除了重要的模組之外,餘下的是輔助模組,但並不是說這些模組不重要,只是鎖這些模組並不在 SQL 執行的關鍵路徑上,我們也會用一定的篇幅描述其中的大部分包。

SQL 層架構

這幅圖比上一幅圖詳細很多,大體描述了 SQL 核心模組,大家可以從左邊開始,順著箭頭的方向看。

Protocol Layer

最左邊是 TiDB 的 Protocol Layer,這裡是與 Client 互動的介面,目前 TiDB 只支援 MySQL 協議,相關的程式碼都在 server 包中。

這一層的主要功能是管理客戶端 connection,解析 MySQL 命令並返回執行結果。具體的實現是按照 MySQL 協議實現,具體的協議可以參考 MySQL 協議文件。這個模組我們認為是當前實現最好的一個 MySQL 協議元件,如果大家的專案中需要用到 MySQL 協議解析、處理的功能,可以參考或引用這個模組。

連線建立的邏輯在 server.go 的 Run() 方法中,主要是下面兩行:

236:         conn, err := s.listener.Accept()

258:         go s.onConn(conn)

單個 Session 處理命令的入口方法是呼叫 clientConn 類的 dispatch 方法,這裡會解析協議並轉給不同的處理函式。

SQL Layer

大體上講,一條 SQL 語句需要經過,語法解析–>合法性驗證–>制定查詢計劃–>優化查詢計劃–>根據計劃生成查詢器–>執行並返回結果 等一系列流程。這個主幹對應於 TiDB 的下列包:

Package 作用
tidb Protocol 層和 SQL 層之間的介面
parser 語法解析
plan 合法性驗證 + 制定查詢計劃 + 優化查詢計劃
executor 執行器生成以及執行
distsql 通過 TiKV Client 向 TiKV 傳送以及彙總返回結果
store/tikv TiKV Client

KV API Layer

TiDB 依賴於底層的儲存引擎提供資料的存取功能,但是並不是依賴於特定的儲存引擎(比如 TiKV),而是對儲存引擎提出一些要求,滿足這些要求的引擎都能使用(其中 TiKV 是最合適的一款)。

最基本的要求是『帶事務的 Key-Value 引擎,且提供 Go 語言的 Driver』,再高階一點的要求是『支援分散式計算介面』,這樣 TiDB 可以把一些計算請求下推到 儲存引擎上進行。

這些要求都可以在 kv 這個包的介面中找到,儲存引擎需要提供實現了這些介面的 Go 語言 Driver,然後 TiDB 利用這些介面操作底層資料。

對於最基本的要求,可以重點看這幾個介面:

有了上面這些介面,可以對資料做各種所需要的操作,完成全部 SQL 功能,但是為了更高效的進行運算,我們還定義了一個高階計算介面,可以關注這三個 Interface/struct :

  • Client:向下層傳送請求以及獲取下層儲存引擎的計算能力

小結

至此,讀者已經來了解了 TiDB 的原始碼結構以及三個主要部分的架構,更詳細的內容會在後面的章節中詳細描述。

作者:申礫