背景

tidb這個技術(shù)名詞很多同學(xué)或多或少都曾經(jīng)耳聞過，但是很多同學(xué)覺得他是分布式數(shù)據(jù)庫，自己的業(yè)務(wù)是使用mysql，基本使用不上這個技術(shù)，可能不會去了解他。最近業(yè)務(wù)上有個需求使用到了tidb，于是學(xué)習(xí)了一下基本原理，會發(fā)現(xiàn)這些原理其實不僅僅局限于分布式數(shù)據(jù)庫這一塊，很多技術(shù)都是通用的，所以在這里寫一下分享一下學(xué)習(xí)tidb的一些心得。

先說說為什么選擇tidb吧，一般來說在咱們的業(yè)務(wù)中都是使用的mysql,但是單機數(shù)據(jù)庫容量和并發(fā)性能都有限，對于一些大容量或者高并發(fā)的場景我們會選擇sharding-jdbc去做，使用sharding-jdbc的確解決了問題但是增加了開發(fā)難度，我需要對我的每一個表都設(shè)置分表key，并且每個查詢都得帶入這個key的值，這樣就增加了查詢限制，如果不帶key的值就得所有庫表都得查詢一次才行，效率極低，所以我們又異構(gòu)了一份數(shù)據(jù)到es來滿足其他條件。怎么解決這個問題呢？正好公司最近內(nèi)部在推tidb，我看了下tidb基本兼容mysql，存儲無限擴展，開發(fā)成本比較低，性能整體也不錯，所以決定使用了tidb。?

數(shù)據(jù)庫發(fā)展歷史

關(guān)系型單機數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫的開始是以1970年Edgar F.Codd 提出了關(guān)系模型。在數(shù)據(jù)庫發(fā)展早期階段，出現(xiàn)了很多優(yōu)秀的商業(yè)數(shù)據(jù)庫產(chǎn)品，如Oracle/DB2。在1990年之后，出現(xiàn)了開源數(shù)據(jù)庫MySQL和PostgreSQL。這些數(shù)據(jù)庫不斷地提升單機實例性能，再加上遵循摩爾定律的硬件提升速度，往往能夠很好地支撐業(yè)務(wù)發(fā)展。

分布式數(shù)據(jù)庫

隨著摩爾定律的失效，單體數(shù)據(jù)庫的發(fā)展很難應(yīng)對更高級別的挑戰(zhàn)，所以就出現(xiàn)了分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫擁有應(yīng)對海量并發(fā)，海量存儲的能力所以能應(yīng)對更難的挑戰(zhàn)。

• nosql:HBase是其中的典型代表。HBase是Hadoop生態(tài)中的重要產(chǎn)品，Google BigTable的開源實現(xiàn)，當(dāng)然還有我們熟悉的redis，nosql有一些自己的特殊使用場景，所以有一些自己的弊端，BigTable不支持跨行事務(wù)，用java開發(fā)性能也跟不上，redis的話用內(nèi)存存儲，無法保證事務(wù)。并且nosql已經(jīng)是不靠關(guān)系模型了。

• sharding: 我們依然可以通過單機數(shù)據(jù)庫完成我們分布式數(shù)據(jù)庫的功能，我們通過某個組件實現(xiàn)對sql進行分發(fā)到不同分片的功能，比如比較出名開源的有sharing-jdbc，mycat，阿里云上商業(yè)的有drds。sharing的話對于運維來說比較困難，如果需要擴容需要不斷的進行手動遷移數(shù)據(jù)，還需要自己指定某一個分片key。

• newsql:在newsql中可以保證acid的事務(wù)，也維持了關(guān)系模型，并且還支持sql。比較出名的有g(shù)oole的F1和Spanner，阿里的OceanBase,pingCap的tidb。

學(xué)前提問

在我們學(xué)習(xí)某個知識的時候，一般都是會帶著一些問題去學(xué)習(xí)，有目的的學(xué)習(xí)會讓你更快的上手，對于tidb或者分布式數(shù)據(jù)庫，我在使用的時候會有這些疑問：

• 如何保證無限擴展？因為平時使用的大多都是sharding-jdbc那種有個sharding-key的技術(shù)，這種其實無限擴展是比較麻煩的，所以我最開始就對tidb如何保證無限擴展發(fā)出了疑問？

