摘要：在系統(tǒng)基礎(chǔ)上，針對(duì)中國(guó)用戶進(jìn)行了深度定制，在此之上孕育出了一系列的應(yīng)用，比如主題商店小米音樂(lè)應(yīng)用商店小米閱讀等。將的監(jiān)控融合到小米公司開源的監(jiān)控系統(tǒng)中。

作者：張良，小米 DBA 負(fù)責(zé)人；潘友飛，小米 DBA；王必文，小米開發(fā)工程師。

MIUI 是小米公司旗下基于 Android 系統(tǒng)深度優(yōu)化、定制、開發(fā)的第三方手機(jī)操作系統(tǒng)，也是小米的第一個(gè)產(chǎn)品。MIUI 在 Android 系統(tǒng)基礎(chǔ)上，針對(duì)中國(guó)用戶進(jìn)行了深度定制，在此之上孕育出了一系列的應(yīng)用，比如主題商店、小米音樂(lè)、應(yīng)用商店、小米閱讀等。

目前 TiDB 主要應(yīng)用在：

小米手機(jī)桌面負(fù)一屏的快遞業(yè)務(wù)

商業(yè)廣告交易平臺(tái)素材抽審平臺(tái)

這兩個(gè)業(yè)務(wù)場(chǎng)景每天讀寫量均達(dá)到上億級(jí)，上線之后，整個(gè)服務(wù)穩(wěn)定運(yùn)行；接下來(lái)我們計(jì)劃逐步上線更多的業(yè)務(wù)場(chǎng)景，小米閱讀目前正在積極的針對(duì)訂單系統(tǒng)做遷移測(cè)試。

TiDB 結(jié)合了傳統(tǒng)的 RDBMS 和 NoSQL 的最佳特性，兼容 MySQL 協(xié)議，支持無(wú)限的水平擴(kuò)展，具備強(qiáng)一致性和高可用性。

具有如下的特性：

高度兼容 MySQL，大多數(shù)情況下無(wú)需修改代碼即可從 MySQL 輕松遷移至 TiDB，即使已經(jīng)分庫(kù)分表的 MySQL 集群亦可通過(guò) TiDB 提供的遷移工具進(jìn)行實(shí)時(shí)遷移。

水平彈性擴(kuò)展，通過(guò)簡(jiǎn)單地增加新節(jié)點(diǎn)即可實(shí)現(xiàn) TiDB 的水平擴(kuò)展，按需擴(kuò)展吞吐或存儲(chǔ)，輕松應(yīng)對(duì)高并發(fā)、海量數(shù)據(jù)場(chǎng)景。

分布式事務(wù)，TiDB 100% 支持標(biāo)準(zhǔn)的 ACID 事務(wù)。

真正金融級(jí)高可用，相比于傳統(tǒng)主從（M-S）復(fù)制方案，基于 Raft 的多數(shù)派選舉協(xié)議可以提供金融級(jí)的 100% 數(shù)據(jù)強(qiáng)一致性保證，且在不丟失大多數(shù)副本的前提下，可以實(shí)現(xiàn)故障的自動(dòng)恢復(fù)（auto-failover），無(wú)需人工介入。

TiDB 的架構(gòu)及原理在 官網(wǎng) 里有詳細(xì)介紹，這里不再贅述。

跟絕大數(shù)互聯(lián)網(wǎng)公司一樣，小米關(guān)系型存儲(chǔ)數(shù)據(jù)庫(kù)首選 MySQL，單機(jī) 2.6T 磁盤。由于小米手機(jī)銷量的快速上升和 MIUI 負(fù)一屏用戶量的快速增加，導(dǎo)致負(fù)一屏快遞業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)量增長(zhǎng)非?？?，每天的讀寫量級(jí)均分別達(dá)到上億級(jí)別，數(shù)據(jù)快速增長(zhǎng)導(dǎo)致單機(jī)出現(xiàn)瓶頸，比如性能明顯下降、可用存儲(chǔ)空間不斷降低、大表 DDL 無(wú)法執(zhí)行等，不得不面臨數(shù)據(jù)庫(kù)擴(kuò)展的問(wèn)題。比如，我們有一個(gè)業(yè)務(wù)場(chǎng)景（智能終端），需要定時(shí)從幾千萬(wàn)級(jí)的智能終端高頻的向數(shù)據(jù)庫(kù)寫入各種監(jiān)控及采集數(shù)據(jù)，MySQL 基于 Binlog 的單線程復(fù)制模式，很容易造成從庫(kù)延遲，并且堆積越來(lái)越嚴(yán)重。

