本文根據 PingCAP DevCon 2021 上來自微眾銀行資深資料庫架構師黃蔚的分享整理而成，主要闡述 TiDB 在微眾銀行的應用實踐，包括微眾銀行選擇 TiDB 的背景和 TiDB 的部署架構，以及 TiDB 在貸款核心批量場景的應用，最後分享了基於 TiDB 優化方案的最佳實踐和未來規劃。
TiDB 的產品優勢
從 2018 年底微眾銀行開始接觸 TiDB 的團隊，到 2019 年上線，TiDB 在資料庫的選型之中展現了很多獨有的優勢。
TiDB 相容 MySQL 協議，同時也相容 MySQL 的生態工具，比如備份、恢復、監控等等，不管是應用本身還是運維或是開發人員，從 MySQL 遷移到 TiDB，其成本和門檻都較低。對於 TiDB 原生的計算、儲存分離的架構，使用者將不必擔心容量或者單機效能的瓶頸，某種程度可以把 TiDB 當作一個很大的 MySQL 來使用。同時 TiDB 的資料多副本強一致的特性對金融場景來說十分重要，TiDB 還天然支援多 IDC 的部署架構，可以支援應用做到同城多活的部署架構。此外，TiDB 開源社群的運營也非常活躍，比如在 AskTUG 平臺可以看到很多使用者的典型問題的處理方法，包含大量的寶貴經驗可以借鑑，可以進一步降低使用者使用 TiDB 的門檻。
現在使用 TiDB 的使用者越來越多，不管是網際網路頭部廠商或者金融行業使用者都在大量使用，這也是 TiDB 產品越來越成熟的體現，也給更多使用者使用 TiDB 帶來了更強的信心。
TiDB 在微眾銀行的部署架構
TiDB 的特性是否能夠滿足金融機構高可用的架構需求？
這是 TiDB 在微眾銀行的部署架構，如圖所示，首先 TiKV 選擇三副本，分別部署在同城的三個資料中心，這樣可以實現 IDC 級別的高可用，同時在每個 IDC 部署了一套 TiDB Server，通過繫結到負載均衡器提供 VIP 服務，這樣使得應用可以做到多活接入的模式。這套架構也經受過 IDC 級別的真實故障的演練驗證，將其中一個 IDC 的網路全部斷掉，觀察到叢集可以快速恢復，我們認為TiDB 能夠符合金融場景高可用的要求。
核心批量核算場景
貸款核心批量核算是金融行業比較經典且非常重要的場景，我們將其接入到了 TiDB。下圖是之前微眾銀行貸款核心批量應用場景的架構，左邊這部分有很多業務單元，相當於把使用者的資料做了單元化拆分，每一個單元化資料可能不一樣，但架構和部署模型是一樣的，底層用的是單例項資料庫，同時批量是在每一個單例項資料庫上面執行，最終把批量結果 ETL 到大資料平臺給下游使用，那麼這個架構有哪些瓶頸或者優化點呢？
它是一個純批量的應用，意味著有大量的批量的寫入、更新以及運算，而且資料量都特別大，億級或者十億級別以上，隨著業務快速開展，借據數、使用者數和流水資料也在持續增漲，如果使用單機資料庫來承載，首先受限於單機資料庫的效能上限，跑批耗時會越來越長，而且之前單機資料庫負載已經很高，IO、CPU 已經達到 70% ~ 80%，如果想提升跑批效率，應用通過增加併發的方式是有風險的，因為資料庫負載太高可能造成主備複製延遲或者遇到故障無法進行快速主備切換，所以效率很難提升；其次單機資料庫對這種億級或者十億級的表加欄位或者資料管理難度非常大，雖然微眾銀行日常會用 online DDL 工具比如 pt-online-schema-change 來做表變更操作，但也會有小概率鎖表風險。另外基於資源利用率考慮，批量系統和聯機系統複用了同一套單機資料庫，所以如果批量任務造成高負載，很可能會影響聯機交易。基於這些背景問題，微眾銀行藉助 TiDB 做了架構優化的升級。
升級改造後的架構如下圖所示，可以看到微眾銀行把各個業務單元的資料通過 DM 工具把資料實時同步和彙總到 TiDB，然後批量 APP 直接基於 TiDB 做批量計算，再把結果傳到大資料平臺，相當於藉助了 TiDB 的水平擴充套件性來達到批量效率的水平擴充套件。之前是傳統的 MySQL 主備架構，會要求 APP 伺服器 要跟 MySQL 的主節點是部署在同一個 IDC，而如果是跨機房訪問，網路延時會比較大進而影響批量耗時，所以其他 IDC 的 APP伺服器 就處於 standby 的狀態，會有一定的資源浪費，而 TiDB 架構的所有 TiKV 節點可以同時讀寫，所以可以多個 IDC 同時啟動批量任務，最大化資源利用率。
價值收益
TiDB 在微眾銀行貸款核心業務場景中的使用，總結有三個主要的價值收益。
1.批量效率的提高。下圖左邊是微眾銀行其中一個貸款業務的賬單日的批量耗時對比，可以看到在單例項架構下面，批量大概是跑三個多小時，而微眾銀行通過藉助 TiDB 進行架構的升級優化後，耗時減少到了 30 分鐘左右，有絕對效率上的提升。
2.線性水平擴充套件。微眾銀行的需求不僅僅是效率提升，而且要求其做到水平擴充套件，也就是彈性伸縮。因為隨著業務發展，借據量包括使用者量在持續增長，如果存在熱點或者其他瓶頸，以後想繼續提升將十分困難，下圖右邊是展示其批量耗時的對比情況，在初始的一個資源情況下大概跑 25 分鐘，如果資料量翻倍，耗時增加到 50 分鐘，如果想把這個耗時降下來再把資源也翻倍，可以發現耗時又降回到 26 分鐘左右，可見已經具備線性擴充套件能力。所以除了效率上的提升，線性擴充套件能力的一大好處就是隨著業務持續的發展，借據數、借據量都在快速增長，這套架構將無需擔心業務快速增長可能出現的技術瓶頸，業務可以更加聚焦於產品本身，這是 TiDB 帶來的一個實實在在的業務價值。
3.批量系統與聯機交易系統分離。前面提到跟聯機系統是因為資源的考慮做了一個複用，現在拆分之後實際上跟聯機就已經完全剝離了，並且沒有像單機資料庫的主備複製延遲，可以最大化資源利用率來提升批量效率。
基於 TiDB 的優化
以上這些收益可以看到比較明顯的效果，那麼微眾銀行做了哪些優化或者遇到了哪些問題呢？
1.SQL 模式優化。TiDB 因為本身分散式架構其單條請求時延會相對比 MySQL 更高，所以需要去把一些跟資料庫頻繁互動的請求進行打包，儘量減少互動，比如把多個 select 改成 in 的方式，把 insert 多條改成 insert 單條多 values 的方式，把多個 update 改成 replace 多條 values 的方式。此外，因為把多個單元化的資料全部彙總到一個 TiDB 叢集，那麼它的單表資料量一定非常非常大，如果跑了一個比較低效的 SQL，很容易把這個叢集搞垮，比如存在著 OOM 的風險，所以需要特別注意 SQL 的稽核和調優。再比如早期版本會出現執行計劃不準確的問題，在 4.0 版本支援 SQL 執行計劃繫結，可以對一些高頻的 SQL 進行繫結，使其執行更加穩定。因為微眾銀行接入 TiDB 比較早期，所以主要使用的是樂觀鎖模式，應用也做了很多適配，目前適配樂觀鎖模式的程式碼已經固化為一個通用模組，新系統接入時直接拿來用就可以了。
2.熱點與應用併發優化。使用 TiDB 比較多的使用者可能會對熱點這個問題比較熟悉，前面提到彈性伸縮，而要做彈性伸縮，資料必須足夠離散，所以微眾銀行在前期接入 TiDB 的時候也發現像在 MySQL 上的 Auto Increment 特性，可能會存在熱點問題，還比如像使用者的卡號、借據號也可能是一些連續的數字，所以微眾銀行鍼對這兩塊做了一些調整或優化，比如把它改成 Auto Random，然後把一些卡號，根據它的資料分佈規律，通過演算法提前把這些資料的分佈區間算出來，再通過 Split Region 打散功能進行預打散，這樣大批量瞬時寫入時就可以充分利用每一個節點的效能；另外也對低頻修改、高頻訪問的小表進行了應用內的快取處理，緩解熱點讀問題。除了資料需要足夠離散，應用同樣也要做分散式改造優化，因為應用是分散式的，所以需要一個 App Master 節點來做資料分片的工作，然後把分片任務均勻分攤到每一個 App 上做運算，執行期間還需要監測每個分片任務的狀態和進度；最終通過資料和應用的協同優化，達到整體具備的水平擴充套件能力。
3.資料同步與資料校驗優化。這就是前面提到微眾銀行通過 DM 工具把各個業務單元的資料彙總起來，早期使用的 DM 1.0 版本不具備高可用特性，這在金融場景下是比較致命的。而在 DM 2.0 版本上包括高可用性，相容灰度 DDL，易用性等等幾個特性都已穩定上線。此外是資料校驗部分，因為是核心批量場景，資料同步必須做到資料不丟、不錯，所以應用也內嵌了資料 checksum 的邏輯，比如在 MySQL 入庫時先對資料進行分片，然後把各個分片的 checksum 值寫到表裡面，再通過 DM 同步到下游 TiDB，最後應用在跑批期間從 TiDB 把各個分片載入出來，然後再跑一遍對應分片的 checksum，再對上下游的 checksum 值進行比對，通過這樣的校驗機制以確保資料的一致性。
4.故障演練與兜底預案優化。這個系統之前是基於 MySQL 的批量系統，遷到 TiDB 後有一些故障場景表現可能會出現非預期的現象，所以微眾銀行做了大量故障演練，第一是模擬各個 TiDB 元件節點異常，確保應用可以相容，同時當出現批量中斷後，應用也支援斷點續跑；第二是整批次重跑，由於可能會遇到程式 bug 或者非預期問題導致整個批次需要重跑，為了快速恢復重跑現場，應用開發了快速備份和 rename 閃回的功能; 第三是針對極端場景的演練，比如假設 TiDB 庫出現了整體不可用，微眾銀行結合 Dumpling 和 Lightning 進行了整叢集的快速備份和恢復，難點包括 DM 同步的還原點快速確認、大表人工預打散等等，最後驗證的結果符合正確性和時效性的要求。因為這個架構涉及到較多資料流轉，所以針對故障場景做了大量的演練以及對應預案 SOP 的編寫。
未來規劃
微眾銀行從 2018 年開始調研及 POC，2019 年上線了第一個 TiDB 的應用，當前 TiDB 在微眾銀行的應用領域已覆蓋了貸款、同業、科技管理、基礎科技等等，當前還有多個核心業務場景在做 POC 測試。針對未來的規劃有五個方面：
1.TiDB 的雲原生 + 容器化。可以帶來比如自動化運維能力的提升、資源調配的能力等等。
2.基於 Redis + TiKV 的持久化方案。主要是替換 Redis + MySQL 的兜底方案，藉助 TiKV 天然的高可用特性來做持久化的方案。
3.基於 SAS 盤低成本應用。微眾銀行在行內有很多歸檔場景，資料量特別大，因為受監管要求需要保留很長時間，針對這種儲存容量要求高但低頻訪問的場景，TiDB 基於 SAS 盤低成本的方向也會做一些試點。
4.國產化 ARM 平臺的 TiDB 應用。去年微眾銀行已經有業務上了 TiDB ARM，未來隨著國產化的趨勢，這塊將會被繼續加大投入力度。
5.TiFlash 的評估與應用。TiFlash 提供的是 HTAP 的能力，尤其像實時風控以及輕量 AP 查詢的場景會帶來很大幫助，這也是微眾銀行未來的重點規劃方向。