「我們已經用起來了」，是我們最喜歡聽到的話，簡簡單單幾個字的背後代表著沉甸甸的信任和託付。從今天開始，我們將通過
「相信開放的力量」系列深度案例分享，從業務的角度，看看一個數據庫為各行業用戶帶來的業務價值。 本篇文章將介紹 TiDB 助力中國電信翼支付金融核心場景的故事。
餐飲娛樂 、投資理財、商戶服務...... 讓大家盡情享受安全、便捷的金融新生活。
中國電信翼支付（以下簡稱：翼支付）成立於 2011 年 3 月，是中國電信旗下的運營支付和互聯網金融的業務品牌，是中國人民銀行核准的第三方支付機構，是中國證監會核准的基金支付結算機構，支持各類線上線下民生支付應用，一直致力於為個人、企業提供“安全、便捷、時尚”的支付解決方案。
2019 年翼支付月活用戶 5000 萬，每月 2.3 億筆交易，年交易金額超 1.75 萬億。目前累計接入華潤、永輝、蘇寧小店、物美、中百等超 800 萬家線下商戶門店及蘇寧易購、京東、天貓、餓了麼、中糧我買網、美團等 170 餘家線上電商。
客戶收益
面對業務快速增長及激烈的市場競爭壓力，翼支付技術團隊選擇 TiDB，對業務系統尤其是支付系統數據庫進行改造升級。經過不懈努力，反洗錢系統效率提升 5 倍，對賬平臺性能提升 2 倍，而處理時間減少 ⅔ ！目前，翼支付業務層以及核心平臺層都採用 TiDB 提供服務。
我們對系統的改造升級，不僅達到了監管部門的要求，也讓財務部門運營的處理能效得到了很大的提升，還大大降低了技術團隊的工作複雜度。新系統上線以後，我們對 TiDB 的表現比較滿意。 ——翼支付基礎架構技術團隊
- 風控監管：反洗錢系統超越監管要求，實測結果顯示：整體批處理性能提高了 3 倍以上，時間也縮短至原來的 ⅓，平臺整體有效處理能力提升到 5 倍以上。
- 夥伴結算：對賬平臺處理時間減少 ⅔ ，性能提高 2 倍，就經常使用的三種形式來看：
- 銀聯支付寶，以前使用 MySQL 用時兩分鐘，現在使用 TiDB 只要 40 秒，性能提高了 300%；
- 銀聯無卡支付，使用 MySQL 用時 3-5 分鐘，TiDB 用時 1-2 分鐘，性能提升 200% - 300%；
- 微信支付，MySQL 用時 3 分鐘，TiDB 約 1 分鐘，性能提升 300%。
- 個人賬單：有效改善使用體驗，增加了用戶活躍度，解決了原有分庫分表在容量、存儲週期、查詢效率等方面問題：
- 現在使用 TiDB 單表數據量近 100 億，原來 MyCAT 只能按照月來分表，單表存儲容量上限為 1 億；
- 存儲週期可以藉助 TiDB 線性擴展能力延長至 3 - 5 年，甚至更長，原來 MySQL 只能存儲半年；
- QPS 提升 50 %，延遲降低 20-30%，成功應對 525 大促。
面臨挑戰
優異成績的得來，向來都不是一帆風順。在項目啟動之初，雙方團隊就面臨了不小的難題。
反洗錢風控 時間緊 任務重
隨著《中華人民共和國反洗錢法》修改工作正式啟動，監管部門對處理時間的要求是 T+1 （次日）的時間內必須要完成可疑的規則和風險評級的計算要求。
之前跑批單的任務時間大概都在幾百分鐘，每天整體任務處理的時間都會在 15 小時甚至更長，隨著數據量越來越大，業務系統面臨了越來越大的風險，所以反洗錢系統在性能上也提出了比較強的要求：
- 滿足 SQL 2003 的標準；
- 多表關聯，能夠查詢數據集 1 千萬以下，響應時間 5 秒以內；
- 數據文件批量加載，20G 大小，大概不能超過 30 分鐘；
- 億萬數據中要刪除 50 萬數據，響應時間要在 10 秒之內；
- 3 億數據中刪除兩千萬，也要有 10 秒之內的響應時間；
- 3 億數據量更新 100 萬，響應時間 5 分鐘左右。
交易激增 要擴展 提性能
與此同時，翼支付團隊還需要解決兩個問題：第一，現有數據庫架構是否支撐未來業務的成長，包括功能、可擴展性、穩定性、服務支持能力等方面的需求；第二，性能始終是難題，在現有架構上提升一點都非常困難，何況數倍提升的要求。
解決方法
經過雙方團隊對業務系統的深入分析和研判，做出了三步走的策略，首先評估現狀考慮數據庫架構的調整方法，接下來在營銷業務進行試點，然後聚焦解決核心支付業務的問題。
基於業務場景 建立數據庫評估模型
在進行了大量的測試之後，最終確定了翼支付基於業務場景構建數據庫選型評估模型，雙方經過仔細研判後決定：對於新採用的項目，在關係型數據庫的選型上，不再考慮使用 Oracle，按照容量閥、性能閥、大表的數量、分區規則、 HTAP 能力，以及拓撲結構這幾個緯度進行容量篩選。得出結論在翼支付的業務場景中對於容量大於 3T，QPS 大於 20000，大表數量比較多，而且分片規則很難定義，以及一些實時分析場景，優先選擇使用 TiDB 。
場景試點 提升用戶體驗
個人賬單系統在翼支付 APP 客戶端內，是為個人用戶提供所有交易的賬單數據的管理、查詢功能，以及數據的分類和統計功能，以便用戶能更好的掌握自己通過翼支付所做的所有交易。根據評估模型，也是屬於典型的 TiDB 適用場景，團隊按照應用切換原則，選用了 TiDB 的數據同步工具在短時間內進行了應用切換和遷移工作。
切入業務 提升 TB 級支付效能
同樣基於評估模型，團隊選擇了對賬平臺系統及反洗錢系統進行核心攻關。
對賬平臺系統涉及到多張表，單表的規模超 10 億，整體數據規模超過 8T+，業務應用的邏輯相對複雜，數據併發量中等。改造後，核心支付系統產生交易流水，通過文件形式傳輸到文件解析服務，文件解析服務將數據的解析結果保存到分佈式數據庫，對賬系統基於分佈式數據庫完成對賬的流程，同時向 WEB 端提供查詢頁面和查詢服務。
在反洗錢系統方面，隨著監控數據的數量和類型發生許多變化，反洗錢業務需求數據日益增大，監控的範圍不斷的擴大。團隊按照 TiDB 的形式進行架構升級，一方面通過（OGG for MySQL client )，將數據從原來的 Oracle 同步到 TiDB；另一方面使用大數據的發佈功能，從 Hive 直接去同步到 TiDB。
挺進核心 佈局未來
下一階段翼支付將會擴大 TiDB 的應用範圍，將業務發展快、規模大的核心鏈路的系統，逐步往 TiDB 遷移 ，而這需要做幾方面工作，一方面是外部環境變化，未來可能在數據庫上也會做很多的限制，必須提前做一些準備；另一方面是考慮性能規劃可以滿足未來業務不斷增長的需求。
目前的核心庫都會有上億數據量的規模，單庫總數據量 10T 以上，核心業務要求停機時間非常短或不能停，這就對數據庫提出了較高的要求，同時需要在開發模式上進行更新，包括：採用 Oracle 和 TiDB 共存的雙模式開發，支持灰度或者雙寫的切換過程，提升業務校驗能力，進行模塊和批次進度的設計。另外，在運維管理上也有更高的要求，包括窗口的切換操作的過程、回退的預案等。
為何選擇 TiDB
從中國電信翼支付的項目不難看出，我們就是看重了 PingCAP 團隊對於核心業務的理解，以及對分佈式數據庫架構的設計及改善能力。 ——翼支付基礎架構技術團隊
降風險 促業務
對於運營商尤其是支付業務來說，風控是第一位的，只有規避的風險，才能保障業務運行；而在此之上，要適應於業務發展及場景要求，更要為業務發展做好規劃，預設技術路線及預留髮展空間，這對技術團隊的數據庫建構設計能力及數據處理效能的改善能力提出了較高要求，毫無疑問，TiDB 及其團隊值得客戶信賴！
與客戶同行，相信開放的力量
每次數據庫架構改善與落地，無論是 TB 級還是 PB 級，都需要付出努力，但這也值得每一個企業去實踐。在當下這個時代，不管企業的規模如何，都要學會藉助開源的力量，避免去重複的造輪子。
每一個看似輕鬆的背後都有不為人知的努力，每一個看似光鮮亮麗的背後，都有不為人知的付出。分佈式數據庫建設之路道阻且長，TiDB 願與翼支付及每個客戶一起，攜手並肩把事情做好。
