TiDB應用實踐

本文主要介紹了TiDB在小米的應用實踐和壓測資料，以及在小米場景下遇到的問題和解決辦法。

TiDB 結合了傳統的 RDBMS 和 NoSQL 的最佳特性，相容 MySQL 協議，支援無限的水平擴充套件，具備強一致性和高可用性，具有如下的特性：

1. 高度相容 MySQL，大多數情況下無需修改程式碼即可從 MySQL 輕鬆遷移至 TiDB，即使已經分庫分表的 MySQL 叢集亦可透過 TiDB 提供的遷移工具進行實時遷移。

2. 水平彈性擴充套件，透過簡單地增加新節點即可實現 TiDB 的水平擴充套件，按需擴充套件吞吐或儲存，輕鬆應對高併發、海量資料場景。

3. 分散式事務，TiDB 100% 支援標準的 ACID 事務。

4. 真正金融級高可用，相比於傳統主從 (M-S) 複製方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 資料強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。

TiDB 的架構及原理官網有詳細介紹（），這裡不再贅述。

TiDB基礎架構圖

關係型儲存資料庫首選 MySQL，單機 2.6T 磁碟。由於手機銷量的快速上升和 MIUI 負一屏使用者量的快速增加，導致負一屏快遞業務資料的資料量增長非常快，每天的讀寫量級均分別達到上億級別，資料快速增長導致單機出現瓶頸，比如效能明顯下降、可用儲存空間不斷降低、大表 DDL 無法執行等，不得不面臨資料庫擴充套件的問題。比如，我們有一個業務場景（智慧終端），需要定時從幾千萬級的智慧終端高頻的向資料庫寫入各種監控及採集資料，MySQL 基於 Binlog 的單執行緒複製模式，很容易造成從庫延遲，並且堆積越來越嚴重。

對於 MySQL 來講，最直接的方案就是採用分庫分表的水平擴充套件方式，綜合來看並不是最優的方案，比如對於業務來講，對業務程式碼的侵入性較大；對於 DBA 來講提升管理成本，後續需要不斷的拆分擴容，即使有中介軟體也有一定的侷限性。同樣是上面的智慧終端業務場景，從業務需求看，需要從多個業務維度進行查詢，並且業務維度可能隨時進行擴充套件，分表的方案基本不能滿足業務的需求。

瞭解到 TiDB 特點之後，DBA 與業務開發溝通確認當前 MySQL 的使用方式，並與 TiDB 的相容性做了詳細對比，經過業務壓測之後，根據壓測的結果，決定嘗試將資料儲存從 MySQL 遷移到 TiDB。經過幾個月的線上考驗，TiDB 的表現達到預期。

TiDB 支援包括跨行事務、JOIN、子查詢在內的絕大多數 MySQL 的語法，可以直接使用 MySQL 客戶端連線；對於已用 MySQL 的業務來講，基本可以無縫切換到 TiDB。

二者簡單對比如下幾方面：

1. 功能支援

（1）TiDB 尚不支援如下幾項：

1）增加、刪除主鍵

2）非 UTF8 字符集

3）檢視（即將支援）、儲存過程、觸發器、部分內建函式

4）Event

5）全文索引、空間索引

 （1）字符集、排序規則、sql_mode、lower_case_table_names 幾項預設值不同

（1）TiDB 使用樂觀事務模型，提交後注意檢查返回值。

（2）TiDB 限制單個事務大小，保持事務儘可能的小。

透過壓測 TiDB 瞭解一下其 OLTP 效能，看是否滿足業務要求。

 1.標準Select壓測

 2.標準OLTP壓測

3.標準Insert壓測

透過壓測發現 TiDB 穩定性上與預期稍有差別，不過壓測的 Load 會明顯高於生產中的業務 Load，參考低 Threads 時 TiDB 的表現，基本可以滿足業務對 DB 的效能要求，決定灰度一部分 MySQL 從庫讀流量體驗一下實際效果。

整個遷移分為 2 大塊：資料遷移、流量遷移

資料遷移分為增量資料、存量資料兩部分。

1. 對於存量資料，可以使用邏輯備份、匯入的方式，除了傳統的邏輯匯入外，官方還提供一款物理匯入的工具 TiDB Lightning。

2. 對於增量備份可以使用 TiDB 提供的 Syncer （新版已經更名為 DM - Data Migration）來保證資料同步。

(1)Syncer 簡介 
主要依靠各種 Rule 來實現不同的過濾、合併效果，一個同步源對應一個 Syncer 程式，同步 Sharding 資料時則要多個 Syncer 程式。  

Syncer結構圖

1. 使用 Syncer 注意事項

    （1）做好同步前檢查，包含 server-id、log_bin、binlog_format 是否為 ROW、binlog_row_image 是否為 FULL、同步相關使用者許可權、Binlog 資訊等。

（2）使用嚴格資料檢查模式，資料不合法則會停止。資料遷移之前最好針對資料、表結構做檢查。

（3）做好監控，TiDB 提供現成的監控方案。

（4）對於已經分片的表同步到同一個 TiDB 叢集，要做好預先檢查。確認同步場景是否可以用 route-rules 表達，檢查分表的唯一鍵、主鍵在資料合併後是否衝突等。

流量切換到 TiDB 分為兩部分：讀、寫流量遷移。每次切換保證灰度過程，觀察週期為 1~2 周，做好回滾措施。

1. 讀流量切換到 TiDB，這個過程中回滾比較簡單，灰度無問題，則全量切換。

2. 將寫入切換到 TiDB，需要考慮好資料回滾方案或者採用雙寫的方式（需要斷掉 Syncer）。

叢集配置採用官方推薦的 7 節點配置，3 個 TiDB 節點，3 個 PD 節點，4 個 TiKV 節點，其中每個 TiDB 與 PD 為一組，共用一臺物理機。後續隨著業務增長或者新業務接入，再按需新增 TiKV 節點。

監控採用了 TiDB 的提供的監控方案，並且也接入了公司開源的 Falcon，目前整個叢集執行比較穩定，監控如下圖。

目前 TiDB 主要提供 OLTP 服務，負一屏快遞業務為使用 TiDB 做了一個良好的開端，而後商業廣告也有接入，2 個業務均已上線數月，TiDB 的穩定性經受住了考驗，帶來了很棒的體驗，對於後續大體的規劃如下

1. MIUI 生態業務中存在大量的類似場景的業務，後續將會與業務開發積極溝通，從 MySQL 遷移到 TiDB。

2. 針對某些業務場景，以資源合理利用為目標，推出歸檔叢集，利用 Syncer 實現資料歸檔的功能。

3. 資料分析，結合 TiDB 提供的工具，將支援離線、實時資料分析支援。

4. 將 TiDB 的監控融合到Open Falcon 中。