TiDB 在游族網路平台部的深度應用

公司介紹

游族網路股份有限公司（SZ.002174）成立於2009年，是全球領先的互動娛樂供應商。公司以「大數據」、「全球化」、「精品化」為戰略方向，立足全球化遊戲研發與發行，知名 IP 管理，大數據與智能化，泛娛樂產業投資四大業務板塊全面發展。

背景

2017 年初的時候，游族的用戶中心體系面臨迭代和重構，當時資料庫有數億多的核心數據，通過hash key 分為了 1024 張表在 64 個資料庫中來存儲，使用自研的代碼框架來進行對應 hash key 的 seek 操作。這時，非 hash key 的查詢、DDL 變更等業務需求，分表分庫邏輯代碼框架的局限，讓研發和運維都面臨較高的資料庫使用成本，資料庫不能靈活高效的支撐業務需求。

圖1：分庫分表方案架構圖

為了解決上述問題，游族的技術團隊急需一套同時滿足如下的條件的資料庫分散式集群：

• 能夠提供實時的 OLTP 的一致性數據存儲服務；
• 彈性的分散式架構；
• 配套的監控備份方案；
• 穩定的高可用性；
• 較低的遷移重構成本。

前期選擇

最開始先考察了幾個方案，但都有相對來說的不足：

• 方案一，將整個分表分庫邏輯剝離到開源分表分庫中間件上：
• 基於 2PC 的 XA 弱事務的一致性保證不盡如人意；
• 高可用架構更加複雜，單分片的局部不可用會對全局產生影響；
• 備份恢復的複雜度高；
• 這些方案引入了新的 sharding key 和 join key 的設計問題，整體的遷移難度不降反升。
• 方案二，官方的 MySQL cluster 集群：
• ndb 引擎不同於 InnoDB，需要修改表引擎，且實際使用效果未知；
• ndb 的高可用有腦裂風險；
• 監控備份的方案需要另作整理；
• 國內生產用例不多，資料缺乏，非企業版運維流程複雜。

探索

機緣巧合下，與 TiDB 的技術團隊做了一次技術交流，了解到 TiDB 是 PingCAP 受 Google Spanner 的論文啟發設計而來的開源分散式 NewSQL 資料庫，具備如下 NewSQL 特性：

• SQL支持 （TiDB 是 MySQL 兼容的）；
• 水平線性彈性擴展；
• 分散式事務；
• 跨數據中心數據強一致性保證；
• 故障自恢復的高可用；
• 海量數據高並發寫入及實時查詢（HTAP 混合負載）。

上述的特點非常契合目前我們在資料庫應用設計上碰到的問題，於是在與 TiDB 的技術團隊溝通了解後，就開始著手安排部署和測試 TiDB：

• TiDB 的備份目前採用的是邏輯備份，官方提供了一套基於 mydumper 和 myloader 的工具套件；
• 監控用的是應用內置上報 Prometheus 的方案，可以寫腳本與自有的監控系統對接；
• 有狀態的 KV 層採用的是 Raft 協議來保證，Leader 的選舉機制滿足了故障自恢復的需求；
• KV 層的 Region 分裂保證了集群無感知的擴展。

測試之後發現資料庫運維中比較重要的幾項都已經閉環的解決了，實測結論是：

• TiDB 是分散式結構，有網路以及多副本開銷，導致 Sysbench OLTP 測試中 TiDB 單 server 的讀性能不如 MySQL，但寫優於 MySQL，且彈性擴展能力評估後可以滿足業務的峰值需求；
• TiDB 的 OLAP 能力在大數據量下遠優於 MySQL，且能看到持續的大幅提升；
• 由於 TiDB-Server 是無狀態的，後續可以添加 Load Balance 來擴展 Server 層的支撐。

持續引入

在性能和需求滿足前提下，就開始著手業務層的接入和改造： MySQL 協議的兼容這時候極大的降低了遷移到 TiDB 的成本，官方的 TiDB 同步 MySQL 的 Syncer 工具也給了接入和改造有力的支持，部分遷移在業務層就是一次 MySQL 的主從切換。

於是，用戶積分系統的擴展便不再採用分表分庫的方案，分表邏輯回歸到多個獨立的單表，數億的數據在 OLTP 的業務場景下表現十分出色，沒有 sharding key 的約束後，整個使用邏輯在上層看來和 MySQL 單表沒有不同，更加靈活的索引也提供了一部分低開銷的 OLAP 的查詢能力，整體的遷移改造流程比較順利，業務契合度很高。

隨著上述系統的成功應用後，後面符合場景的 OLTP 項目也逐漸開始使用 TiDB：

• 登錄態系統：原先的在 MySQL 採用 Replace 保留最後一條數據，遷移到 TiDB 的模式後，由於表的伸縮能力獲得了很大的提升，故將 Replace 改為了 Insert 保留了所有的登錄情況，單表數據量十億以上，業務上支持了更多維度的記錄，沒有碰到性能和擴展性問題；
• 禮包碼系統：禮包碼的主流程為複雜度 O(1) 的 hash seek OLTP業務，經過 TiDB 的改造後，將原來的 100 個表的分表模式集中成單表管理，單表數據預計會達到 20 億+；
• 用戶軌跡項目：資料庫彈性能力增長後的新需求，一些重要的用戶行為數據的記錄。

同時，在 kv 存儲層沒有瓶頸的時候，採用復用了集群的 kv 層的策略，在無狀態的 Server 層做了業務隔離，間接的提升了整個集群的使用率，類似一個 DBaaS 的服務（圖2）。

圖2：多套業務系統 TiDB 部署圖

RC2.2 -> GA1.0 -> GA1.1

從 RC2.2 版本到 GA1.0，游族平台部的生產環境已經有 3 套 TiDB 集群在運行，共計支撐了 6 個 OLTP 業務的穩定運行快一年的時間。 期間 PingCAP 團隊提供了非常多的技術支持：集群部署策略、BUG 響應和修復、升級方案協助、遷移工具支持等，廠商和開源社區都非常活躍。

從 RC2.2 開始，從性能優化到細小的 SQL 兼容性 BUG 修復，每個版本都能看到開發團隊對 roadmap 的細緻規劃和態度。TiDB 也在廠商和社區打磨下，性能和穩定性逐漸提升，兼容性也越來越好。

現在官方已經發布 GA1.1 的 alpha 版本，重構了 TiDB 的優化器，我們也在第一時間做了詳細的測試，目前大部分 OLAP 性能比 GA1.0 要提升 1~2 倍，不得不感慨 TiDB 的演進速度，也期待 1.1 的正式發布。

計劃和期望

我們與 TiDB 團隊的溝通中了解到補充 TiDB-Server 的重 OLAP 需求的 TiSpark 計算層已經比較成熟了，後面計劃分析型的需求也會嘗試使用 TiSpark 來進行計算。

同時我們與 TiDB 團隊在交流的時候也得知分區表，視圖等功能都已經在計劃中，後續 TiDB 的數據存儲方式將會越來越靈活。

經過內部的實際使用後，後續已經有數個符合業務場景在評估或計劃使用 TiDB 做為 OLTP 存儲層的支撐。TiDB 給了大庫大表業務的一個全新的選擇方向，相信 TiDB 以後能在更多的業務選型和設計方案上給出新的方向和思路。

? 作者：陶政，游族網路平台部 MySQL DBA 負責人。曾任同程旅遊系統架構組 DBA，現負責游族網路資料庫整體的運維規劃和設計。熟悉各類業務的資料庫設計、緩存設計、離線數據分析等解決方案。