摘要：業(yè)務(wù)延遲和錯(cuò)誤量對(duì)比接入數(shù)據(jù)庫后業(yè)務(wù)邏輯層服務(wù)接口耗時(shí)穩(wěn)定無抖動(dòng)，且沒有發(fā)生丟棄的情況上圖錯(cuò)誤大多由數(shù)據(jù)訪問層服務(wù)隊(duì)列堆積發(fā)生請(qǐng)求丟棄造成。

作者：孫玄，轉(zhuǎn)轉(zhuǎn)公司首席架構(gòu)師；陳東，轉(zhuǎn)轉(zhuǎn)公司資深工程師；冀浩東，轉(zhuǎn)轉(zhuǎn)公司資深 DBA。

轉(zhuǎn)轉(zhuǎn)二手交易網(wǎng) —— 把家里不用的東西賣了變成錢，一個(gè)幫你賺錢的網(wǎng)站。由騰訊與 58 集團(tuán)共同投資。為海量用戶提供一個(gè)有擔(dān)保、便捷的二手交易平臺(tái)。轉(zhuǎn)轉(zhuǎn)是 2015 年 11 月 12 日正式推出的 APP，遵循“用戶第一”的核心價(jià)值觀，以“讓資源重新配置，讓人與人更信任”為企業(yè)愿景，提倡真實(shí)個(gè)人交易。

轉(zhuǎn)轉(zhuǎn)二手交易涵蓋手機(jī)、3C 數(shù)碼、母嬰用品等三十余個(gè)品類。在系統(tǒng)設(shè)計(jì)上，轉(zhuǎn)轉(zhuǎn)整體架構(gòu)采用微服務(wù)架構(gòu)，首先按照業(yè)務(wù)領(lǐng)域模型垂直拆分成用戶、商品、交易、搜索、推薦微服務(wù)。對(duì)每一個(gè)功能單元（商品等），繼續(xù)進(jìn)行水平拆分，分為商品網(wǎng)關(guān)層、商品業(yè)務(wù)邏輯層、商品數(shù)據(jù)訪問層、商品 DB / Cache，如下圖所示：?

1. 面臨的問題

轉(zhuǎn)轉(zhuǎn)后端業(yè)務(wù)現(xiàn)階段主要使用 MySQL 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)，還有少部分業(yè)務(wù)使用 MongoDB。雖然目前情況下使用這兩種存儲(chǔ)基本可以滿足我們的需求，但隨著業(yè)務(wù)的增長(zhǎng)，公司的數(shù)據(jù)規(guī)模逐漸變大，為了應(yīng)對(duì)大數(shù)據(jù)量下業(yè)務(wù)服務(wù)訪問的性能問題，MySQL 數(shù)據(jù)庫常用的分庫、分表方案會(huì)隨著 MySQL Sharding（分片）的增多，業(yè)務(wù)訪問數(shù)據(jù)庫邏輯會(huì)越來越復(fù)雜。而且對(duì)于某些有多維度查詢需求的表，我們總需要引入額外的存儲(chǔ)或犧牲性能來滿足我們的查詢需求，這樣會(huì)使業(yè)務(wù)邏輯越來越重，不利于產(chǎn)品的快速迭代。

從數(shù)據(jù)庫運(yùn)維角度講，大數(shù)據(jù)量的情況下，MySQL 數(shù)據(jù)庫在每次 DDL 都會(huì)對(duì)運(yùn)維人員造成很大的工作量，當(dāng)節(jié)點(diǎn)故障后，由于數(shù)據(jù)量較大，恢復(fù)時(shí)間較長(zhǎng)。但這種 M - S 架構(gòu)只能通過主從切換并且需要額外的高可用組件來保障高可用，同時(shí)在切換過程由于需要確定主庫狀態(tài)、新主庫選舉、新路由下發(fā)等原因，還是會(huì)存在短暫的業(yè)務(wù)訪問中斷的情況。?
綜上所述，我們面臨的主要問題可歸納為：

數(shù)據(jù)量大，如何快速水平擴(kuò)展存儲(chǔ)；

大數(shù)據(jù)量下，如何快速 DDL；

分庫分表造成業(yè)務(wù)邏輯非常復(fù)雜；

常規(guī) MySQL 主從故障轉(zhuǎn)移會(huì)導(dǎo)致業(yè)務(wù)訪問短暫不可用。

2. 為什么選擇 TiDB

針對(duì)上章提到的問題，轉(zhuǎn)轉(zhuǎn)基礎(chǔ)架構(gòu)部和 DBA 團(tuán)隊(duì)考慮轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)數(shù)據(jù)增速，定位簡(jiǎn)化業(yè)務(wù)團(tuán)隊(duì)數(shù)據(jù)庫使用方案，更好的助力業(yè)務(wù)發(fā)展，決定啟動(dòng)新型存儲(chǔ)服務(wù)（NewSQL）的選型調(diào)研工作。?

