摘要：作者介紹劉春輝，洪超，一業(yè)務(wù)場景是東南亞和臺(tái)灣地區(qū)領(lǐng)先的電子商務(wù)平臺(tái)，覆蓋新加坡馬來西亞菲律賓印度尼西亞泰國越南和臺(tái)灣等七個(gè)市場。母公司為首家在紐約證券交易所上市的東南亞互聯(lián)網(wǎng)企業(yè)。

作者介紹
劉春輝，Shopee DBA
洪超，Shopee DBA

Shopee（https://shopee.com/）是東南亞和臺(tái)灣地區(qū)領(lǐng)先的電子商務(wù)平臺(tái)，覆蓋新加坡、馬來西亞、菲律賓、印度尼西亞、泰國、越南和臺(tái)灣等七個(gè)市場。Shopee 母公司 Sea（https://seagroup.com/）為首家在紐約證券交易所上市的東南亞互聯(lián)網(wǎng)企業(yè)。2015 年底上線以來，Shopee 業(yè)務(wù)規(guī)模迅速擴(kuò)張，逐步成長為區(qū)域內(nèi)發(fā)展最為迅猛的電商平臺(tái)之一：

截止 2018 年第三季度 Shopee APP 總下載量達(dá)到 1.95 億次，平臺(tái)賣家數(shù)量超過 700 萬。

2018 年第一季度和第二季度 GMV 分別為 19 億美金和 22 億美金，2018 上半年的 GMV 已達(dá)到 2017 全年水平。2018 年第三季度 GMV 達(dá)到了創(chuàng)紀(jì)錄的 27 億美元, 較 2017 年同期年增長率為 153%。

2018 年雙 11 促銷日，Shopee 單日訂單超過 1100 萬，是 2017 年雙 11 的 4.5 倍；剛剛過去的雙 12 促銷日再創(chuàng)新高，實(shí)現(xiàn)單日 1200 萬訂單。

我們從 2018 年初開始調(diào)研 TiDB，6 月份上線了第一個(gè) TiDB 集群。到目前為止我們已經(jīng)有兩個(gè)集群、60 多個(gè)節(jié)點(diǎn)在線運(yùn)行，主要用于以下 Shopee 業(yè)務(wù)領(lǐng)域：

風(fēng)控系統(tǒng)：風(fēng)控日志數(shù)據(jù)庫是我們最早上線的一個(gè) TiDB 集群，稍后詳細(xì)展開。

審計(jì)日志系統(tǒng)：審計(jì)日志數(shù)據(jù)庫存儲(chǔ)每一個(gè)電商訂單的支付和物流等狀態(tài)變化日志。

本文將重點(diǎn)展開風(fēng)控日志數(shù)據(jù)庫選型和上線的過程，后面也會(huì)約略提及上線后系統(tǒng)擴(kuò)容和性能監(jiān)控狀況。

風(fēng)控系統(tǒng)基于大量歷史訂單以及用戶行為日志，以實(shí)時(shí)和離線兩種方式識別平臺(tái)上的異常行為和欺詐交易。它的重要數(shù)據(jù)源之一是各種用戶行為日志數(shù)據(jù)。最初我們將其存儲(chǔ)于 MySQL 數(shù)據(jù)庫，并按照 USER_ID 把數(shù)據(jù)均分為 100 個(gè)表。隨著 Shopee 用戶活躍度見長，數(shù)據(jù)體積開始瘋長，到 2017 年底磁盤空間顯得十分捉襟見肘了。作為應(yīng)急措施，我們啟用了 InnoDB 表透明壓縮將數(shù)據(jù)體積減半；同時(shí)，我們把 MySQL 服務(wù)器磁盤空間從 2.5TB 升級到了 6TB。這兩個(gè)措施為后續(xù)遷移 MySQL 數(shù)據(jù)到 TiDB 多爭取了幾個(gè)月時(shí)間。

關(guān)于水平擴(kuò)容的實(shí)現(xiàn)方案，當(dāng)時(shí)內(nèi)部有兩種意見：MySQL 分庫分表和直接采用 TiDB。

