導讀
作業幫是一家成立於 2015 年的在線教育品牌，致力於用科技手段助力教育普惠。經過近十年的積累，作業幫運用人工智能、大數據等技術，爲學生、老師、家長提供學習、教育解決方案，智能硬件產品等。隨着公司產品和業務場景越來越豐富，數據量越來越大，業務方對數據庫的使用需求也越來越多元化。本文介紹了作業幫對 TiDB 的探索歷程，以及逐漸落地多個業務場景的使用實踐。
TiDB 在作業幫的探索和推廣
作業幫內部最開始接觸的版本是 TiDB v4.0.9。相較於 TiDB v3.x，v4.0.9 在性能、管理、易用性等方面都有了質的提升，同時 TiDB 的生態組件以及社區也都達到了非常完善的程度，可以說是一個標誌性的版本。2020 年，我們正式開始調研測試 TiDB v4.0.9, 以實現團隊在分佈式數據庫的技術儲備，從而更好地服務公司的業務需求。
1. 探索期: 使用 TiDB 隔離對在線 MySQL 集羣有性能影響的查詢請求
研發人員需要不定時查詢線上實時數據，以此來確定業務數據的情況或者對部分業務數據做彙總分析。
● 引入 TiDB 之前：業務人員是直連到 MySQL 從庫查詢數據，如果掃描的數據量太大經常會引起線上 MySQL 節點性能抖動甚至機器的 io/cpu 資源瓶頸。
● 引入 TiDB 之後：通過數據同步工具 DM 將 MySQL 的數據以全量+實時增量的方式同步到 TiDB 中，實現在線、離線請求的隔離性。
在這個探索階段，一方面滿足了離線查詢的隔離性的要求，另一方面也熟悉了 TiDB 及其生態組件的特性以及使用方法。
2、推廣期：內部分享+主動出擊
經過半年左右時間的使用，在對 TiDB 有一定了解的基礎上，我們開始在公司內部進行 TiDB 相關的技術分享，向研發人員介紹 TiDB 的一些特性和在大數據量場景下的優勢，並主動接觸各個業務線去尋找合適的使用場景。研發人員也陸續將一些業務 內部使用的報表服務 接入到離線 TiDB 集羣中。
在線業務落地從 0-1
在各個團隊使用和熟悉 TiDB 一段時間後，我們開始針對已有業務的痛點或者未來新業務的規劃，逐漸將視野轉移到 TiDB。通過配合業務一起測試驗證，開始正式將在線業務遷移到 TiDB 中。
1、報表平臺使用 TiDB 突破存儲&性能瓶頸
作業幫的報表服務每天要導入大量來自各個業務線的文件數據，來實現最終的數據大盤展示。隨着業務線越來越多以及 MySQL 單實例主機的磁盤限制，報表服務平臺逐漸顯現出存儲受限以及數據展示響應慢，甚至無法響應等問題。
我們通過 DM 將數據同步到 TiDB 中，經過業務驗證，TiDB 對 SQL 達到了高度兼容性。同時，對比使用 MySQL 的耗時，TiDB 減少 80% 的時間，效果遠超預期。隨着 DM 同步穩定性的提高，報表平臺也將一些直連線上 MySQL 的報表服務改成使用 TiDB 作爲數據源。
經過改造，報表服務最終架構如下:
2、業務流水數據
業務流水數據業務的主要特點是每日寫入數據量特別大，而且需要保存時間比較長。在公司的多個業務線中，只要是發展到一定階段，使用 MySQL 存儲的數據最終都會遇到存儲瓶頸。此時 TiDB 便是非常好的一種解決方案。
在線業務落地從1-N
得益於 DM 同步數據的可靠性以及後面 TiDB-5.x 版本的兼容性、穩定性，作業幫有些業務逐漸將性能採集數據、用戶訪問記錄、業務日誌等業務也遷移到 TiDB。同時，在人工智能爆發的背景下，越來越多的探索性業務天然需要存儲海量的數據，TiDB 自然成爲首選方案。當然，線上還有很多核心業務不會輕易更換數據存儲方案，那麼對歷史數據的歸檔使用 TiDB 也是目前的標準方案。
從 TiDB 4.0 版本開始，TiDB 加入了 TiFlash 列存引擎，並且在之後的版本中不斷增強。如果業務有任何複雜查詢需求，直接就可以在 TiDB 集羣裏通過增加 TiFlash 節點解決一些比較複雜的查詢。
總結以及未來展望
現在，TiDB 在作業幫內部使用中已經可以獨當一面了。目前，作業幫已經部署了幾十套 TiDB 集羣，總體數據量規模超過百 TB。在這些集羣中，大部分採用的是 TiDB 5.4 版本，有一半已經升級到 6.5 版本。如果大家還在用 v3.x 版本的話，建議可以採用一些比較保險的方法測試升級到新的版本。作業幫從 v4.0.9 版本一路不斷升級上來，整體感受是越來越穩定，讓人比較安心，升級過程也非常絲滑，業務幾乎沒有任何感知。
最近有看到消息說杭州銀行已經在覈心賬務系統上線 TiDB 6.5.6 版本，到 2024 年我們應該也會全部升級到這個版本。
最後，也說一下對 TiDB 的希望：
- 希望 TiDB 能有不依賴於 CDC 的主備集羣方案，一方面可以做異地機房的災備，另一方面可以作爲升級回滾的方案，避免升級之後出現業務不兼容的情況；
- 探索使用資源管控方案 (Resource Control)。對於 MySQL 分庫分表的業務，無法將多個分集羣同步到同一個 TiDB 集羣，會出現庫名衝突的情況；
- SQL 限流或者攔截功能：對於資源消耗異常高的 SQL，可以自動進行降級處理，避免將集羣資源耗盡，集羣雪崩。