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

本文將介紹京東雲物件儲存服務的架構演進，以及遷移到 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淺析

相關推薦