上週咱們推送了 TiDB 團隊職位解讀文章,當天就有不少簡歷砸來,咱們深深感覺到了小夥伴們的熱情~ 趁熱打鐵,今天我司首席架構師唐劉老師將帶你們瞭解一下傳說中「面試經過率最低、難度最高」的研發團隊——TiKV 團隊。node
咱們 Team 主要負責 TiKV 的研發工做,下圖是咱們產品的架構圖,你們能夠看到,不管是 TiDB 仍是 TiSpark,都是從 TiKV 存取數據的,因此咱們必定要保證 TiKV 的穩定和高效。ios
在咱們官網招聘頁面,TiKV 研發工程師的崗位職責就兩個:程序員
負責分佈式數據庫 TiKV 相關的設計,開發。面試
負責構建分佈式壓力測試框架,穩定性測試框架。算法
是否是特別簡單?說實話,咱們也想好好寫清楚,但無奈 TiKV 這邊要作的事情實在是太多,因此這裏我會詳細介紹一下。數據庫
TiKV 研發工程師職位信息:編程
https://pingcap.com/recruit-cn/engineering/tikv-engineer/安全
TiKV 是一個支持事務的、數據強一致的分佈式 Key-Value 數據庫。也許有人會說,造一個 Key-Value 數據庫有啥難的,我不這麼認爲,由於造一個工業級、通用的、有超高性能的 Key-Value,真的是一件很難的事情。並且這個 Key-Value 數據庫上面還加了不少限定詞來修飾,要支持這些特性就更難了。下面我會一個一個的自底向上來講明 TiKV 是如何實現這些特性的。性能優化
TiKV 採用分層架構設計,這樣的好處在於各個模塊特性都是獨立解耦合的,你們能夠專一於某一層的研究和開發。但同時,這些獨立的模塊最終會造成 TiKV 這一個總體。因此咱們內部仍是會但願你們不僅侷限於某一個單一模塊,而是要儘量地精通多個模塊,若是你是一個典型的自我驅動力很強的人,那麼你在 TiKV 團隊就能快速成長起來!網絡
做爲一個 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 引擎,這樣咱們就能實現真正意義上面的行列混存,這是一個很是有挑戰性的工做,歡迎你們加入。
上面說完了存儲引擎方面的工做,但這些只能解決單個機器數據存儲的問題,做爲一個分佈式系統,咱們必需要將數據複製到多個機器上面,保證數據的安全。這裏,咱們就要使用分佈式一致性算法了。分佈式一致性算法,如今無非就是兩類,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 等。
TiKV 採用 Google Percolator 模型來實現分佈式事務,但如今咱們的實現還有不少能夠作的地方,主要以下:
Timestamp 的獲取。一次事務,會從 PD 獲取兩次時間戳,雖然獲取時間戳的速度很快,但畢竟仍是有網絡開銷。咱們能夠經過一些方式,只從 PD 拿一次時間戳,也可能會考慮其餘授時方案。
跟 Raft 整合,延遲 apply。如今一次寫入,會在 Raft 上面生成兩個 log,第一個 log 包含的是 Prewrite,而第二個則是 Commit,而咱們都會把這兩個 log apply 到狀態機,但實際在處理 Prewrite 的時候,咱們能夠延遲 apply,等真正碰到對應的 Commit 再一塊兒處理。
跟引擎的結合。如何高效的讓事務跟底層引擎結合起來,讓事務處理的更快,也是一個須要考慮的問題。譬如在 RocksDB 裏面如何高效的獲取特定版本的數據,或者掃描的時候如何快速的過濾掉不須要的數據,都是不小的挑戰。
衝突事務的優化。如今的事務模型採用樂觀鎖機制,其實對衝突事務不友好,咱們也須要對其進行優化。
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 下面的調度。譬如若是出現了熱點,調度器須要快速的檢測出來,而且將熱點的請求分散到不一樣的節點,分散壓力。
模擬器。如何驗證咱們的調度程序正常工做?惟一的方法就是測試,但每次測試都搭建集羣,插入很是多的數據,其實很是的麻煩,因此咱們須要經過模擬器來簡化這些事情。
可視化。除了經過模擬器,另外一個查看調度是否正常的辦法就是可視化,咱們會將整個調度的過程展現出來,經過可視化就能知道集羣是否在正常工做。
上面說了一些重要模塊須要作的工做,對於 TiKV 來講,還有兩個很是重要的地方,是咱們很是關注的,就是性能和測試。這兩塊其實算是比較通用的,會涉及到全部的模塊,主要是:
對各個模塊進行性能測試,獲得各模塊的性能極限,爲後面的性能優化提供指導。
對各個模塊進行詳細的測試,使用 failpoint 等對系統進行注入測試。
實踐 Chaos,對系統進行大規模長時間的穩定性測試。
使用 TLA+ 驗證系統設計的正確性。
設計並實現性能迴歸測試平臺。任何提交,咱們都能很是方便的知道與以前版本的性能對比,知道此次提交到底在哪些地方影響了性能。
使用 Jepsen 和 Porcupine 等驗證系統的線性一致性。
操做系統的調優,包括 IO,network 等。
在 TiKV team,咱們很是鼓勵你們將本身作的東西經過文字表達出來。你能夠參與《TiKV 源碼解析系列》文章,讓你們能經過你的文章深刻的理解代碼,也能夠參與《Deep Dive TiKV 系列》文章,讓你們理解爲何咱們要這麼設計系統,它背後的原理究竟是什麼。
做爲一個開源項目,咱們須要經過本身的努力來回饋開源社區。咱們會提供 Rust 培訓課程,也會提供分佈式系統學習課程,讓你們能經過在網上自學就能用 Rust 來構建一個高可用的分佈式項目。
咱們很是鼓勵你們出去佈道。你能夠參加咱們各地 Office 按期舉辦的 Meetup,也能夠去知名的公司進行技術交流,咱們也會提供機會讓你在國內知名的會議上演講。對於優秀的同窗,咱們還提供參加國外 Meetup 的機會。
TiKV 做爲 CNCF 的項目,不管在國內,仍是海外,都有不少朋友關注,而且給咱們貢獻代碼。你須要跟衆多的開發者一塊兒交流協做,共同完善整個項目。
「從理論到實踐,從入門到熟練,TiKV 團隊完善的培養計劃讓我快速成長。新的挑戰天天都有,新的技能樹每週都能開啓,在這讓我有一種回到學校的感受,能和你們一塊兒進步,真好!」
—— Overvenus
「在 PingCAP TiKV 團隊,你不只能夠和各類大牛甚至語言創始者共同協做、開發、學習、進步,更重要的是,在掌握基礎以後你能夠很是自由地選擇本身感興趣的部分來改進 TiKV 這個產品。在這個過程當中你能夠由本身來設計一切並逐步將它打造出來。相信這種本身當 PM、本身來設計、本身來實現的開發方式能帶給你全新的體驗。」
—— Breeswish
「在這裏你能夠零距離接觸一個分佈式存儲引擎的全部細節,並提出本身的改進、優化建議,快來一塊兒享受寫數據庫的浪漫吧!」
—— Hicqu
「這裏有不少聰明能幹的小夥伴一塊兒成長,有來自世界各地的 Rust 社區大佬,更有老司機們指路護航。工做即富有挑戰又自由有趣,愈來愈多的深水區等待你的挖掘,快來打造你理想中的數據庫吧!」
—— Nolouch
最後來講說要求吧,畢竟招人就像是相親,總得有個門檻的。
公司目前還處在創業階段,壓力是不可避免的,並且如今咱們用戶特多(尤爲是互聯網頭部用戶),這就要求你們必須具有必定的抗壓能力。
須要有分佈式開發經驗,至少 CAP,Raft 這些基礎概念是須要了解的。固然,若是你有調度系統的開發經驗,折騰過 Kubernetes,Mesos 等東西,那就更好了。
若是沒有這兩門語言的開發經驗,有 C、Python 相關經驗也沒問題。固然,Rust 可能對一些同窗是一個坎,就看你能不能克服了,畢竟這門語言實在太難上手了。
固然,咱們也很是歡迎實習生。對於想來實習的同窗,你只要以爲本身主動性強,肯學習,能寫代碼就能夠了。咱們有時候也直接會讓實習生去解決用戶問題,雖然會頗有挑戰,但能讓你快速成長。
咱們認爲優秀的工程師或多或少有如下共同特質:
A Quick Learner
An Earnest Curiosity
Faith in Open Source
Self-driven
Get Things Done
若是你符合以上特質,歡迎進入招聘頁面查看目前開放的工做機會:
https://www.pingcap.com/recruit-cn/join/#positions
實習生:公司的各項福利和學習資源對實習生全面開放,更重要的是實習生還未畢業就有機會接觸工業級項目,並且實習期間表現優異者將有機會得到校招綠色通道特權。若是小夥伴們時間不夠充裕,也能夠先從社區 Contributor 作起,或許下一期 Talent Plan 的主角就是你!
伯樂推薦:若是你身邊有符合以上要求的小夥伴,也能夠找咱們聊一聊,推薦成功就有機會得到伯樂推薦獎勵(iPad、iPhone、MacBook Pro 等等)。伯樂推薦郵件格式:[伯樂推薦] 候選人姓名-職位名稱-推薦人姓名-推薦人手機號。