• 如何保證id唯一，分布式數(shù)據(jù)庫往往會進行分片，在單機數(shù)據(jù)庫中的自增id就不成立，tidb是如何保證的呢？

• 如何保證事務(wù)？前面我們說過newsql是需要支持acid的事務(wù)的，那么我們的tidb是如何保證的呢？

• 通過索引是如何查詢數(shù)據(jù)的呢？單機數(shù)據(jù)庫使用了索引加速查詢，tidb又是如何做到用索引加速查詢的呢？

tidb

架構(gòu)

再回答我們上面的那些問題之前，先看一看tidb的整體架構(gòu)是什么？?

tidb其實是典型的計算分離的架構(gòu)，對計算分離架構(gòu)不熟悉的可以看看我之前的文章:聊聊計算與分離

• TiDB Server：計算層，對外暴露協(xié)議的連接端口，負(fù)責(zé)管理客戶端的連接，主要做的就是執(zhí)行SQL解析以及優(yōu)化，生成分布式執(zhí)行計劃，由于這里是計算層是沒有狀態(tài)的，所以是可以無限擴展。

• PD Server:PD是整個集群的大腦，負(fù)責(zé)存儲每個 TiKV 節(jié)點實時的數(shù)據(jù)分布情況和集群的整體拓?fù)浣Y(jié)構(gòu)，提供 TiDB Dashboard 管控界面，需要保持高可用。

• TiKV: k-v存儲引擎，在tikv內(nèi)部，存儲數(shù)據(jù)的基本單位是Region。

• Tiflash：這個是用于列式的存儲引擎

• TSpark: 這是tidb對spark進行支持，所以tidb他是一個HTAP的數(shù)據(jù)庫。

如何無限擴展？

我們首先來到我們的第一個問題，Tidb如何做到無限擴展？

首先我們來看看計算層: tidb-server，我們剛才說過在計算層中，是無狀態(tài)的，所以就可以進行無限擴展，如果你的場景并發(fā)度很高或者數(shù)據(jù)庫連接很多，可以考慮多擴展tidb-server。

然后我們來看看存儲層，有一類數(shù)據(jù)云數(shù)據(jù)庫通常也會被誤認(rèn)為是分布式數(shù)據(jù)庫，也就是aws的auroradb和阿里云的polardb，這兩個數(shù)據(jù)庫也是采用的計算與存儲分離的架構(gòu)，在計算層也可以無限擴展，但是在存儲層他們使用的是一份數(shù)據(jù)，這個也就是shared-storage架構(gòu)，這兩個數(shù)據(jù)庫依靠這大容量磁盤，來支撐更高容量的數(shù)據(jù)。

在tidb中是shared-nothing架構(gòu)，存儲層也是分離的：?

在每個tikv上會劃分出多個Region,這個也就是我們的基本存儲單位,大家見這個圖是不是發(fā)現(xiàn)這個架構(gòu)似曾相識呢？

從上面看，region就對應(yīng)這kafka下的partition，partition在kafka中的作用也是用來將topic的壓力打散到不同broker上，同樣的在tidb的region上也是一樣的,我們通過region為最小單位進行存儲。

再詳細(xì)介紹region之前先說一下存儲引擎為什么叫tikv呢？原因就是這個存儲引擎就是保存的就是一個key-value，你可以理解成java里面的hashmap，在tikv中沒有選擇自己研發(fā)如何將這個map數(shù)據(jù)去落地，而是通過一個非常優(yōu)秀的kv存儲引擎——rocksdb去進行磁盤落地。RocksDB是Facebook開源的一個KV高性能單機數(shù)據(jù)庫，很多公司基于rocksdb做了很多優(yōu)秀的存儲產(chǎn)品，后面也會詳細(xì)的寫一篇介紹rocksdb的文章。

rocksdb是一個單機的存儲引擎那么我們是需要保證數(shù)據(jù)在分布式環(huán)境下是不丟失的，在kafka中有其他partition的副本會不斷的拉取leader副本，并且通過一個ISR的機制去維護。在tikv中，直接使用的raft協(xié)議去做數(shù)據(jù)復(fù)制，每個數(shù)據(jù)變更都會落地為一條 Raft 日志，通過 Raft 的日志復(fù)制功能，將數(shù)據(jù)安全可靠地同步到復(fù)制組的每一個節(jié)點中。不過在實際寫入中，根據(jù) Raft 的協(xié)議，只需要同步復(fù)制到多數(shù)節(jié)點，即可安全地認(rèn)為數(shù)據(jù)寫入成功。