基本思路：按照 USER_ID 重新均分?jǐn)?shù)據(jù)（Re-sharding），從現(xiàn)有的 100 個(gè)表增加到1000 個(gè)甚至 10000 個(gè)表，然后將其分散到若干組 MySQL 數(shù)據(jù)庫。

優(yōu)點(diǎn)：繼續(xù)使用 MySQL 數(shù)據(jù)庫 ，不論開發(fā)團(tuán)隊(duì)還是 DBA 團(tuán)隊(duì)都駕輕就熟。

缺點(diǎn)：業(yè)務(wù)代碼復(fù)雜度高。Shopee 內(nèi)部若干個(gè)系統(tǒng)都在使用該數(shù)據(jù)庫，同時(shí)我們還在使用 Golang 和 Python 兩種編程語言，每一個(gè)系統(tǒng)都要改動(dòng)代碼以支持新的分庫分表規(guī)則。

基本思路：把數(shù)據(jù)從 MySQL 搬遷至 TiDB，把 100 個(gè)表合并為一個(gè)表。

優(yōu)點(diǎn)：數(shù)據(jù)庫結(jié)構(gòu)和業(yè)務(wù)邏輯都得以大幅簡化。TiDB 會(huì)自動(dòng)實(shí)現(xiàn)數(shù)據(jù)分片，無須客戶端手動(dòng)分表；支持彈性水平擴(kuò)容，數(shù)據(jù)量變大之后可以通過添加新的 TiKV 節(jié)點(diǎn)實(shí)現(xiàn)水平擴(kuò)展。理想狀況下，我們可以把 TiDB 當(dāng)做一個(gè)「無限大的 MySQL」來用，這一點(diǎn)對我們極具誘惑力。

缺點(diǎn)：TiDB 作為新組件首次引入 Shopee 線上系統(tǒng)，我們要做好「踩坑」的準(zhǔn)備。

最后，我們決定采用 TiDB 方案，在 Shopee 內(nèi)部做「第一個(gè)吃螃蟹的人」。風(fēng)控日志數(shù)據(jù)庫以服務(wù)離線系統(tǒng)為主，只有少許在線查詢；這個(gè)特點(diǎn)使得它適合作為第一個(gè)遷移到 TiDB 的數(shù)據(jù)庫。

我們的上線步驟大致如下：

應(yīng)用程序開啟雙寫：日志數(shù)據(jù)會(huì)同時(shí)寫入 MySQL 和 TiDB。

搬遷舊數(shù)據(jù)：把舊數(shù)據(jù)從 MySQL 搬到 TiDB，并完成校驗(yàn)確保新舊數(shù)據(jù)一致。

遷移只讀流量：應(yīng)用程序把只讀流量從 MySQL 逐步遷移至 TiDB（如圖 3 所示）。

停止雙寫：遷移過程至此結(jié)束。

雙寫方式使得我們可以把整個(gè)切換過程拖長至幾個(gè)月時(shí)間。這期間開發(fā)團(tuán)隊(duì)和 DBA 團(tuán)隊(duì)有機(jī)會(huì)逐步熟悉新的 TiDB 集群，并充分對比新舊數(shù)據(jù)庫的表現(xiàn)。理論上，在雙寫停掉之前，若新的 TiDB 集群遭遇短時(shí)間內(nèi)無法修復(fù)的問題，則應(yīng)用程序有可能快速回退到 MySQL。

除此之外，采用雙寫方式也讓我們有了重構(gòu)數(shù)據(jù)庫設(shè)計(jì)的機(jī)會(huì)。這一次我們就借機(jī)按照用戶所屬地區(qū)把風(fēng)控日志數(shù)據(jù)分別存入了七個(gè)不同的邏輯數(shù)據(jù)庫：rc_sg，rc_my，rc_ph，…，rc_tw。Shopee 用戶分布于七個(gè)不同地區(qū)。遷移到 TiDB 之前，所有日志數(shù)據(jù)共存于同一個(gè)邏輯數(shù)據(jù)庫。按照地區(qū)分別存儲(chǔ)使得我們能夠更為方便地為每個(gè)地區(qū)的日志定制不同的數(shù)據(jù)結(jié)構(gòu)。

