TiKV 在京東雲物件儲存後設資料管理的實踐

京東雲物件儲存是在 2016 年作為公有云對外公開的，主要特點是可靠、安全、海量、低成本，應用於包括一些常用的業務場景，比如京東內部的京東商城影片/圖片雲端儲存，面向京東雲公有云外部的開發者的服務，和麵向政府、企業的私有云服務，甚至混合雲服務。 

本文將介紹京東雲物件儲存服務的架構演進，以及遷移到 TiKV 的經驗。

一、物件儲存簡介

圖 1 什麼是“物件”

首先舉例說明一下這裡的“物件 (Object)”概念。比如我們把一張照片當作一個“物件”，除了照片本身的二進位制資料，它還應該包含一些元資訊（照片資料長度、上次修改時間等）、涉及使用者的資料（拍攝者、拍攝裝置資料等）。物件儲存的特點是這些資料不會頻繁地修改。

如果是數量比較少的圖片儲存，我們可能會用類似 LVM 之類的東西，把一個節點上的多個磁碟使用起來，這種方法一般適用於數量級在 1M ~ 10M 的圖片。隨著業務的增長，圖片會越來越多甚至有影片儲存，因此我們採用分散式檔案系統來儲存，這種方法是基於 DFS 的架構（如下圖所示）。

圖 2 如何儲存物件（資料量 1B）

這種方法的前提是單機容量受限，必須把資料放在多臺機器上儲存，並且用一個或多個獨立的 node 儲存後設資料，並且後設資料會維持樹狀目錄的結構，拆分比較困難。但是這個架構一般適合儲存到 10 億級別的物件，同時存在兩個比較大的問題：

• 資料分散式儲存在不同的節點上，如果存在一箇中心的 master 節點的資料是相對有限的，那麼這個機器就不太可能無限擴張下去。
• 後設資料管理是樹狀結構，它本身並不適合做分散式儲存，並且目錄結構需要多次訪問，不適合把它放到 SSD 上，而更適合放在記憶體裡，然後一般授權一個 master 節點 list。HDFS 基本也是這樣。

圖 3 如何儲存物件（資料量 100PB）

那麼如果要求做千億級的物件儲存，如何實現呢？最容易想到的辦法是將後設資料分散式儲存，不再像檔案系統中那樣儲存在單獨的機器上，是一個樹狀結構，而是變成一個平坦結構。

二、物件儲存後設資料管理系統

回到上面的舉例，針對一個圖片物件我們主要有四類操作：上傳（Put）、下載（Get）、刪除（Delete），Scan。Scan 操作相對比較傳統 ，比如檢視當前有多少圖片物件，獲取所有圖片名稱。

1. 後設資料管理系統 v1.0

圖 4 後設資料管理系統 v1.0（1/4）

上面是一個最簡單、原始的方案，這裡 Bucket 相當於名字空間（Namespace）。很多人最開始設計的結構也就是這樣的，但後期資料量增長很快的時候會遇到一些問題，如下圖。

圖 5 後設資料管理系統 v1.0（2/4）

第一個問題是，在初期資料量比較小的時候，可能只分了 4 個 Bucket 儲存，隨著業務增長，需要重新拆分到 400 個 Bucket 中，資料遷移是一個 Rehash 過程，這是一件非常複雜且麻煩的事情。所以，我們在思考物件儲存連續的、跨數量級的無限擴充套件要怎麼做呢？下圖是一個相對複雜的解決方案，核心思想是把絕大部分資料做靜態處理，因為靜態的儲存，無論是做遷移還是做拆分，都比較簡單。比如每天都把前一天寫入的資料靜態化，合到歷史資料中去。

圖 6 後設資料管理系統 v1.0（3/4）

針對第二個問題，如果單個 Bucket 資料量很大，那麼在往 Stable Meta（上圖中黃色部分）做靜態化遷移時需要做深度拆分，單個 Bucket 的物件的數量非常多，在一個資料庫裡面儲存不下來，需要儲存在多個資料庫裡面，再建立一層索引，儲存每個資料庫裡面儲存那個區間的資料。同時，我們在執行的時候其實也會出現一個 Bucket 數量變多的情況，這種是屬於非預期的變多，這種情況下我們的做法是弄了一大堆外部的監控程式，監控 Bucket 的量，在 Bucket 量過大的時候，會主動去觸發表分裂、遷移等一系列流程。

圖 7 後設資料管理系統 v1.0（4/4）

這個解決方案有兩個明顯的問題，第一資料分佈複雜，管理困難；第二，排程不靈活，給後期維護帶來很大的困難。

圖 8 後設資料管理系統改進目標

所以，我們思考了這個事情本質其實是做一個全域性有序 KV，並且需要“足夠大”，能夠彈性擴張。這樣系統架構就會變得非常簡單（如上圖所示） 。當然最終我們找到了分散式 KV 資料庫—— TiKV。

2. 基於 TiKV 的後設資料管理系統

我們前期調研了很多產品，最終選擇 TiKV 主要原因有以下四點：

• 全域性有序 KV，可輕鬆⽔平擴充套件，功能上完全能夠滿⾜物件儲存後設資料管理的需求。
• 經過一些測試，效能上很好，能夠滿足要求。
• 社群活躍，文件和工具相對比較完善。這一點也很重要，TiKV 目前已經是 CNCF（雲原生計算基金會）的孵化專案，很多功能可以快速開發，產品迭代也很迅速。
• 相對於 TiDB Server 而言，TiKV 的程式碼更加簡單，而且我們後續可以在 TiKV 的基礎上做更多開發工作。

在上線之前，我們主要進行了以下幾方面的測試：

• 功能測試：測試 TiKV 的基本功能是否滿足業務需求。
• 效能測試：測試了常規的 QPS、Latency (Avg, TP90, TP99) 等指標。
• 異常測試：其實我們做資料儲存的同學往往最關注的是各種異常故障的情況，效能倒是其次，而且分散式儲存相比單機儲存更為複雜。所以我們測試了各種機器/磁碟/網路故障，業務異常情況。更進一步的，我們將這些異常情況隨機組合，並在系統內觸發，再驗證系統的正確性。
• 預釋出環境驗證：在大規模上線之前，我們會在相對不太重要的、實際業務上跑一段時間，收集一些問題和可最佳化的部分，包括運維上的調優等。

透過上面的測試我們認為 TiKV 無論是從效能還是系統安全性的角度，都能很好的滿足要求，於是我們在 TiKV 基礎之上，實現了物件後設資料管理系統 v2.0，如下圖所示。

圖 9 後設資料管理系統 v2.0

將 v1.0 中一堆複雜的資料庫和邏輯結構用 TiKV 替代之後，整個系統變得非常簡潔。

三、業務遷移

很多使用者可能直接將 MySQL 遷移到 TiDB 上，這個遷移過程已經非常成熟，但是由於遷移到 TiKV 前人的經驗比較少，所以我們在遷移過程中也做了很多探索性的工作。

1. 遷移方案

圖 10 遷移方案

上圖是我們設計的遷移方案，首先線上的資料都必須雙寫，保證資料安全。第二，我們將存量資料設定為只讀之後遷移到 TiKV 中，同時遷移過程中的增量資料直接寫入 TiKV，每天將前一日的增量資料做靜態化處理，然後與 MySQL 中的資料對比，驗證資料正確性。另外，如果雙寫失敗，會啟用 MySQL backup。下面詳細介紹實際操作過程中的相關細節。

2. 切換

在存量資料切換方面，我們首先將存量資料靜態化，簡化遷移、資料對比、回滾的流程；在增量資料切換方面，首先將增量資料雙寫 TiKV & MySQL，並且保證出現異常情況時快速回滾至 MySQL，不影響線上的業務。值得一提的是，由於 TiKV 在測試環境下的驗證結果非常好，所以我們採用 TiKV 作為雙寫的 Primary。整個切換 過程分為三個步驟：

• 存量資料切換到 TiKV，驗證讀。
• 增量資料切換到 TiKV，驗證讀寫。
• 驗證 TiKV 中的資料正確性之後，就下線 MySQL。

3. 驗證

資料驗證過程最大的困難在於增量資料的驗證，因為增量資料是每天變化的，所以我們雙寫了 MySQL 和 TiKV，並且每天將增量資料進行靜態化處理，用 MySQL 中的記錄來驗證 TiKV 的資料是否可靠（沒有出現資料丟失和錯誤），如下圖所示。

圖 11 雙寫驗證

因為同時雙寫 MySQL 和 TiKV 可能會出現一種情況是，寫入 TiKV 就成功了，但是寫入 MySQL 失敗了，這兩個寫入不在同一個事務中，所以不能保證一定同時成功或者失敗，尤其是在業務量比較大的情況下。對於這種不一致的情況，我們會透過業務層的操作記錄，來判斷是由於業務層的問題導致的，還是由 TiKV 導致的。

四、業務現狀及後續最佳化工作

目前 TiKV 在京東雲物件儲存業務上是 Primary 資料庫，計劃 2019 年年底會把原資料庫下線。總共部署的叢集數量為 10+，生產環境單叢集 QPS 峰值 4 萬（讀寫 1:1），最大的單叢集資料量 200+億，共有 50 餘萬個 Region，我們後設資料管理業務對 Latency 要求比較高，目前 Latency 能保證在 10ms 左右。另外，我們正在測試 TiKV 3.0，預計 2019 年第四季度能夠上線。

針對目前的業務執行情況，我們後續還將做一些最佳化工作。

第一點是災備 ，目前我們是在業務層做災備，後續可能會直接在 TiKV 層做災備，也很期待 TiKV 之後的版本中能夠有這方面的功能。

第二點是叢集規模最佳化 ，因為物件儲存是儲存密集型的業務，我們希望壓縮硬體成本，比如可以用到 8T 、10T 的磁碟，或者用更廉價的磁碟，這點我們後續可能 PingCAP 研發同學們一起考慮怎麼最佳化提升。

第三點是 Region 排程最佳化 ，目前 TiKV 的排程整體比較複雜，這對於儲存密集型的業務來說就比較麻煩，尤其是資料量特別大的情況下，我們並不希望有一絲的波動就把資料遷移到其他機器上。

本文整理自崔燦老師在 TiDB TechDay 2019 杭州站上的演講。

歡迎點選“ 京東雲 ”瞭解更多精彩內容

推薦閱讀

乾貨 | TiDB Operator實踐

乾貨 | DRDS 與TiDB淺析

---