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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

停止雙寫：遷移過程至此結束。

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

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

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

TiKV 節(jié)點

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é)點和 SQL 節(jié)點

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)運行了六個多月，數(shù)據(jù)量增長至 35TB（如圖 4 所示），經(jīng)歷了兩次擴容后現(xiàn)在集群共包含 42 個節(jié)點。

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

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

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

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

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

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

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

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 會成為 Shopee 數(shù)據(jù)庫未來實現(xiàn)彈性水平擴容和分布式事務的關鍵組件。當前我們正在努力讓更多 Shopee 業(yè)務使用 TiDB。

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

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

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

感謝 PingCAP 的同學一年來對我們的幫助和支持。每一次我們在微信群里提問，都能快速獲得回應。官方架構師同學還不辭辛勞定期和我們跟進，詳細了解項目進度和難點，總是能給出非常棒的建議。

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

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