TiDB 數(shù)據(jù)庫，結(jié)合了關(guān)系庫與 KV 存儲(chǔ)的優(yōu)點(diǎn)，對(duì)于使用方，完全可以當(dāng)做 MySQL 來用，而且不用考慮數(shù)據(jù)量大了后的分庫分表以及為了支持分庫分表后的多維度查詢而建立的 Mapping 表，可以把精力全部放在業(yè)務(wù)需求上。所以我們把 TiDB 作為選型的首選對(duì)象展開了測(cè)試和試用。

1. 功能測(cè)試

TiDB 支持絕大多數(shù) MySQL 語法，業(yè)務(wù)可以將基于 MySQL 的開發(fā)，無縫遷移至 TiDB。不過目前 TiDB 不支持部分 MySQL 特性，如：存儲(chǔ)過程、自定義函數(shù)、觸發(fā)器等。

2. TiDB 壓力測(cè)試

通過測(cè)試工具模擬不同的場(chǎng)景的請(qǐng)求，對(duì) TiDB 數(shù)據(jù)庫進(jìn)行壓力測(cè)試，通過壓力測(cè)試結(jié)果的對(duì)比，可以提供 RD 使用 TiDB 的合適業(yè)務(wù)場(chǎng)景以及 TiDB 的使用建議。
此次壓力測(cè)試，總共使用 6 臺(tái)物理服務(wù)器，其中 3 臺(tái) CPU 密集型服務(wù)器，用于啟動(dòng) TiDB - Server、PD 服務(wù)；另外 3 臺(tái)為 IO / CPU 密集型的PCIE 服務(wù)器，用于啟動(dòng) TiKV 服務(wù)。
使用 sysbench - 1.0.11 測(cè)試數(shù)據(jù)大小為 200G 的 TiDB 集群，在不同場(chǎng)景下 TiDB 的響應(yīng)時(shí)間（95th per）：

3. 結(jié)果整理

順序掃描的效率是比較高的，連續(xù)的行大概率會(huì)存儲(chǔ)在同一臺(tái)機(jī)器的鄰近位置，每次批量的讀取和寫入的效率會(huì)高；

控制并發(fā)運(yùn)行的線程數(shù)，會(huì)減少請(qǐng)求響應(yīng)時(shí)間，提高數(shù)據(jù)庫的處理性能。

4. 場(chǎng)景建議

適合線上業(yè)務(wù)混合讀寫場(chǎng)景；

適合順序?qū)懙膱?chǎng)景，比如：數(shù)據(jù)歸檔、操作日志、攤銷流水。

5. TiDB 預(yù)上線

將 TiDB 掛載到線上 MySQL，作為 MySQL 從庫同步線上數(shù)據(jù)，然后業(yè)務(wù)將部分線上讀流量切換到 TiDB，可以對(duì) TiDB 集群是否滿足業(yè)務(wù)訪問做好預(yù)判。

1. 遷移過程

我們第一個(gè)接入 TiDB 的業(yè)務(wù)線是轉(zhuǎn)轉(zhuǎn)消息服務(wù)。消息作為轉(zhuǎn)轉(zhuǎn)最重要的基礎(chǔ)服務(wù)之一，是保證平臺(tái)上買賣雙方有效溝通、促進(jìn)交易達(dá)成的重要組件，其數(shù)據(jù)量和訪問量都非常大。起初我們使用的是 MySQL 數(shù)據(jù)庫，對(duì)其所有的業(yè)務(wù)都做了庫的垂直拆分以及表的水平拆分。目前線上有幾十 TB 的數(shù)據(jù)，記錄數(shù)據(jù)達(dá)到了幾百億。雖對(duì) MySQL 做了分庫分表，但實(shí)例已經(jīng)開始又有偶發(fā)的性能問題，需要馬上對(duì)數(shù)據(jù)進(jìn)行二次拆分，而二次拆分的執(zhí)行成本也比較高，這也是我們首先遷移消息數(shù)據(jù)庫的原因之一。

消息服務(wù)有幾個(gè)核心業(yè)務(wù)表：聯(lián)系人列表、消息表、系統(tǒng)消息表等等。聯(lián)系人列表作為整個(gè)消息系統(tǒng)的樞紐，承載著巨大的訪問壓力。業(yè)務(wù)場(chǎng)景相對(duì)其他表最復(fù)雜的，也是這個(gè)表的實(shí)例出現(xiàn)了性能問題，所以我們決定先遷移聯(lián)系人列表。

整個(gè)遷移過程分三步：測(cè)試（判斷 TiDB 是否滿足業(yè)務(wù)場(chǎng)景，性能是否 OK）、同步數(shù)據(jù)、切流量。

