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

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

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

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

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

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

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

風控系統：風控日志數據庫是我們最早上線的一個 TiDB 集群，稍后詳細展開。

審計日志系統：審計日志數據庫存儲每一個電商訂單的支付和物流等狀態變化日志。

本文將重點展開風控日志數據庫選型和上線的過程，后面也會約略提及上線后系統擴容和性能監控狀況。

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

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

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

優點：繼續使用 MySQL 數據庫 ，不論開發團隊還是 DBA 團隊都駕輕就熟。

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

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

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

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

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

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

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

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

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

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

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

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

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

TiKV 節點

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

內存: 192GB

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

網卡: 2 * 10gbps NIC Bonding

PD 節點和 SQL 節點

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

內存: 64GB

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

網卡: 2 * 10gbps NIC Bonding

截至目前，系統已經平穩運行了六個多月，數據量增長至 35TB（如圖 4 所示），經歷了兩次擴容后現在集群共包含 42 個節點。

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

盡管數據量較之 6 個月前漲了 8 倍，目前整個集群的查詢響應質量仍然良好，大部分時間 pct99 響應時間（如圖 6 所示）都小于 60ms。對于以大型復雜 SQL 查詢為主的風控系統而言，這個級別的響應時間已經足夠好了。

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

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

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

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

TiDB v1.x 版本需要定期手動執行 Analyze Table 以確保元信息準確。PingCAP 的同學告訴我們說：當 (Modify_count / Row_count) 大于 0.3 就要手動 Analyze Table 了。v2.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 數據庫未來實現彈性水平擴容和分布式事務的關鍵組件。當前我們正在努力讓更多 Shopee 業務使用 TiDB。

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

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

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

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

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

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