TiDB 在 Mobikok 廣告系統中的應用和實踐

來自專欄 TiDB 的後花園

公司介紹

Mobikok（可可網路）成立於 2013 年，是一家快速成長的移動互聯網營銷公司，專註於移動 eCPM 營銷。總部在中國深圳，聚焦於訂閱 offer 的海外流量變現業務。Mobikok 提供的介面方式支持各類手機端流量（API、SDK、Smartlink），RTB（實時競價系統）對接海外的 DSP（Demand-Side Platform，需求方平台）高效優化客戶的廣告效果。截止目前，系統已對 2 億用戶進行廣告優化，已接入上百家廣告主以及上百家渠道，Mobikok 致力於高效，便捷，專業的幫助廣告主以及渠道互惠共贏。

SSP 系統

訂閱 SSP（Sell-Side-Platform） 平台當前業務主要分為：SDK、Smartlink、Online API 以及 Offline API；在當前 SSP SDK 業務系統當中，累計用戶已達到 2 億，最初使用的是 MySQL 主從分表的方式存儲用戶數據，隨著數據量的增加，MySQL 單機容量以及大數據量查詢成為了瓶頸；當單表數據達到 2 千萬以上時，單機 MySQL 的查詢以及插入已經不能滿足業務的需求，當訪問量到一定階段後，系統響應能力在資料庫這一塊是一個瓶頸。

一次很偶然的機會在 GitHub 上面了解到 TiDB，並且因為現在業務系統當中使用的 Redis 集群是 Codis，已在線上穩定使用兩年，聽聞 TiDB 創始團隊就是之前 Codis 的作者，所以對 TiDB 有了極大的興趣並且進行測試。通過測試單機 MySQL 和 TiDB 集群，當數據量達到數千萬級別的時候發現 TiDB 效率明顯高於 MySQL。所以就決定進行 MySQL 到 TiDB 的遷移。

遷移後整體架構圖：

引入 TiDB

在選擇使用替換 MySQL 方案當中。我們主要考慮幾點：

• 支持 MySQL 便捷穩定的遷移，不影響線上業務；
• 高度兼容 MySQL，少改動代碼；
• 支持水平彈性部署服務以及在線升級；
• 支持水平擴展業務；
• 成熟的配套監控服務。

TiDB 資料庫整體集群配置：2*TiDB、3*TiKV、3*PD。

從 12 月初正式上線到目前為止，TiDB 穩定運行四個多月，最高 QPS 達到 2000，平均 QPS 穩定在 500 左右。TiDB 在性能、可用性、穩定性上完全超出了我們的預期。但是由於前期我們對 TiDB 的了解還不深，在此遷移期間碰到的一些兼容性的問題，比如 TiDB 的自增 ID 的機制，排序的時候需要使用欄位名等，諮詢 TiDB 的工程師都很快的得到了解決，非常感謝 TiDB 團隊的支持以及快速響應。

下圖是當前集群的 Grafana 展示圖：

後續計劃

使用 TiDB 對於像我們這樣可預期核心數據會暴增的場景，有非常大的意義。在後端支撐力量有限時，業務暴增時只需要增加機器，而不是頻繁重構業務，讓我們有更多精力在自己的業務上耕耘，增加我們的行業競爭力。未來我們還有 ADX（Ad Exchang，廣告交易平台） 和 DSP 業務，需要處理海量的用戶數據以及廣告數據。目前統計數據這一塊當前業務當中使用的是 Spark Streaming，通過和 TiDB 開發團隊溝通，官方 TiSpark 可直接引入到當前統計 Spark 群集當中，非常期望在後續開發當中使用 TiSpark。

問題建議

在實際應用當中，因為我們切換的並不是只有用戶數據表，還遷移了關於廣告業務、渠道業務基礎數據表。由於 TiDB 是一個分散式資料庫，對於一些小表以及 count(*) 操作會影響效率，後來諮詢 TiDB 官方得知，TiDB 有不同的隔離級別，SQL 也有高低優先順序，如果有全表掃描的需求，可以使用低的隔離級別或者是低的優先順序。將來我們就可以直接所有線上業務使用 TiDB 進行替換，最後還是非常感謝 TiDB 團隊的支持與幫助。

作者：rayi，深圳可可網路服務端架構負責人

推薦閱讀：