上週我們推送了 TiDB 團隊職位解讀文章，當天就有很多簡歷砸來，我們深深感受到了小夥伴們的熱情～ 趁熱打鐵，今天我司首席架構師唐劉老師將帶大家瞭解一下傳說中「面試通過率最低、難度最高」的研發團隊——TiKV 團隊。
Team 簡介
我們 Team 主要負責 TiKV 的研發工作，下圖是我們產品的架構圖，大家可以看到，無論是 TiDB 還是 TiSpark，都是從 TiKV 存取資料的，所以我們一定要保證 TiKV 的穩定和高效。
在我們官網招聘頁面，TiKV 研發工程師的崗位職責就兩個：
-
負責分散式資料庫 TiKV 相關的設計，開發。
-
負責構建分散式壓力測試框架，穩定性測試框架。
是不是特別簡單？說實話，我們也想好好寫清楚，但無奈 TiKV 這邊要做的事情實在是太多，所以這裡我會詳細介紹一下。
TiKV 研發工程師職位資訊：
TiKV 簡介
TiKV 是一個支援事務的、資料強一致的分散式 Key-Value 資料庫。也許有人會說，造一個 Key-Value 資料庫有啥難的，我不這麼認為，因為造一個工業級、通用的、有超高效能的 Key-Value，真的是一件很難的事情。而且這個 Key-Value 資料庫上面還加了很多限定詞來修飾，要支援這些特性就更難了。下面我會一個一個的自底向上來說明 TiKV 是如何實現這些特性的。
TiKV 採用分層架構設計，這樣的好處在於各個模組特性都是獨立解耦合的，大家可以專注於某一層的研究和開發。但同時，這些獨立的模組最終會形成 TiKV 這一個整體。所以我們內部還是會希望大家不只侷限於某一個單一模組，而是要儘可能地精通多個模組，如果你是一個典型的自我驅動力很強的人，那麼你在 TiKV 團隊就能快速成長起來！
Storage
作為一個 Key-Value 儲存系統，最底層當然是考慮如何去儲存 Key-Value 了。在這裡，我們並沒有發揚程式設計師「自己造輪子」這種光榮的優良傳統，而是直接使用 RocksDB。主要原因就在於 RocksDB 已經足夠好，我們短時間造一個還真不可能比它強。與其冒風險花很長時間去弄一個自己的底層 Key-Value，還不如基於 RocksDB 來更加穩妥和保險。
但我們並不只是單純的使用 RocksDB，在 RocksDB 這邊，我們需要：
-
原始碼級別的精通 RocksDB。也就是我們在使用 RocksDB 的時候遇到了任何問題，我們都可以幫助 RocksDB Team 去 fix。之前我們已經幫 RocksDB Team fix 了幾個嚴重的 bug 了。
-
調優 RocksDB。RocksDB 雖然上手簡單，但裡面那一堆的引數，你要把它們給折騰好，適配到不同的機型，也是一個困難的事情，這塊就不光要求你對 RocksDB 非常熟悉，也需要對作業系統有很深入的瞭解。後面，我們的目標是能做到自動調優 RocksDB。
-
Titan。今年我們已經開始給 RocksDB 定製一個新的 engine，叫做 Titan，這個 engine 主要是用的 KV 分離的思想，將大的 value 從 LSM-Tree 裡面移除，減少寫放大。
-
基於 Intel 下一代硬體 AEP 的 RocksDB 優化。硬體一直在以超過我們想象的速度發展，當我們還在糾結如何優化 SSD 的時候，基於 NVM 的程式設計已經在興起了，但現在很多的 NVM 環境都是基於模擬器的，而我們手上則有實際的 Intel AEP 盤。現在，我們正在跟 Intel 合作以及某高校合作，一起在 AEP 上面對 RocksDB 進行優化。
當然，在 storage 層面，我們還要做的更多，現在我們正在做抽象 storage API 的工作，當這個完成之後，TiKV 就能支援不同的儲存引擎，譬如使用 LevelDB，WiredTiger 等等，或者你自己用 Rust 寫一個 pure engine 也可以。但我覺得更令人激動的是，我們內部正在基於這種方式，讓 TiKV 直接對接自研的 AP 引擎，這樣我們就能實現真正意義上面的行列混存，這是一個非常有挑戰性的工作，歡迎大家加入。
Raft
上面說完了儲存引擎方面的工作，但這些只能解決單個機器資料儲存的問題，作為一個分散式系統，我們必須要將資料複製到多個機器上面，保證資料的安全。這裡，我們就要使用分散式一致性演算法了。分散式一致性演算法，現在無非就是兩類，Paxos 和 Raft，我們選擇了 Raft。
Raft 協議比較簡單。但實話，如果真的要做一個工業級別高效能的 Raft 實現，難度還是非常大的，我們已經做了很多的優化，但還有很多工作要做，主要包括：
-
Joint consensus，安全的成員變更。當我們要進行叢集擴容縮容的時候，採用的是每次變更一個節點的做法，但這個方式在一些情況下會有 corner case 問題。所以更好的方式就是 Raft 裡面提到的 Joint consensus。
-
Follower snapshot。當一個新節點加入叢集之後，通常都是 Leader 給這個新的節點傳送 snapshot，但這樣其實會造成 Leader 的壓力比較大（因為 Leader 同時要處理客戶端的讀寫請求），所以一種可行的做法就是讓其 follower 給這個新的節點傳送 snapshot，等新的節點接受完了 snapshot，Leader 才會傳送 logs。
-
不對等網路環境的優化。現在我們遇到了很多使用者，都是兩地三中心的架構，也就是同城有兩個 IDC，而異地有一個 IDC，所以這幾個 IDC 之間網路環境是不對等的。但原生的 Raft 其實並沒有考慮如何處理這樣的情況， 我們考慮的做法是給節點設定 priority，只有高 priority 的 node 才能發起選舉。或者考慮只能投票節點，這些節點不會存有實際的資料，只有 Raft 的原資訊，用來投票。
-
Learner backup/restore/replication。對於一個分散式叢集來說，如何高效的對整個叢集進行備份，恢復以及支援實時複製是一件非常困難的事情，我們後續準備通過 Raft Learner 機制來做這個事情。通過 Raft 自帶的 snapshot 以及 Log replication 機制，將資料備份到其他地方，譬如 S3，Ceph 等。
Transaction
TiKV 採用 Google Percolator 模型來實現分散式事務，但現在我們的實現還有很多可以做的地方，主要如下：
-
Timestamp 的獲取。一次事務，會從 PD 獲取兩次時間戳，雖然獲取時間戳的速度很快，但畢竟還是有網路開銷。我們可以通過一些方式，只從 PD 拿一次時間戳，也可能會考慮其他授時方案。
-
跟 Raft 整合，延遲 apply。現在一次寫入，會在 Raft 上面生成兩個 log，第一個 log 包含的是 Prewrite，而第二個則是 Commit，而我們都會把這兩個 log apply 到狀態機，但實際在處理 Prewrite 的時候，我們可以延遲 apply，等真正碰到對應的 Commit 再一起處理。
-
跟引擎的結合。如何高效的讓事務跟底層引擎結合起來，讓事務處理的更快，也是一個需要考慮的問題。譬如在 RocksDB 裡面如何高效的獲取特定版本的資料，或者掃描的時候如何快速的過濾掉不需要的資料，都是不小的挑戰。
-
衝突事務的優化。現在的事務模型採用樂觀鎖機制，其實對衝突事務不友好，我們也需要對其進行優化。
Coprocessor
Coprocessor 主要是為了支援 TiDB 和 TiSpark 的下推操作，隨著越來越多的下推函式推到 Coprocessor 去執行，Coprocessor 就要做更多的事情了，主要包括：
-
支援更多的 Push 函式。這個其實就是將 TiDB 和 TiSpark 需要支援的函式實現。雖然看起來是一個辛苦活，但這對於個人克服 Rust 語言學習上的困難、快速參與 TiKV 開發，幫助都是非常大的。
-
資源隔離。對於查詢語句，從 TP 發上來的和從 AP 發上來的我們的關注度是不一樣的。同時我們也需要保證 AP 的大查詢不能將整個系統資源給耗盡，影響到 TP 的操作。
-
查詢的提速。譬如返回更多的 hint 給 TiDB 的優化器，用來調優後面的查詢。
-
特定查詢的優化。現在所有的查詢都是走的統一的框架，生成一個 AST，依次執行，但實際對於一些特定查詢，譬如 select count(*)，我們完全可以將 AST 壓扁，讓其直接跟 engine 互動，得到資料，快速返回。
-
向量化支援。這是一個比較複雜的工程，涵蓋了一系列優化，其核心是以列向量為單位進行計算。向量化通過一次性計算一批資料，改進了 Cache Locality 並更好地利用流水線，從而極大地提高計算速度。未來甚至還可以在此基礎上實現指令級向量化——SIMD。
排程
當你的叢集有幾百臺機器，有非常多的資料的時候，排程的作用就非常明顯了。如果排程設計的不好，很容易導致整個叢集效能的抖動，甚至把叢集搞得完全沒法工作。所以，排程也是 TiKV 裡面非常重要的工作。在 TiKV 裡面，我們需要考慮：
-
不同 workload 下面的排程。譬如如果出現了熱點，排程器需要快速的檢測出來，並且將熱點的請求分散到不同的節點，分散壓力。
-
模擬器。如何驗證我們的排程程式正常工作？唯一的方法就是測試，但每次測試都搭建叢集，插入非常多的資料，其實非常的麻煩，所以我們需要通過模擬器來簡化這些事情。
-
視覺化。除了通過模擬器，另一個檢視排程是否正常的辦法就是視覺化，我們會將整個排程的過程展示出來，通過視覺化就能知道叢集是否在正常工作。
Performance and Test
上面說了一些重要模組需要做的工作，對於 TiKV 來說，還有兩個非常重要的地方，是我們非常關注的，就是效能和測試。這兩塊其實算是比較通用的，會涉及到所有的模組，主要是：
-
對各個模組進行效能測試，得到各模組的效能極限，為後面的效能優化提供指導。
-
對各個模組進行詳細的測試，使用 failpoint 等對系統進行注入測試。
-
實踐 Chaos，對系統進行大規模長時間的穩定性測試。
-
使用 TLA+ 驗證系統設計的正確性。
-
設計並實現效能迴歸測試平臺。任何提交，我們都能非常方便的知道與之前版本的效能對比，知道這次提交到底在哪些地方影響了效能。
-
使用 Jepsen 和 Porcupine 等驗證系統的線性一致性。
-
作業系統的調優，包括 IO，network 等。
除了寫程式碼，你能做的還有這些……
盡情的用文字來抒發你的想法
在 TiKV team，我們非常鼓勵大家將自己做的東西通過文字表達出來。你可以參與《TiKV 原始碼解析系列》文章，讓大家能通過你的文章深入的理解程式碼，也可以參與《Deep Dive TiKV 系列》文章，讓大家理解為什麼我們要這麼設計系統，它背後的原理到底是什麼。
參與 Talent Plan 專案
作為一個開源專案，我們需要通過自己的努力來回饋開源社群。我們會提供 Rust 培訓課程，也會提供分散式系統學習課程，讓大家能通過在網上自學就能用 Rust 來構建一個高可用的分散式專案。
成為佈道師
我們非常鼓勵大家出去佈道。你可以參加我們各地 Office 定期舉辦的 Meetup，也可以去知名的公司進行技術交流，我們也會提供機會讓你在國內知名的會議上演講。對於優秀的同學，我們還提供參加國外 Meetup 的機會。
瞭解如何運營一個國際化的開源專案
TiKV 作為 CNCF 的專案，無論在國內，還是海外，都有很多朋友關注，並且給我們貢獻程式碼。你需要跟眾多的開發者一起交流協作，共同完善整個專案。
Team 成員有話說
“從理論到實踐，從入門到熟練，TiKV 團隊完善的培養計劃讓我快速成長。新的挑戰每天都有，新的技能樹每週都能開啟，在這讓我有一種回到學校的感覺，能和大家一起進步，真好！”
—— Overvenus
“在 PingCAP TiKV 團隊，你不僅可以和各種大牛甚至語言創始者共同協作、開發、學習、進步，更重要的是，在掌握基礎之後你可以非常自由地選擇自己感興趣的部分來改進 TiKV 這個產品。在這個過程中你可以由自己來設計一切並逐步將它打造出來。相信這種自己當 PM、自己來設計、自己來實現的開發方式能帶給你全新的體驗。”
—— Breeswish
“在這裡你可以零距離接觸一個分散式儲存引擎的所有細節，並提出自己的改進、優化建議，快來一起享受寫資料庫的浪漫吧！”
—— Hicqu
“這裡有很多聰明能幹的小夥伴一起成長，有來自世界各地的 Rust 社群大佬，更有老司機們指路護航。工作即富有挑戰又自由有趣，越來越多的深水區等待你的挖掘，快來打造你理想中的資料庫吧！”
—— Nolouch
我們的要求
最後來說說要求吧，畢竟招人就像是相親，總得有個門檻的。
抗壓能力
公司目前還處在創業階段，壓力是不可避免的，而且現在我們使用者特多（尤其是網際網路頭部使用者），這就要求大家必須具備一定的抗壓能力。
知識背景
需要有分散式開發經驗，至少 CAP，Raft 這些基礎概念是需要了解的。當然，如果你有排程系統的開發經驗，折騰過 Kubernetes，Mesos 等東西，那就更好了。
語言方面我們主要會使用 Go 和 Rust
如果沒有這兩門語言的開發經驗，有 C、Python 相關經驗也沒問題。當然，Rust 可能對一些同學是一個坎，就看你能不能克服了，畢竟這門語言實在太難上手了。
當然，我們也非常歡迎實習生。對於想來實習的同學，你只要覺得自己主動性強，肯學習，能寫程式碼就可以了。我們有時候也直接會讓實習生去解決使用者問題，雖然會很有挑戰，但能讓你快速成長。
加入我們吧！
我們認為優秀的工程師或多或少有以下共同特質：
-
A Quick Learner
-
An Earnest Curiosity
-
Faith in Open Source
-
Self-driven
-
Get Things Done
如果你符合以上特質，歡迎進入招聘頁面檢視目前開放的工作機會：
簡歷投遞通道：hire@pingcap.com
實習生：公司的各項福利和學習資源對實習生全面開放，更重要的是實習生還未畢業就有機會接觸工業級專案，而且實習期間表現優異者將有機會獲得校招綠色通道特權。如果小夥伴們時間不夠充裕，也可以先從社群 Contributor 做起，或許下一期 Talent Plan 的主角就是你！
伯樂推薦：如果你身邊有符合以上要求的小夥伴，也可以找我們聊一聊，推薦成功就有機會獲得伯樂推薦獎勵（iPad、iPhone、MacBook Pro 等等）。伯樂推薦郵件格式：[伯樂推薦] 候選人姓名-職位名稱-推薦人姓名-推薦人手機號。