可以發(fā)現(xiàn)其實這里是寫的raft,通過raft接口再寫的rocksdb。

我們這里回到region，region還有一個partition不一樣的點在于，partition一般不會自動去擴容，在業(yè)務(wù)開發(fā)中他往往是一個恒定得值，而region不一樣，region的大小默認(rèn)是96MB，再實際得業(yè)務(wù)中，我們的region的個數(shù)會隨著我們數(shù)據(jù)量而變多，當(dāng)然如果我們的數(shù)據(jù)量變小，他也會自動合并。

如何確定某個數(shù)據(jù)是在哪個region上呢？一般來說有hash(key)和range(key)的方案，在tikv中選擇的是rangekey，因為對于region分裂是比較方便的，每一個region其實就是一個[StartKey，EndKey) 的表示：

出現(xiàn)region的分裂的時候，只需要新增一個region，將老region的數(shù)據(jù)拿出一部分到新region， 譬如 [a, b) -> [a, ab) [ab, b)，如果是hash來做的話，他會將所有region的數(shù)據(jù)都會重新hash，所以在tikv中選的是range(key)的方式，合并也是一樣。

所以對于tidb來說無論是存儲層還是計算層，我們都可以無限擴展。

如何保證id唯一

在mysql中我們可以對于主鍵直接設(shè)置?AUTO_INCREMENT來達到自增列的效果，mysql是怎么做到自增的呢？

• 在MySQL5.7及之前的版本：InnoDB引擎的自增值，自增值保存在內(nèi)存里，并沒有持久化。每次重啟后，第一次打開表的時候，都會去找自增值的最大值max(id)，然后將max(id) 步長作為這個表當(dāng)前的自增值。

• 在MySQL8.0版本：將自增值的變更記錄在了redo log中，重啟的時候依靠redo log恢復(fù)重啟之前的值。

在單機中這些都好做，但是在分布式數(shù)據(jù)庫中，我們就沒法保證id的唯一了，我之前有寫過相關(guān)的文章：如果再有人問你分布式ID，這篇文章丟給他。我們在使用sharding-jdbc的時候就是使用的文章介紹的leaf這個ID生成中間件，來完成ID生成。

在Tidb中同樣支持?AUTO_INCREMENT,實現(xiàn)的原理和leaf中的號段模式一樣，不能保證嚴(yán)格遞增，只能保證趨勢遞增，具體原理是：，對于每一個自增列，都使用一個全局可見的鍵值對用于記錄當(dāng)前已分配的最大 ID。由于分布式環(huán)境下的節(jié)點通信存在一定開銷，為了避免寫請求放大的問題，每個 TiDB 節(jié)點在分配 ID 時，都申請一段 ID 作為緩存，用完之后再去取下一段，而不是每次分配都向存儲節(jié)點申請。

tidb還支持?AUTO_RANDOM,可以用于解決大批量寫數(shù)據(jù)入 TiDB 時因含有整型自增主鍵列的表而產(chǎn)生的熱點問題。因為region是有序的如果一段時間大量有序的數(shù)據(jù)產(chǎn)生有可能會在同一個region上，所以我們可以使用AUTO_RANDOM來將我們的主鍵數(shù)據(jù)打散。

如何保證事務(wù)

這里我們先回顧一下事務(wù)的四大特性ACID，我們來想想在mysql的innodb中這個是怎么做的呢？

• A:原子性，指一個事務(wù)中的所有操作，或者全部完成，或者全部不完成，不會結(jié)束在中間某個環(huán)節(jié)，原子性在mysql中我們是依賴redolog和undolog共同完成

• C:一致性，指在事務(wù)開始之前和結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。一致性是依靠其他幾個特性來保證的。

• I:隔離性，指數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進行讀寫和修改的能力。隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致，主要用于處理并發(fā)場景。mysql隔離性依靠的是鎖和mvcc，在mysql里面鎖的種類很豐富，mysql支持多種隔離性。

