TiKV 在京東雲對象存儲元數據管理的實踐

做者介紹：崔燦，京東雲產品研發部專家架構師，目前主要負責京東雲對象存儲產品的工做。

京東雲對象存儲是在 2016 年做爲公有云對外公開的，主要特色是可靠、安全、海量、低成本，應用於包括一些經常使用的業務場景，好比京東內部的京東商城視頻/圖片雲存儲，面向京東雲公有云外部的開發者的服務，和麪向企業的私有云服務，甚至混合雲服務。

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

1、對象存儲簡介

<center>圖 1 什麼是「對象」</center>

首先舉例說明一下這裏的「對象 (Object)」概念。好比咱們把一張照片看成一個「對象」，除了照片自己的二進制數據，它還應該包含一些元信息（照片數據長度、上次修改時間等）、涉及用戶的數據（拍攝者、拍攝設備數據等）。對象存儲的特色是這些數據不會頻繁地修改。

若是是數量比較少的圖片存儲，咱們可能會用相似 LVM 之類的東西，把一個節點上的多個磁盤使用起來，這種方法通常適用於數量級在 1M ~ 10M 的圖片。隨着業務的增加，圖片會愈來愈多甚至有視頻存儲，所以咱們採用分佈式文件系統來存儲，這種方法是基於 DFS 的架構（以下圖所示）。 

<center>圖 2 如何存儲對象（數據量 1B）</center>

這種方法的前提是單機容量受限，必須把數據放在多臺機器上存儲，而且用一個或多個獨立的 node 存儲元數據，而且元數據會維持樹狀目錄的結構，拆分比較困難。可是這個架構通常適合存儲到 10 億級別的對象，同時存在兩個比較大的問題：

• 數據分佈式存儲在不一樣的節點上，若是存在一箇中心的 master 節點的數據是相對有限的，那麼這個機器就不太可能無限擴張下去。

• 元數據管理是樹狀結構，它自己並不適合作分佈式存儲，而且目錄結構須要屢次訪問，不適合把它放到 SSD 上，而更適合放在內存裏，而後通常受權一個 master 節點 list。HDFS 基本也是這樣。

<center>圖 3 如何存儲對象（數據量 100B）</center>

那麼若是要求作千億級的對象存儲，如何實現呢？最容易想到的辦法是將元數據分佈式存儲，再也不像文件系統中那樣存儲在單獨的機器上，是一個樹狀結構，而是變成一個平坦結構。

2、對象存儲元數據管理系統

回到上面的舉例，針對一個圖片對象咱們主要有四類操做：上傳（Put）、下載（Get）、刪除（Delete），Scan。Scan 操做相對比較傳統 ，好比查看當前有多少圖片對象，獲取全部圖片名稱。

1. 元數據管理系統 v1.0

<center>圖 4 元數據管理系統 v1.0（1/4）</center>

上面是一個最簡單、原始的方案，這裏 Bucket 至關於名字空間（Namespace）。不少人最開始設計的結構也就是這樣的，但後期數據量增加很快的時候會遇到一些問題，以下圖。

<center>圖 5 元數據管理系統 v1.0（2/4）</center>

第一個問題是，在初期數據量比較小的時候，可能只分了 4 個 Bucket 存儲，隨着業務增加，須要從新拆分到 400 個 Bucket 中，數據遷移是一個 Rehash 過程，這是一件很是複雜且麻煩的事情。因此，咱們在思考對象存儲連續的、跨數量級的無限擴展要怎麼作呢？下圖是一個相對複雜的解決方案，核心思想是把絕大部分數據作靜態處理，由於靜態的存儲，不管是作遷移仍是作拆分，都比較簡單。好比天天都把前一天寫入的數據靜態化，合到歷史數據中去。

<center>圖 6 元數據管理系統 v1.0（3/4）</center>

針對第二個問題，若是單個 Bucket 數據量很大，那麼在往 Stable Meta（上圖中黃色部分）作靜態化遷移時須要作深度拆分，單個 Bucket 的對象的數量很是多，在一個數據庫裏面存儲不下來，須要存儲在多個數據庫裏面，再創建一層索引，存儲每一個數據庫裏面存儲那個區間的數據。同時，咱們在運行的時候其實也會出現一個 Bucket 數量變多的狀況，這種是屬於非預期的變多，這種狀況下咱們的作法是弄了一大堆外部的監控程序，監控 Bucket 的量，在 Bucket 量過大的時候，會主動去觸發表分裂、遷移等一系列流程。