（1）測(cè)試：首先我們模擬線上的數(shù)據(jù)和請(qǐng)求對(duì)“聯(lián)系人列表”做了大量功能和性能的驗(yàn)證，而且還將線上的數(shù)據(jù)和流量引到線下，對(duì)數(shù)據(jù)庫做了真實(shí)流量的驗(yàn)證，測(cè)試結(jié)果證明 TiDB 完全滿足消息業(yè)務(wù)的需求。引流工作，我們是通過轉(zhuǎn)轉(zhuǎn)自研的消息隊(duì)列，將線上數(shù)據(jù)庫的流量引一份到測(cè)試環(huán)境。測(cè)試環(huán)境消費(fèi)消息隊(duì)列的數(shù)據(jù)，轉(zhuǎn)換成數(shù)據(jù)庫訪問請(qǐng)求發(fā)送到 TiDB 測(cè)試集群。通過分析線上和測(cè)試環(huán)境兩個(gè)數(shù)據(jù)訪問模塊的日志可以初步判斷 TiDB 數(shù)據(jù)庫是否可以正常處理業(yè)務(wù)請(qǐng)求。當(dāng)然僅僅這樣是不夠的，DBA 同學(xué)還需要校驗(yàn) TiDB 數(shù)據(jù)的正確性（是否與線上 MySQL 庫一致）。驗(yàn)證思路是抽樣驗(yàn)證 MySQL 庫表記錄和 TiDB 的記錄 Checksum 值是否一致。

（2）同步數(shù)據(jù)：DBA 同學(xué)部署 TiDB 集群作為 MySQL 實(shí)例的從庫，將 MySQL 實(shí)例中的聯(lián)系人列表（單實(shí)例分了 1024 個(gè)表）的數(shù)據(jù)同步到 TiDB 的一張大表中。

（3）切流量：切流量分為三步，每?jī)刹街g都有一周左右的觀察期。

第一步將讀流量灰度切到 TiDB 上；

第二步斷開 TiDB 與 MySQL 的主從同步，業(yè)務(wù)開雙寫（同時(shí)寫 MySQL 和 TiDB，保證兩庫數(shù)據(jù)一致）確保業(yè)務(wù)流量可以隨時(shí)回滾到 MySQL；

第三步停止 MySQL 寫入，到此業(yè)務(wù)流量完全切換到 TiDB 數(shù)據(jù)庫上。

遷移過程中最重要的點(diǎn)就是確保兩個(gè)數(shù)據(jù)庫數(shù)據(jù)一致，這樣讀寫流量隨時(shí)可以切回 MySQL，業(yè)務(wù)邏輯不受任何影響。數(shù)據(jù)庫雙寫的方案與上文提到的引流測(cè)試類似，使用消息隊(duì)列引一份寫入流量，TiDB 訪問模塊消費(fèi)消息隊(duì)列數(shù)據(jù)，寫庫。但僅僅這樣是不能保證兩個(gè)庫數(shù)據(jù)一致的，因?yàn)檫@個(gè)方案無法保證兩個(gè)寫庫操作的原子性。所以我們需要一個(gè)更嚴(yán)謹(jǐn)?shù)姆桨福D(zhuǎn)轉(zhuǎn)的消息隊(duì)列還提供了事務(wù)消息的支持，可以保證本地操作和發(fā)送消息的原子性。利用這一特性再加上異步補(bǔ)償策略（離線掃描日志，如果有失敗的寫入請(qǐng)求，修正數(shù)據(jù)）保證每個(gè)消息都被成功消費(fèi)且兩個(gè)庫每次寫入結(jié)果都是一致的，從而保證了 MySQL 與 TiDB 兩個(gè)庫的數(shù)據(jù)一致。

2. 遇到問題

按照上述的方案，我們已經(jīng)將消息所有的業(yè)務(wù)都切到 TiDB 數(shù)據(jù)庫上。遷移過程中也不都是順風(fēng)順?biāo)?，也遇到了問題，過程中也得到了 TiDB 官方團(tuán)隊(duì)的大力支持。這里主要介紹兩個(gè)問題：