• D:持久性，事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失，持久性是依靠redolog和mysql的刷盤機制。

在tidb中ACID是什么做到的呢？

• A:通過 Primary Key 所在 Region 的原子性來保證分布式事務(wù)的原子。

• C:TiDB 在寫入數(shù)據(jù)之前，會校驗數(shù)據(jù)的一致性，校驗通過才會寫入內(nèi)存并返回成功。

• I:也是通過鎖和mvcc來完成隔離性，但是在tidb只支持RR(可重復(fù)讀)級別，RC隔離級別在4.0之后樂觀模式下也能支持。

• D:事務(wù)一旦提交成功，數(shù)據(jù)全部持久化存儲到 TiKV，并且還有多副本機制，如果發(fā)生宕機數(shù)據(jù)也不會丟失。

在mysql中的事務(wù)模型都是悲觀事務(wù)模型，而在tidb中事務(wù)模型提供了樂觀和悲觀兩種，怎么去理解悲觀和樂觀兩種模型呢：

• 悲觀模型：其實和名字一樣，只要在事務(wù)執(zhí)行的時候認(rèn)為每一條被你修改的數(shù)據(jù)都很大概率被其他事務(wù)修改(悲觀的看法)。在mysql里面，如果你在事務(wù)中你對某一行修改是會給你加上行鎖的，如果此時有其他事務(wù)想對這個數(shù)據(jù)進行修改，那么其他事務(wù)會被阻塞等待住?？梢院唵卫斫獬蛇厛?zhí)行邊檢測沖突。

• 樂觀模型：我們認(rèn)為我們修改的數(shù)據(jù)很大概率不會和其他事務(wù)產(chǎn)生沖突，所以不需要邊執(zhí)行邊進行沖突檢測，而是最后提交的時候進行沖突檢測。如果沖突比較少這樣就可以獲得較高的性能。

在tidb中是如何實現(xiàn)這兩種模式的呢？因為我們是分布式數(shù)據(jù)庫，兩階段提交一般是分布式事務(wù)的通用解決方案，之前我寫過很多分布式事務(wù)相關(guān)的文章大家可以自行查閱一下。

樂觀模式

tidb同樣使用兩階段提交來保證分布式事務(wù)的原子性，分為 Prewrite 和 Commit 兩個階段：

• Prewrite：對事務(wù)修改的每個 Key 檢測沖突并寫入 lock 防止其他事務(wù)修改。對于每個事務(wù)，TiDB 會從涉及到改動的所有 Key 中選中一個作為當(dāng)前事務(wù)的 Primary Key，事務(wù)提交或回滾都需要先修改 Primary Key，以它的提交與否作為整個事務(wù)執(zhí)行結(jié)果的標(biāo)識。

• Commit：Prewrite 全部成功后，先同步提交 Primary Key，成功后事務(wù)提交成功，其他 Secondary Keys 會異步提交。

整個事務(wù)步驟如下：

• Step 1: 客戶端開啟事務(wù)，類似我們在mysql里面的?begintrasaction;

• Step 2: TiDB 向 PD 獲取全局時間，可以知道這個事務(wù)的全局順序，用于后續(xù)mvcc的處理

• Step 3: 發(fā)起DML，比如update xxx; 這個時候不會有沖突檢測，只會在tidb內(nèi)存中進行保存;

• Step 4: 提交事務(wù)，類似我們在mysql里面的commit，這個時候tidb會在commit階段完成兩階段提交，先進行prewrite 各種加鎖檢測之后如果沒有問題再進行commit。這里舉個例子:

1. begin; //step1

2. insert into xx; // step3

3. update xx; // step3

4. update xx; // step3

5. commit;// step4

在上面的例子中如果是悲觀模式step3的時候就會進行加鎖檢測了，樂觀模式下所有的工作都放在了commit中，所以會出現(xiàn)commit出現(xiàn)異常的狀態(tài)，所以我們使用樂觀模式需要更好的處理commit階段的異常行為，這和我們一般的編程不一樣。但是如果數(shù)據(jù)的競爭不是太激烈的話是可以使用樂觀模式來提升性能的。

悲觀模式