上線之初我們一共從 MySQL 遷移了大約 4TB 數(shù)據(jù)到 TiDB 上。當(dāng)時(shí) TiDB 由 14 個(gè)節(jié)點(diǎn)構(gòu)成，包括 3 個(gè) PD 節(jié)點(diǎn)，3 個(gè) SQL 節(jié)點(diǎn)和 8 個(gè) TiKV 節(jié)點(diǎn)。服務(wù)器硬件配置如下：

TiKV 節(jié)點(diǎn)

CPU: 2 * Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz, 40 cores

內(nèi)存: 192GB

磁盤: 4 * 960GB Read Intensive SAS SSD Raid 5

網(wǎng)卡: 2 * 10gbps NIC Bonding

PD 節(jié)點(diǎn)和 SQL 節(jié)點(diǎn)

CPU: 2 * Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz, 40 cores

內(nèi)存: 64GB

磁盤: 2 * 960GB Read Intensive SAS SSD Raid 1

網(wǎng)卡: 2 * 10gbps NIC Bonding

截至目前，系統(tǒng)已經(jīng)平穩(wěn)運(yùn)行了六個(gè)多月，數(shù)據(jù)量增長至 35TB（如圖 4 所示），經(jīng)歷了兩次擴(kuò)容后現(xiàn)在集群共包含 42 個(gè)節(jié)點(diǎn)。

風(fēng)控日志數(shù)據(jù)庫的日常 QPS（如圖 5 所示）一般低于每秒 20K，在最近的雙 12 促銷日我們看到峰值一度攀升到了每秒 100K 以上。

盡管數(shù)據(jù)量較之 6 個(gè)月前漲了 8 倍，目前整個(gè)集群的查詢響應(yīng)質(zhì)量仍然良好，大部分時(shí)間 pct99 響應(yīng)時(shí)間（如圖 6 所示）都小于 60ms。對于以大型復(fù)雜 SQL 查詢?yōu)橹鞯娘L(fēng)控系統(tǒng)而言，這個(gè)級別的響應(yīng)時(shí)間已經(jīng)足夠好了。

TiDB 的字符串匹配區(qū)分大小寫（Case Sensitive）。目前尚不支持 Case Insensitive 方式。應(yīng)用程序做了適配以實(shí)現(xiàn) Case Insensitive 方式的字符串匹配。

TiDB 對于 MySQL 用戶授權(quán) SQL 語法的兼容支持尚不完善。例如，目前不支持 SHOW CREATE USER 語法，有時(shí)候不得不讀取系統(tǒng)表（mysql.user）來查看一個(gè)數(shù)據(jù)庫賬戶的基本信息。

添加 TiKV 節(jié)點(diǎn)后需要較長時(shí)間才能完成數(shù)據(jù)再平衡。據(jù)我們觀察，1TB 數(shù)據(jù)大約需要 24 個(gè)小時(shí)才能完成拷貝。因此促銷前我們會(huì)提前幾天擴(kuò)容和觀察數(shù)據(jù)平衡狀況。

TiDB v1.x 版本以 region 數(shù)目為準(zhǔn)在各個(gè) TiKV 節(jié)點(diǎn)之間平衡數(shù)據(jù)。不過每個(gè) region 的大小其實(shí)不太一致。這個(gè)問題導(dǎo)致不同 TiKV 節(jié)點(diǎn)的磁盤空間使用率存在明顯差異。據(jù)說新的 TiDB v2.x 對此已經(jīng)做了優(yōu)化，我們未來會(huì)嘗試在線驗(yàn)證一下。

TiDB v1.x 版本需要定期手動(dòng)執(zhí)行 Analyze Table 以確保元信息準(zhǔn)確。PingCAP 的同學(xué)告訴我們說：當(dāng) (Modify_count / Row_count) 大于 0.3 就要手動(dòng) Analyze Table 了。v2.x 版本已經(jīng)支持自動(dòng)更新元數(shù)據(jù)了。我們后續(xù)會(huì)考慮升級到新版本。