對(duì)于 MySQL 來(lái)講，最直接的方案就是采用分庫(kù)分表的水平擴(kuò)展方式，綜合來(lái)看并不是最優(yōu)的方案，比如對(duì)于業(yè)務(wù)來(lái)講，對(duì)業(yè)務(wù)代碼的侵入性較大；對(duì)于 DBA 來(lái)講提升管理成本，后續(xù)需要不斷的拆分?jǐn)U容，即使有中間件也有一定的局限性。同樣是上面的智能終端業(yè)務(wù)場(chǎng)景，從業(yè)務(wù)需求看，需要從多個(gè)業(yè)務(wù)維度進(jìn)行查詢，并且業(yè)務(wù)維度可能隨時(shí)進(jìn)行擴(kuò)展，分表的方案基本不能滿足業(yè)務(wù)的需求。

了解到 TiDB 特點(diǎn)之后，DBA 與業(yè)務(wù)開發(fā)溝通確認(rèn)當(dāng)前 MySQL 的使用方式，并與 TiDB 的兼容性做了詳細(xì)對(duì)比，經(jīng)過(guò)業(yè)務(wù)壓測(cè)之后，根據(jù)壓測(cè)的結(jié)果，決定嘗試將數(shù)據(jù)存儲(chǔ)從 MySQL 遷移到 TiDB。經(jīng)過(guò)幾個(gè)月的線上考驗(yàn)，TiDB 的表現(xiàn)達(dá)到預(yù)期。

TiDB 支持包括跨行事務(wù)、JOIN、子查詢?cè)趦?nèi)的絕大多數(shù) MySQL 的語(yǔ)法，可以直接使用 MySQL 客戶端連接；對(duì)于已用 MySQL 的業(yè)務(wù)來(lái)講，基本可以無(wú)縫切換到 TiDB。

二者簡(jiǎn)單對(duì)比如下幾方面：

功能支持

TiDB 尚不支持如下幾項(xiàng)：

增加、刪除主鍵

非 UTF8 字符集

視圖（即將支持）、存儲(chǔ)過(guò)程、觸發(fā)器、部分內(nèi)置函數(shù)

Event

全文索引、空間索引

默認(rèn)設(shè)置

字符集、排序規(guī)則、sql_mode、lower_case_table_names 幾項(xiàng)默認(rèn)值不同。

事務(wù)

TiDB 使用樂(lè)觀事務(wù)模型，提交后注意檢查返回值。

TiDB 限制單個(gè)事務(wù)大小，保持事務(wù)盡可能的小。

TiDB 支持絕大多數(shù)的 Online DDL。

另，一些 MySQL 語(yǔ)法在 TiDB 中可以解析通過(guò)，不會(huì)產(chǎn)生任何作用，例如： create table 語(yǔ)句中 engine、partition 選項(xiàng)都是在解析后忽略。

詳細(xì)信息可以訪問(wèn)官網(wǎng)：https://pingcap.com/docs-cn/sql/mysql-compatibility/?。

通過(guò)壓測(cè) TiDB 了解一下其 OLTP 性能，看是否滿足業(yè)務(wù)要求。

通過(guò)壓測(cè)發(fā)現(xiàn) TiDB 穩(wěn)定性上與預(yù)期稍有差別，不過(guò)壓測(cè)的 Load 會(huì)明顯高于生產(chǎn)中的業(yè)務(wù) Load，參考低 Threads 時(shí) TiDB 的表現(xiàn)，基本可以滿足業(yè)務(wù)對(duì) DB 的性能要求，決定灰度一部分 MySQL 從庫(kù)讀流量體驗(yàn)一下實(shí)際效果。

整個(gè)遷移分為 2 大塊：數(shù)據(jù)遷移、流量遷移。

數(shù)據(jù)遷移分為增量數(shù)據(jù)、存量數(shù)據(jù)兩部分。

對(duì)于存量數(shù)據(jù)，可以使用邏輯備份、導(dǎo)入的方式，除了傳統(tǒng)的邏輯導(dǎo)入外，官方還提供一款物理導(dǎo)入的工具 TiDB Lightning。