（1）TiDB 作為分布式存儲(chǔ)，其鎖機(jī)制和 MySQL 有很大不同。我們有一個(gè)并發(fā)量很大，可能同時(shí)更新一條記錄的場(chǎng)景，我們用了 MySQL 的唯一索引保證了某個(gè) Key 值的唯一性，但如果業(yè)務(wù)請(qǐng)求使用默認(rèn)值就會(huì)大量命中唯一索引，會(huì)造成 N 多請(qǐng)求都去更新統(tǒng)一同一條記錄。在 MySQL 場(chǎng)景下，沒有性能問題，所以業(yè)務(wù)上也沒做優(yōu)化。但當(dāng)我們用這個(gè)場(chǎng)景測(cè)試 TiDB 時(shí)，發(fā)現(xiàn) TiDB 處理不太好，由于其使用的樂觀鎖，數(shù)據(jù)庫輸出大量的重試的日志。業(yè)務(wù)出現(xiàn)幾十秒的請(qǐng)求延遲，造成隊(duì)列中大量請(qǐng)求被拋棄。PingCAP 的同學(xué)建議調(diào)整 retry_limit 但也沒有完全生效（該 BUG 已經(jīng)在 2.0 RC 5 已經(jīng)修復(fù)），最后業(yè)務(wù)進(jìn)行優(yōu)化（過濾使用默認(rèn)值的請(qǐng)求）后問題得到解決。

（2）第二個(gè)問題是運(yùn)維方面的，DBA 同學(xué)按照使用 MySQL 的運(yùn)維經(jīng)驗(yàn)，對(duì)一個(gè)上近 T 的表做了 Truncate操作，操作后，起初數(shù)據(jù)庫表現(xiàn)正常，但幾分鐘后，開始出現(xiàn)超時(shí)，TiKV 負(fù)載變高。最后請(qǐng)教 PingCAP 同學(xué)分析，定位是操作觸發(fā)了頻繁回收 Region 的 BUG（該 BUG TiDB 2.0 版本已經(jīng)修復(fù)）。

1. 隊(duì)列等待情況對(duì)比

使用 TiDB 數(shù)據(jù)庫，業(yè)務(wù)模塊隊(duì)列請(qǐng)求數(shù)基本保持 1 個(gè)，MySQL 會(huì)有較大抖動(dòng)。

2. 請(qǐng)求延遲情況對(duì)比

使用 TiDB 數(shù)據(jù)庫，整體響應(yīng)延時(shí)非常穩(wěn)定，不受業(yè)務(wù)流量高峰影響，但 MySQL 波動(dòng)很大。 另外在擴(kuò)展性方面，我們可以通過無縫擴(kuò)展 TiDB 和 TiKV 實(shí)例提升系統(tǒng)的吞吐量，這個(gè)特性 MySQL 是不具備的。

3. 業(yè)務(wù)延遲和錯(cuò)誤量對(duì)比

接入 TiDB 數(shù)據(jù)庫后業(yè)務(wù)邏輯層服務(wù)接口耗時(shí)穩(wěn)定無抖動(dòng)，且沒有發(fā)生丟棄的情況（上圖錯(cuò)誤大多由數(shù)據(jù)訪問層服務(wù)隊(duì)列堆積發(fā)生請(qǐng)求丟棄造成）。

目前轉(zhuǎn)轉(zhuǎn)線上已經(jīng)接入消息、風(fēng)控兩套 OLTP 以及一套風(fēng)控 OLAP 集群。?

集群架構(gòu)如下：目前轉(zhuǎn)轉(zhuǎn)線上 TiDB 集群的總?cè)萘繋装?TB，線上 TiDB 表現(xiàn)很穩(wěn)定，我們會(huì)繼續(xù)接入更多的業(yè)務(wù)（留言，評(píng)論、搜索、商品、交易等等）。

1. 后續(xù)規(guī)劃

多個(gè)正在開發(fā)的新業(yè)務(wù)在開發(fā)和測(cè)試環(huán)境中使用 TiDB，線上會(huì)直接使用 TiDB；

轉(zhuǎn)轉(zhuǎn)核心的留言、評(píng)論、搜索、商品、交易訂單庫計(jì)劃遷移到 TiDB，已經(jīng)開始梳理業(yè)務(wù)，準(zhǔn)備展開測(cè)試；

計(jì)劃在后續(xù) TiDB 的使用中，TiKV 服務(wù)器池化，按需分配 TiKV 節(jié)點(diǎn)。

2. TiDB 使用成果

利用 TiDB 水平擴(kuò)展特性，避免分庫分表帶來的問題，使得業(yè)務(wù)快速迭代；

TiDB 兼容 MySQL 語法和協(xié)議，按照目前線上 MySQL 使用規(guī)范，可以無縫的遷移過去，無需 RD 做調(diào)整，符合預(yù)期；

在數(shù)據(jù)量較大的情況下，TiDB 響應(yīng)較快，優(yōu)于 MySQL；

集群出現(xiàn)故障對(duì)用戶無感知；

TiDB 自帶了完善的監(jiān)控系統(tǒng)，使得運(yùn)維成本大大降低。

TiDB 助力客如云餐飲 SaaS 服務(wù)

TiDB 在威銳達(dá) WindRDS 遠(yuǎn)程診斷及運(yùn)維中心的應(yīng)用

TiDB 在餓了么歸檔環(huán)境的應(yīng)用