mysql> show stats_meta where db_name = "aaa_db"  G

*************************** 1. row ***************************

     Db_name: aaa_db

  Table_name: xxx_tab

 Update_time: 2018-12-16 23:49:02

Modify_count: 166545248

   Row_count: 8568560708

1 row in set (0.00 sec)

過去一年親密接觸之下，我們對 TiDB 的未來充滿信心，相信 TiDB 會(huì)成為 Shopee 數(shù)據(jù)庫未來實(shí)現(xiàn)彈性水平擴(kuò)容和分布式事務(wù)的關(guān)鍵組件。當(dāng)前我們正在努力讓更多 Shopee 業(yè)務(wù)使用 TiDB。

我們規(guī)劃把 Shopee 數(shù)據(jù)從 MySQL 遷移到 TiDB 上的路線是「先 Non-transactional Data（非交易型數(shù)據(jù)），后 Transactional Data（交易型數(shù)據(jù)）」。目前線上運(yùn)行的集群都屬于 Non-transactional Data，他們的特點(diǎn)是數(shù)據(jù)量超大（TB 級別），寫入過程中基本不牽涉數(shù)據(jù)庫事務(wù)。接下來我們會(huì)探索如何把一些 Transactional Data 遷移到 TiDB 上。

MySQL Replica 是另一個(gè)工作重點(diǎn)。MySQL Replica 指的是把 TiDB 作為 MySQL 的從庫，實(shí)現(xiàn)從 MySQL 到 TiDB 實(shí)時(shí)復(fù)制數(shù)據(jù)。我們最近把訂單數(shù)據(jù)從 MySQL 實(shí)時(shí)復(fù)制到 TiDB。后續(xù)來自 BI 系統(tǒng)以及部分對數(shù)據(jù)實(shí)時(shí)性要求不那么高的只讀查詢就可以嘗試改為從 TiDB 讀取數(shù)據(jù)了。這一類查詢的特點(diǎn)是全表掃描或者掃描整個(gè)索引的現(xiàn)象較多，跑在 TiDB 可能比 MySQL 更快。當(dāng)然，BI 系統(tǒng)也可以借助 TiSpark 繞過 SQL 層直接讀取 TiKV 以提升性能。

目前我們基于物理機(jī)運(yùn)行 TiDB 集群，DBA 日常要耗費(fèi)不少精力去照顧這些服務(wù)器的硬件、網(wǎng)絡(luò)和 OS。我們有計(jì)劃把 TiDB 搬到 Shopee 內(nèi)部的容器平臺(tái)上，并構(gòu)建一套工具實(shí)現(xiàn)自助式資源申請和配置管理，以期把 DBA 從日常運(yùn)維的瑣碎中解放出來。

感謝 PingCAP 的同學(xué)一年來對我們的幫助和支持。每一次我們在微信群里提問，都能快速獲得回應(yīng)。官方架構(gòu)師同學(xué)還不辭辛勞定期和我們跟進(jìn)，詳細(xì)了解項(xiàng)目進(jìn)度和難點(diǎn)，總是能給出非常棒的建議。

PingCAP 的文檔非常棒，結(jié)構(gòu)層次完整清晰，細(xì)節(jié)翔實(shí)，英文文檔也非常扎實(shí)。一路跟著讀下來，受益良多。

TiDB 選擇了 Golang 和 RocksDB，并堅(jiān)信 SSD 會(huì)在數(shù)據(jù)庫領(lǐng)域取代傳統(tǒng)機(jī)械硬盤。這些也是 Shopee 技術(shù)團(tuán)隊(duì)的共識。過去幾年間我們陸續(xù)把這些技術(shù)引入了公司的技術(shù)棧，在一線做開發(fā)和運(yùn)維的同學(xué)相信都能真切體會(huì)到它們?yōu)?Shopee 帶來的改變。