對(duì)于增量備份可以使用 TiDB 提供的 Syncer （新版已經(jīng)更名為 DM - Data Migration）來(lái)保證數(shù)據(jù)同步。

Syncer 結(jié)構(gòu)如圖 6，主要依靠各種 Rule 來(lái)實(shí)現(xiàn)不同的過(guò)濾、合并效果，一個(gè)同步源對(duì)應(yīng)一個(gè) Syncer 進(jìn)程，同步 Sharding 數(shù)據(jù)時(shí)則要多個(gè) Syncer 進(jìn)程。

使用 Syncer 需要注意：

做好同步前檢查，包含 server-id、log_bin、binlog_format 是否為 ROW、binlog_row_image 是否為 FULL、同步相關(guān)用戶權(quán)限、Binlog 信息等。

使用嚴(yán)格數(shù)據(jù)檢查模式，數(shù)據(jù)不合法則會(huì)停止。數(shù)據(jù)遷移之前最好針對(duì)數(shù)據(jù)、表結(jié)構(gòu)做檢查。

做好監(jiān)控，TiDB 提供現(xiàn)成的監(jiān)控方案。

對(duì)于已經(jīng)分片的表同步到同一個(gè) TiDB 集群，要做好預(yù)先檢查。確認(rèn)同步場(chǎng)景是否可以用 route-rules 表達(dá)，檢查分表的唯一鍵、主鍵在數(shù)據(jù)合并后是否沖突等。

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

讀流量切換到 TiDB，這個(gè)過(guò)程中回滾比較簡(jiǎn)單，灰度無(wú)問(wèn)題，則全量切換。

再將寫入切換到 TiDB，需要考慮好數(shù)據(jù)回滾方案或者采用雙寫的方式（需要斷掉 Syncer）。

集群配置采用官方推薦的 7 節(jié)點(diǎn)配置，3 個(gè) TiDB 節(jié)點(diǎn)，3 個(gè) PD 節(jié)點(diǎn)，4 個(gè) TiKV 節(jié)點(diǎn)，其中每個(gè) TiDB 與 PD 為一組，共用一臺(tái)物理機(jī)。后續(xù)隨著業(yè)務(wù)增長(zhǎng)或者新業(yè)務(wù)接入，再按需添加 TiKV 節(jié)點(diǎn)。

監(jiān)控采用了 TiDB 的提供的監(jiān)控方案，并且也接入了公司開源的 Falcon，目前整個(gè)集群運(yùn)行比較穩(wěn)定，監(jiān)控如圖 7。 ?????

目前 TiDB 在小米主要提供 OLTP 服務(wù)，小米手機(jī)負(fù)一屏快遞業(yè)務(wù)為使用 TiDB 做了一個(gè)良好的開端，而后商業(yè)廣告也有接入，2 個(gè)業(yè)務(wù)均已上線數(shù)月，TiDB 的穩(wěn)定性經(jīng)受住了考驗(yàn)，帶來(lái)了很棒的體驗(yàn)，對(duì)于后續(xù)大體的規(guī)劃如下：

MIUI 生態(tài)業(yè)務(wù)中存在大量的類似場(chǎng)景的業(yè)務(wù)，后續(xù)將會(huì)與業(yè)務(wù)開發(fā)積極溝通，從 MySQL 遷移到 TiDB。

針對(duì)某些業(yè)務(wù)場(chǎng)景，以資源合理利用為目標(biāo)，推出歸檔集群，利用 Syncer 實(shí)現(xiàn)數(shù)據(jù)歸檔的功能。

數(shù)據(jù)分析，結(jié)合 TiDB 提供的工具，將支持離線、實(shí)時(shí)數(shù)據(jù)分析支持。

將 TiDB 的監(jiān)控融合到小米公司開源的監(jiān)控系統(tǒng) Falcon 中。

非常感謝 TiDB 官方在遷移及業(yè)務(wù)上線期間給予我們的支持，為每一個(gè) TiDB 人專業(yè)的精神、及時(shí)負(fù)責(zé)的響應(yīng)點(diǎn)贊。

更多 TiDB 用戶實(shí)踐： https://www.pingcap.com/cases-cn/