上周寫了一篇 PD 的招聘廣告，想想還是應(yīng)該寫一下 TiKV一也，畢竟誰叫 TiKV 也缺人了。這里风纠，我仍然會(huì)詳細(xì)的說明 TiKV 主要是干啥的蚯斯，以及我們要做的事情薄风，這樣你大概就知道我們做的東西靠不靠譜，愿不愿意參與了拍嵌。
在我們官網(wǎng)上面遭赂，TiKV 的招聘職責(zé)就兩個(gè)：
- 負(fù)責(zé)分布式數(shù)據(jù)庫 TiKV 相關(guān)的設(shè)計(jì)，開發(fā)
- 負(fù)責(zé)構(gòu)建分布式壓力測(cè)試框架撰茎，穩(wěn)定性測(cè)試框架
看起來是不是一臉懵逼嵌牺，這是啥打洼。實(shí)話龄糊，我其實(shí)也想好好的寫清楚，但無奈 TiKV 這邊要做的事情實(shí)在是太多募疮，只能這里慢慢嘮叨了炫惩。
TiKV 簡介
TiKV 是一個(gè)支持事務(wù)的，數(shù)據(jù)強(qiáng)一致的分布式 Key-Value 數(shù)據(jù)庫阿浓。也許有人會(huì)說他嚷，造一個(gè) Key-Value 數(shù)據(jù)庫有啥難的，我不這么認(rèn)為芭毙，因?yàn)樵煲粋€(gè)工業(yè)級(jí)筋蓖，通用的，有超高性能的 Key-Value 真的是一件很難的事情退敦。而且這個(gè) Key-Value 數(shù)據(jù)庫上面還加了很多限定詞來修飾粘咖，要支持這些特定就更難了。后面我會(huì)一個(gè)一個(gè)的自底向上來說明 TiKV 是如何實(shí)現(xiàn)這些特性的侈百。
TiKV 采用分層架構(gòu)設(shè)計(jì)瓮下，這樣好處在于各個(gè)模塊特性都是獨(dú)立解耦合的，大家可以專注于某一層的研究和開發(fā)钝域。但同時(shí)讽坏，這些獨(dú)立的模塊最終會(huì)形成 TiKV 這一個(gè)整體。所以我們內(nèi)部還是會(huì)要求大家不光僅僅局限于一層例证，而是要能精通多個(gè)模塊路呜，所以在 TiKV，你的壓力會(huì)很大，但如果你是一個(gè)典型的自我驅(qū)動(dòng)力很強(qiáng)的人胀葱，你會(huì)在這邊快速的成長党涕。
Storage
作為一個(gè) Key-Value 存儲(chǔ)系統(tǒng)，最底層當(dāng)然是考慮如何去存儲(chǔ) Key-Value 了巡社。在這里膛堤，我們并沒有發(fā)揚(yáng)程序員的『擼起袖子自己造輪子』這種光榮的優(yōu)良傳統(tǒng)，而是直接使用 RocksDB晌该。主要原因就在于 RocksDB 已經(jīng)足夠好肥荔，我們短時(shí)間造一個(gè)還真不可能比它強(qiáng)。與其冒風(fēng)險(xiǎn)花很長時(shí)間去弄一個(gè)自己的底層 Key-Value朝群，還不如基于 RocksDB 來更加穩(wěn)妥和保險(xiǎn)燕耿。
但我們并不只是單純的使用 RocksDB，如果我們這邊就只是用 RocksDB 的 API姜胖，那我也不好意思在這里寫下去了誉帅。在 RocksDB 這邊，我們需要：
- 源碼級(jí)別的精通 RocksDB右莱，也就是我們?cè)谑褂?RocksDB 的時(shí)候遇到了任何問題蚜锨，我們都可以幫助 RocksDB Team 去 fix。去年我們已經(jīng)幫 RocksDB Team fix 了幾個(gè)嚴(yán)重的丟數(shù)據(jù) bug 了慢蜓。
- 調(diào)優(yōu) RocksDB亚再，RocksDB 雖然上手簡單，但里面那一堆的參數(shù)晨抡，你要把它們給折騰好氛悬，適配到不同的機(jī)型，也是一個(gè)困難的事情耘柱，這塊就不光要求你對(duì) RocksDB 非常熟悉如捅，也需要對(duì)操作系統(tǒng)有很深入的了解了。
- 增強(qiáng) RocksDB调煎，我們今年會(huì)跟 RocksDB 社區(qū)一起合作镜遣，參與 BlobDB 的開發(fā)，也不排除會(huì)參與到其他一些 feature 的開發(fā)汛蝙，但這些 feature 我們也會(huì)爭(zhēng)取 merge 到 RocksDB 的主干烈涮。
當(dāng)然，引擎不光只有 RocksDB窖剑，在一些特定場(chǎng)景坚洽，譬如 Raft log，我們會(huì)考慮使用自己的存儲(chǔ)引擎西土，畢竟這些場(chǎng)景都比較簡單讶舰，寫一個(gè)定制的性能會(huì)好很多，而且難度也不大。
Raft
上面說了存儲(chǔ)引擎跳昼，但這個(gè)只能解決單個(gè)機(jī)器數(shù)據(jù)存儲(chǔ)的問題般甲，作為一個(gè)分布式系統(tǒng)，我們必須要將數(shù)據(jù)復(fù)制到多個(gè)機(jī)器上面鹅颊，保證數(shù)據(jù)的安全敷存。這里，我們就要使用分布式一致性算法了堪伍。分布式一致性算法锚烦，現(xiàn)在無非就是兩類，Paxos 和 Raft帝雇，我們選擇了 Raft涮俄。至于 Raft 的介紹，我之前寫過了很多尸闸，包括小豬佩奇系列彻亲，這里就不多說了。
也許你要說吮廉，光一個(gè) Raft苞尝，這么簡單，還要做啥茧痕。但實(shí)話野来，要做的東西多著了：
- PreVote 特性的支持。大家知道踪旷，在 Raft 里面，只要一個(gè)節(jié)點(diǎn)被隔離出去豁辉，在重新回到集群的時(shí)候令野，就可能講 Leader 下線，集群就要重新選舉徽级。為了緩解這個(gè)問題气破，需要 PreVote，但這個(gè)特性現(xiàn)在我們是沒有的餐抢。
- Joint consensus现使，安全的成員變更。當(dāng)我們要進(jìn)行集群擴(kuò)容縮容的時(shí)候旷痕，采用的是每次變更一個(gè)節(jié)點(diǎn)的做法碳锈，但這個(gè)方式在一些情況下面會(huì)有 corner case 問題。所以更好的方式就是 Raft 里面提到的 Joint consensus欺抗。另一個(gè)可選的方式就是支持 Replace Node 命令售碳，但也需要處理一些 corner case。
- Multi Raft。光一個(gè) Raft 是不可能承載這么多數(shù)據(jù)的贸人，所以我們一定要支持多 Raft 集群间景，這里就要關(guān)心 Raft Group 如何分裂成多個(gè) Group，同時(shí)這些 Group 又如何合并成一個(gè) Group艺智。另外當(dāng)有很多 Group 之后倘要，對(duì)于長時(shí)間沒有工作的 Group，我們?nèi)绾谓档退鼈兊臋?quán)重十拣，讓它們靜默不占用資源碗誉。這些問題，在數(shù)據(jù)量變的特大之后父晶，都是一個(gè)非常嚴(yán)峻的考驗(yàn)哮缺。
- Huge Raft Group。現(xiàn)在我們的 Raft Group 是 96 MB 的甲喝，預(yù)計(jì)我們會(huì)逐漸調(diào)大尝苇，可能會(huì)到 GB 級(jí)別。這樣埠胖，對(duì)于 Raft 副本的遷移糠溜，以及在這個(gè) Raft 對(duì)應(yīng)的狀態(tài)機(jī)上面的數(shù)據(jù)操作，都需要有更優(yōu)化的考量了直撤。
Transaction
TiKV 是支持分布式事務(wù)的非竿，雖然我們有 Raft，但也只能保證一個(gè) Raft 里面數(shù)據(jù)的一致性問題谋竖，如果外面的一個(gè)操作涉及到多個(gè) Raft 了红柱，那么就需要使用分布式事務(wù)來保證數(shù)據(jù)的一致性了。
通用的分布式事務(wù)實(shí)現(xiàn)方式就是 2 PC蓖乘，TiKV 采用的是 Google Percolator 模型的〈盖模現(xiàn)在 TiKV 的事務(wù)還有很多事情要做：
- 穩(wěn)定性。分布式事務(wù)的正確性是我們首要保證的嘉抒，如果你的事務(wù)實(shí)現(xiàn)不能滿足 ACID 特定零聚，那么根本不能用到用戶的核心系統(tǒng)上面。所以我們需要做非常多的測(cè)試來驗(yàn)證我們的事務(wù)實(shí)現(xiàn)是正確的些侍。
- TSO隶症。我在之前的文章中寫過我們跟 Percolator 一樣使用的是 TSO，但對(duì)于 Go 程序來說岗宣，一些 goroutine 調(diào)度等就可能造成獲取 TSO 變慢蚂会，所以我們也考慮優(yōu)化這塊，不排除以后整合 TSO 和 HLC狈定。
- 沖突事務(wù)的優(yōu)化颂龙。Percolator 使用的是樂觀事務(wù)习蓬，所以對(duì)于沖突事務(wù)其實(shí)性能并不好。對(duì)于這種情況措嵌，我們可以考慮引入悲觀鎖等機(jī)制來優(yōu)化躲叼。
- 跟引擎的結(jié)合。如何高效的讓事務(wù)跟底層引擎結(jié)合起來企巢，讓事務(wù)處理的更快枫慷，也是一個(gè)需要考慮的問題。譬如如何在 RocksDB 里面如何高效的獲取特定版本的數(shù)據(jù)浪规，或者掃描的時(shí)候如何快速的過濾掉不需要的數(shù)據(jù)或听，都是不小的挑戰(zhàn)。
gRPC
TiKV 現(xiàn)在的網(wǎng)絡(luò)框架采用的 gRPC笋婿，關(guān)于 gRPC誉裆，之前也說了很多支持它的血淚史，但現(xiàn)在我們也僅僅限于支持了缸濒，還有很多東西要做：
- 性能提升足丢。gRPC 現(xiàn)在對(duì) CPU 的要求還是比較高，為了減少 CPU 的開銷庇配，我們需要更加深入的了解 gRPC 代碼斩跌，所以這里也需要源碼級(jí)別的精通 gRPC，知道 HTTP/2捞慌，以及 gRPC 是如何實(shí)現(xiàn)的耀鸦。
- 網(wǎng)絡(luò)工具。有時(shí)候我們遇到的一些網(wǎng)絡(luò)問題啸澡，需要快速的定位袖订，但現(xiàn)在其實(shí)缺少 gRPC 相關(guān)的工具。當(dāng)然锻霎，一個(gè)做法是用 tcpdump 抓包著角，然后在弄出來使用 Wireshark 來進(jìn)行分析，但這樣畢竟不高效旋恼，如果能有自己的工具來對(duì)整個(gè) gRPC 鏈路進(jìn)行分析處理，會(huì)更好奄容。
- Rust gRPC ecosystem冰更。在 Go 里面，我們可以使用 go 的 gRPC ecosystem 來方便的將 gRPC 跟其他系統(tǒng)昂勒，譬如 OpenTracing蜀细，Prometheus 這些整合，但 Rust 這邊要做的工作還有非常多戈盈。
Coprocessor
Coprocessor 的主要是為了支持 TiDB 和 TiSpark 的下推操作奠衔，這里簡單說一下要做的事情：
- 支持更多的 Push 函數(shù)谆刨，這個(gè)其實(shí)就是將 TiDB 和 TiSpark 需要支持的函數(shù)實(shí)現(xiàn)。雖然看起來是一個(gè)辛苦活归斤，但這個(gè)對(duì)克服 Rust痊夭，快速參與 TiKV 開發(fā)，幫助都是非常大的脏里。
- 資源隔離她我。對(duì)于不同的查詢語句，TP 發(fā)上來的和 AP 發(fā)上來的我們的關(guān)注度是不一樣的迫横，同時(shí)我們也需要保證 AP 的大查詢不能將整個(gè)系統(tǒng)資源給耗盡番舆，影響到 TP 的操作。
- 查詢的提速矾踱，譬如返回更多的 hint 給 TiDB 的優(yōu)化器恨狈，用來調(diào)優(yōu)后面的查詢。
Performance and Test
上面說了一些重要模塊需要做的工作呛讲，對(duì)于 TiKV 來說禾怠，還有兩個(gè)非常重要的地方，是我們非常關(guān)注的圣蝎，就是性能和測(cè)試刃宵。這兩塊其實(shí)算是比較通用的，會(huì)涉及到所有的模塊徘公，主要是：
- 對(duì)各個(gè)模塊進(jìn)行性能測(cè)試牲证，得到各模塊的性能極限，為后面的性能優(yōu)化提供指導(dǎo)关面。
- 對(duì)各個(gè)模塊進(jìn)行詳細(xì)的測(cè)試坦袍，使用 failpoint 等對(duì)系統(tǒng)進(jìn)行注入測(cè)試。
- 實(shí)踐 Chaos等太，對(duì)系統(tǒng)進(jìn)行大規(guī)模長時(shí)間的穩(wěn)定性測(cè)試捂齐。
- 使用 TLA+ 驗(yàn)證系統(tǒng)設(shè)計(jì)的正確性。
- 設(shè)計(jì)并實(shí)現(xiàn)性能回歸測(cè)試平臺(tái)缩抡，任何提交奠宜，我們都能非常方便的知道跟之前版本的性能對(duì)比這些的，知道這次提交到底在那些地方影響了性能瞻想。
- 使用 Jepsen 和 Porcupine 等驗(yàn)證系統(tǒng)的線性一致性压真。
- 操作系統(tǒng)的調(diào)優(yōu)，包括 IO蘑险，network 等滴肿。
因?yàn)樾阅芎蜏y(cè)試涉及到的東西太多，這里就不一一列舉了佃迄。
小結(jié)
因?yàn)橹耙呀?jīng)在 PD 那邊文章里面說到了為啥要加入我們泼差，這里就不重復(fù)了贵少。只是想在強(qiáng)調(diào)一次，在 TiKV堆缘，你的個(gè)人能力會(huì)得到極大的提升滔灶，因?yàn)槟阋龅氖虑檎娴氖翘刑魬?zhàn)了。
要求其實(shí)跟 PD 那邊的也差不多套啤，畢竟 TiKV 其實(shí)跟 PD 是一起的宽气，你也可以都要去開發(fā)。但 TiKV 這邊對(duì) Rust 語言要求會(huì)更高一點(diǎn)潜沦，你必須要克服 Rust 這個(gè)門檻萄涯。
好了，說了這么多唆鸡，相信你也對(duì)我們有所了解了涝影，你可以先去了解下 TiKV，代碼在 https://github.com/pingcap/tikv争占，歡迎給我們提 issue 和 PR燃逻。
如果你對(duì)我們感興趣，歡迎聯(lián)系我臂痕，直接發(fā)郵箱到 tl@pingcap.com 就可以了伯襟。