悲觀模式把lock進行了提前，每個 DML 都會加悲觀鎖，鎖寫到 TiKV 里，同樣會通過 raft 同步，在加悲觀鎖時檢查各種約束，如 Write Conflict、key 唯一性約束等。

悲觀事務(wù)下能保證我們的commit成功，這種模式比較符合我們的編程模式，所以tidb默認(rèn)的模式也是悲觀模式。

如何做的索引查詢

為什么我會想到這個索引查詢這個問題呢？當(dāng)時是在看到了rocksdb是tidb的底層存儲介質(zhì)之后，我想到了在innodb中我們的索引是B 樹，如果tidb的索引是b 樹的話，那么rocksdb應(yīng)該怎么去構(gòu)造呢？

事實上在tidb中的索引也是使用的k-v形式去做的，我們先看看對于每一行的數(shù)據(jù)是怎么存儲的：

• 為了保證同一個表的數(shù)據(jù)放在一起，方便查找，TiDB 會為每個表分配一個表 ID，用 TableID 表示。表 ID 是一個整數(shù)，在整個集群內(nèi)唯一。

• TiDB 會為表中每行數(shù)據(jù)分配一個行 ID，用 RowID 表示。行 ID 也是一個整數(shù)，在表內(nèi)唯一。對于行 ID，TiDB 做了一個小優(yōu)化，如果某個表有整數(shù)型的主鍵，TiDB 會使用主鍵的值當(dāng)做這一行數(shù)據(jù)的行 ID。每行數(shù)據(jù)按照如下規(guī)則編碼成 (Key, Value) 鍵值對：

1. Key: tablePrefix{TableID}_recordPrefixSep{RowID}

2. Value: [col1, col2, col3, col4]

假定我們的tablePrefix是常量字符t,recordPrefixSep是常量字符r，我們的tableId是1,rowID在這里是我們的主鍵假定是100,如果有一個用戶表的數(shù)據(jù)，如下：

1. Key: t1_r100

2. Value: [100, "zhangsan"]

如果我們的主鍵為整數(shù)的情況下，那么上面也可以看作是我們的主鍵索引，如果我們的主鍵不為整型或者說在唯一索引的情況下，規(guī)則編碼如下：

1. Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue

2. Value: RowID

indexId是tidb為每個索引分配的ID，所以上面那個情況下一個indexedColumnsValue只能對應(yīng)一條數(shù)據(jù)滿足唯一性，如果是非唯一索引，我們可以有：

1. Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue_rowId

2. Value: null

這樣一個indexedColumnsValue就可以有多行數(shù)據(jù)，所以其實我們region中的數(shù)據(jù)的索引并不會和region的數(shù)據(jù)再一起，而是有自己的region分片，同樣的我們查詢數(shù)據(jù)的時候需要依靠我們的tidb-server分析出來我們應(yīng)該用什么樣的索引，先根據(jù)索引數(shù)據(jù)查詢出來rowId再根據(jù)rowId查詢出來我們對應(yīng)的數(shù)據(jù)。

總結(jié)

不管是tidb還是分布式數(shù)據(jù)庫，要學(xué)習(xí)的知識還有非常的多，上面只是對tidb做了一些粗解的分析，如果大家要學(xué)習(xí)可以看看下面的一些資料：

• pingcap文檔: https://docs.pingcap.com, ping cap的文檔是我見過做得算是比較頂級的文檔了，他可以說不叫做文檔，其實是一個文章知識庫，我的文章很多圖和內(nèi)容都是借鑒而來。

• 極客時間《分布式數(shù)據(jù)庫》：極客時間有一個課叫分布式數(shù)據(jù)庫，不會局限于講tidb，主要講解的是分布式數(shù)據(jù)庫的各種知識，并且會列舉市場上的分布式數(shù)據(jù)庫做對比。

• 《數(shù)據(jù)庫系統(tǒng)內(nèi)幕》：豆瓣評分8.5，這本書講解了很多數(shù)據(jù)庫理論基本知識，不論上分布式數(shù)據(jù)庫還是單機數(shù)據(jù)庫都會使用到，稍微有一點難懂，但是還是會有不少收獲。

如果大家覺得這篇文章對你有幫助，你的關(guān)注和轉(zhuǎn)發(fā)是對我最大的支持，O(∩_∩)O: