摘要：對(duì)于上面表來(lái)說(shuō)，假設(shè)現(xiàn)在它有兩行數(shù)據(jù)，分別是和，在里面，每一行數(shù)據(jù)會(huì)有不同的對(duì)應(yīng)。對(duì)于來(lái)說(shuō)，也是具有唯一性的，所以我們用來(lái)表示，而則是對(duì)應(yīng)的。如果兩個(gè)相同，就會(huì)破壞唯一性約束。因?yàn)橐欢ㄊ俏ㄒ坏?，所以?xún)尚袛?shù)據(jù)即使一樣，也不會(huì)沖突。

上篇文章中，我們介紹了與 TiKV 處理讀寫(xiě)請(qǐng)求相關(guān)的基礎(chǔ)知識(shí)，下面將開(kāi)始詳細(xì)的介紹 TiKV 的讀寫(xiě)流程。Enjoy~

作者：唐劉 @siddontang

TiKV 提供兩套 API，一套叫做 RawKV，另一套叫做 TxnKV。TxnKV 對(duì)應(yīng)的就是上面提到的 Percolator，而 RawKV 則不會(huì)對(duì)事務(wù)做任何保證，而且比 TxnKV 簡(jiǎn)單很多，這里我們先討論 RawKV。

當(dāng)進(jìn)行寫(xiě)入，譬如 Write a = 1，會(huì)進(jìn)行如下步驟：

Client 找 PD 問(wèn) a 所在的 Region

PD 告訴 Region 相關(guān)信息，主要是 Leader 所在的 TiKV

Client 將命令發(fā)送給 Leader 所在的 TiKV

Leader 接受請(qǐng)求之后執(zhí)行 Raft 流程

Leader 將 a = 1 Apply 到 KV RocksDB 然后給 Client 返回寫(xiě)入成功

對(duì)于 Read 來(lái)說(shuō)，也是一樣的操作，唯一不同在于 Leader 可以直接提供 Read，不需要走 Raft。

對(duì)于 TxnKV 來(lái)說(shuō)，情況就要復(fù)雜的多，不過(guò)大部分流程已經(jīng)在 Percolator 章節(jié)進(jìn)行說(shuō)明了。這里需要注意的是，因?yàn)槲覀円焖俚?seek 到最新的 commit，所以在 RocksDB 里面，我們會(huì)先將 TS 使用 bigendian 生成 8 字節(jié)的 bytes，然后將這個(gè) bytes 逐位取反，在跟原始的 key 組合存儲(chǔ)到 RocksDB 里面，這樣就能保證最新的提交存放到前面，seek 的時(shí)候就能直接定位了，當(dāng)然 seek 的時(shí)候，也同樣會(huì)將對(duì)應(yīng)的 TS 按照相同的方式編碼處理。

譬如，假設(shè)一個(gè) key 現(xiàn)在有兩次提交，commitTS 分別為 10 和 12，startTS 則是 9 和 11，那么在 RocksDB 里面，key 的存放順序則是：

Write CF：

a_12 -> 11
a_10 -> 9

Data CF:

a_11 -> data_11
a_9 -> data_9

另外，還需要注意的是，對(duì)于 value 比較小的情況，TiKV 會(huì)直接將 value 存放到 Write CF 里面，這樣 Read 的時(shí)候只要走 Write CF 就行了。在寫(xiě)入的時(shí)候，流程如下：

PreWrite：

Lock CF: W a -> Lock + Data

Commit:
Lock CF: R a -> Lock + 10 + Data
Lock CF: D a

Write CF: W a_11 -> 10 + Data

對(duì)于 TiKV 來(lái)說(shuō)，在 Commit 階段無(wú)論怎樣都會(huì)讀取 Lock 來(lái)判斷事務(wù)沖突，所以我們可以從 Lock 拿到數(shù)據(jù)，然后再寫(xiě)入到 Write CF 里面。

Read 的流程之前的 Percolator 已經(jīng)有說(shuō)明了，這里就不詳細(xì)解釋了。

我們?cè)?TiKV 上面構(gòu)建了一個(gè)分布式數(shù)據(jù)庫(kù) TiDB，它是一個(gè)關(guān)系型數(shù)據(jù)庫(kù)，所以大家需要關(guān)注的是一個(gè)關(guān)系型的 table 是如何映射到 key-value 上面的。假設(shè)我們有如下的表結(jié)構(gòu)：

CREATE TABLE t1 {
    id BIGINT PRIMARY KEY,
    name VARCHAR(1024),
    age BIGINT,
    content BLOB,
    UNIQUE(name),
    INDEX(age),
}

上面我們創(chuàng)建了一張表 t1，里面有四個(gè)字段，id 是主鍵，name 是唯一索引，age 是一個(gè)索引。那么這個(gè)表里面的數(shù)據(jù)是如何對(duì)應(yīng)到 TiKV 的呢？

在 TiDB 里面，任何一張表都有一個(gè)唯一的 ID，譬如這里是 11，任何的索引也有唯一的 ID，上面 name 就是 12，age 就是 13。我們使用前綴 t 和 i 來(lái)區(qū)分表里面的 data 和 index。對(duì)于上面表 t1 來(lái)說(shuō)，假設(shè)現(xiàn)在它有兩行數(shù)據(jù)，分別是 (1, “a”, 10, “hello”) 和 (2, “b”, 12, “world”)，在 TiKV 里面，每一行數(shù)據(jù)會(huì)有不同的 key-value 對(duì)應(yīng)。如下：

PK
t_11_1 -> (1, “a”, 10, “hello”)
t_11_2 -> (2, “b”, 12, “world”)

Unique Name
i_12_a -> 1
i_12_b -> 2

Index Age
i_13_10_1 -> nil
i_13_12_2 -> nil

因?yàn)?PK 具有唯一性，所以我們可以用 t + Table ID + PK 來(lái)唯一表示一行數(shù)據(jù)，value 就是這行數(shù)據(jù)。對(duì)于 Unique 來(lái)說(shuō)，也是具有唯一性的，所以我們用 i + Index ID + name 來(lái)表示，而 value 則是對(duì)應(yīng)的 PK。如果兩個(gè) name 相同，就會(huì)破壞唯一性約束。當(dāng)我們使用 Unique 來(lái)查詢(xún)的時(shí)候，會(huì)先找到對(duì)應(yīng)的 PK，然后再通過(guò) PK 找到對(duì)應(yīng)的數(shù)據(jù)。

對(duì)于普通的 Index 來(lái)說(shuō)，不需要唯一性約束，所以我們使用 i + Index ID + age + PK，而 value 為空。因?yàn)?PK 一定是唯一的，所以?xún)尚袛?shù)據(jù)即使 age 一樣，也不會(huì)沖突。當(dāng)我們使用 Index 來(lái)查詢(xún)的時(shí)候，會(huì)先 seek 到第一個(gè)大于等于 i + Index ID + age 這個(gè) key 的數(shù)據(jù)，然后看前綴是否匹配，如果匹配，則解碼出對(duì)應(yīng)的 PK，再?gòu)?PK 拿到實(shí)際的數(shù)據(jù)。

TiDB 在操作 TiKV 的時(shí)候需要保證操作 keys 的一致性，所以需要使用 TxnKV 模式。

上面簡(jiǎn)單的介紹了下 TiKV 讀寫(xiě)數(shù)據(jù)的流程，還有很多東西并沒(méi)有覆蓋到，譬如錯(cuò)誤處理，Percolator 的性能優(yōu)化這些，如果你對(duì)這些感興趣，可以參與到 TiKV 的開(kāi)發(fā)，歡迎聯(lián)系我 [email protected]。