<center>圖 7 元數據管理系統 v1.0（4/4）</center>

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

<center>圖 8 元數據管理系統改進目標</center>

因此，咱們思考了這個事情本質實際上是作一個全局有序 KV，而且須要「足夠大」，可以彈性擴張。這樣系統架構就會變得很是簡單（如上圖所示）。固然最終咱們找到了分佈式 KV 數據庫—— TiKV。

2. 基於 TiKV 的元數據管理系統

咱們前期調研了不少產品，最終選擇 TiKV 主要緣由有如下四點：

• 全局有序 KV，可輕鬆⽔平擴展，功能上徹底可以滿⾜對象存儲元數據管理的需求。

• 通過一些測試，性能上很好，可以知足要求。

• 社區活躍，文檔和工具相對比較完善。這一點也很重要，TiKV 目前已是 CNCF（雲原生計算基金會）的孵化項目，不少功能能夠快速開發，產品迭代也很迅速。

• 相對於 TiDB Server 而言，TiKV 的代碼更加簡單，並且咱們後續能夠在 TiKV 的基礎上作更多開發工做。

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

• 功能測試：測試 TiKV 的基本功能是否知足業務需求。

• 性能測試：測試了常規的 QPS、Latency (Avg, TP90, TP99) 等指標。

• 異常測試：其實咱們作數據存儲的同窗每每最關注的是各類異常故障的狀況，性能卻是其次，並且分佈式存儲相比單機存儲更爲複雜。因此咱們測試了各類機器/磁盤/網絡故障，業務異常狀況。更進一步的，咱們將這些異常狀況隨機組合，並在系統內觸發，再驗證系統的正確性。  

• 預發佈環境驗證：在大規模上線以前，咱們會在相對不過重要的、實際業務上跑一段時間，收集一些問題和可優化的部分，包括運維上的調優等。

經過上面的測試咱們認爲 TiKV 不管是從性能仍是系統安全性的角度，都能很好的知足要求，因而咱們在 TiKV 基礎之上，實現了對象元數據管理系統 v2.0，以下圖所示。

<center>圖 9 元數據管理系統 v2.0</center>

將 v1.0 中一堆複雜的數據庫和邏輯結構用 TiKV 替代以後，整個系統變得很是簡潔。

3、業務遷移

不少用戶可能直接將 MySQL 遷移到 TiDB 上，這個遷移過程已經很是成熟，可是因爲遷移到 TiKV 前人的經驗比較少，因此咱們在遷移過程當中也作了不少探索性的工做。

1. 遷移方案

<center>圖 10 遷移方案</center>

上圖是咱們設計的遷移方案，首先線上的數據都必須雙寫，保證數據安全。第二，咱們將存量數據設置爲只讀以後遷移到 TiKV 中，同時遷移過程當中的增量數據直接寫入 TiKV，天天將前一日的增量數據作靜態化處理，而後與 MySQL 中的數據對比，驗證數據正確性。另外，若是雙寫失敗，會啓用 MySQL backup。

下面詳細介紹實際操做過程當中的相關細節。

2. 切換

在存量數據切換方面，咱們首先將存量數據靜態化，簡化遷移、數據對比、回滾的流程；在增量數據切換方面，首先將增量數據雙寫 TiKV & MySQL，而且保證出現異常狀況時快速回滾至 MySQL，不影響線上的業務。值得一提的是，因爲 TiKV 在測試環境下的驗證結果很是好，因此咱們採用 TiKV 做爲雙寫的 Primary。

整個切換 過程分爲三個步驟：

• 存量數據切換到 TiKV，驗證讀。

• 增量數據切換到 TiKV，驗證讀寫。

• 驗證 TiKV 中的數據正確性以後，就下線 MySQL。

3. 驗證

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

<center>圖 11 雙寫驗證</center>

由於同時雙寫 MySQL 和 TiKV 可能會出現一種狀況是，寫入 TiKV 就成功了，可是寫入 MySQL 失敗了，這兩個寫入不在同一個事務中，因此不能保證必定同時成功或者失敗，尤爲是在業務量比較大的狀況下。對於這種不一致的狀況，咱們會經過業務層的操做記錄，來判斷是因爲業務層的問題致使的，仍是由 TiKV 致使的。

4、業務現狀及後續優化工做

目前 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 杭州站上的演講。