TiDB 在北京銀行交易場景中的應用實踐

做者介紹：陳振東，北京銀行軟件開發部

北京銀行是一家城市商業銀行，公司價值位列中國區域性發展銀行的首位，依託於中國經濟的大環境，北京銀行的資產總量在全球千家大銀行中名列第 61 位，連續六年躋身全球銀行業百強。北京銀行積極開闢多元化的業務經營，例如北京地區的社保繳納和醫保代發，都是由北京銀行在提供服務，在你入職一家公司的時候，收到的醫保摺子就是來自北京銀行。

業務轉型驅動分佈式架構建設

因爲快速的業務發展需求，北京銀行在業務轉型中對系統架構進行了升級，逐漸向分佈式架構進行轉移。早在 2016 年，北京銀行就開始了對分佈式數據庫的探索，並於 2018 年正式投產上線了 TiDB 分佈式數據庫，當時在業內尚未一個比較完善與成熟的體系，咱們也是根據銀行的安全合規需求建設了兩地三中心的部署方案。

如上圖所示，在兩地三中心部署了 TiDB 分佈式數據庫集羣，採用主從的多活架構，主集羣做爲生產集羣承擔平常的生產服務，從集羣是建設在西安的異地災備中心，主從之間是用 Kafka 同步 Binlog 形式進行數據的同步。

在這兩年的建設過程當中，北京銀行與 PingCAP 進行專項的深度合做，這裏簡單介紹三個方面：

• 兩地三中心：在兩地三中心的部署方案中，異地中心的網絡延時會對整個集羣的性能產生較大影響，咱們在這層面上對 gRPC 的消息格式進行了壓縮，同時利用 Multi-Raft 特性將主節點都固定到北京 IDC 的節點。
• 增量備份：有一些系統對增量備份有需求，特別是審計、監管這類數據的導入和導出，北京銀行和 PingCAP 共同展開增量備份和指定時間數據恢復的方案研究，將 Binlog 保存到本地，以 ProtoBuf 的形式存下來，再利用 Reparo 相關工具可以恢復到指定的時間節點。
• 事務：金融行業你們都比較關心數據庫事務，例如大事務處理、RC 級別、悲觀鎖的應用等，北京銀行在這些需求層面也與 PingCAP 進行了專項的合做，固然在 TiDB 4.0 版本里面已經包括了這些功能特性。

TiDB 在金融交易場景中的應用實踐

網聯支付清算平臺 & 銀聯無卡快捷支付系統

在構建數據庫以後，咱們來看看 TiDB 在北京銀行交易場景中的應用時間。首先給你們介紹的是網聯支付清算平臺和銀聯無卡快捷支付的場景，這兩個是最先使用 TiDB 數據庫的業務系統。

根據當時中國人民銀行「斷直連」的要求，全部銀行的三方支付交易都要進行集中的彙總。在此以前，銀行對這種三方支付的建設方案會採用一些通用平臺去承載這些專用業務，好比支付寶有專業的支付寶系統、微信支付、京東支付等等都有各自專用的支付系統。在有了「斷直連」匯聚三方支付的要求以後，北京銀行對業務和系統進行了整合，以便更好地迎接互聯網金融帶來的大數據量和高併發的挑戰。

在這兩個系統投產以後，已經成功應對了兩次雙十一挑戰，上圖列出了 2019 年雙十一巔峯的 QPS 達到了 7500，是平時 QPS 的十倍以上。IT 團隊進行屢次線上的運維操做，包括版本升級、打補丁等，很好地利用了 TiDB 分佈式數據庫的多副本特性實現「運維零中斷」的操做。隨着北京銀行系統的升級，在網聯這條業務鏈上，包括上游的手機銀行到網聯、銀聯無卡快捷支付這樣的業務中臺，再到後臺的金融日曆、查詢服務都已經進行了分佈式架構的升級，完成了與 TiDB 的對接。 在這裏，手機銀行指的是手機銀行 App 的後臺管理端，並非說您下載一個北京銀行手機 App 就能得到一個 TiDB。

網貸業務平臺

第二個比較典型的應用場景就是網貸業務平臺，網貸平臺不一樣於網聯平臺的聯機實時高併發的交易，主要進行的是一些批處理的業務，好比像借唄、花唄、度小滿這類比較熱門的互聯網金融明星產品，其實在銀行側就是一筆筆貸款與一筆筆借據，咱們須要對它們進行無差異的處理。

網貸平臺跟上面提到的網聯平臺仍是很是有淵源的，整個網貸平臺採用敏捷化的建設方式，包括敏捷的項目管理、敏捷開發與敏捷測試。最開始的時候，項目組是計劃經過採購實體服務器專門搭建一套數據庫集羣給網貸平臺使用，可是因爲整個採購物流的週期太長，咱們最終決定對網聯、銀聯無卡這套比較完備的系統進行一個 Scale-in 縮容，將縮容出來的五臺 TiKV、兩臺 TiDB 給到網貸平臺使用，PD 由網貸和網聯兩套系統共同使用，咱們採用這種方式快速完成了系統的構建。

在這個過程當中，有幾點經驗分享給你們：

首先是對批處理結構的優化，起初網貸平臺專門處理網貸借據、貸款覈算等批處理業務，隨着後期的一些消費貸、貸款查詢、用戶查詢這類聯機交易上來之後，對 TiDB server 層的批處理性能會產生較大的影響。因而，咱們將剛纔提到的兩臺 TiDB 其中的一臺專門用於處理這些實時聯機交易，另外一臺 TiDB 專門進行批處理。

另一點，網貸平臺在處理完本身的會計分錄以後，由傳統的核心總帳系統進行覈算與帳務處理。外系統也是在這種交互過程當中，因爲 TiDB 的 SI 隔離級別，MVCC 多版本 有它的回收機制，以前開發測試中沒有考慮到這一點，後期在性能測試中發現了有 GC 超時的現象，咱們經過對事務的合理編排解決了這個問題。

在業務評估層面，當銀行的業務人員說有一個 300 萬的貸款合同、貸款借據，其實到網貸平臺通過流水錶、當日表與歷史表這樣一系列處理以後，就成了一個 3000 萬行須要處理的數據，網貸平臺須要去跑批處理的數據也就是這 3000 萬，再也不是業務人員的 300 萬。再從 TiDB 數據庫層面去看，加上了副本、索引等等以後，這樣的數據量其實已經遠遠大於最開始業務預期的評估，這就是一個金融場景大數據產生的過程。

而後跟你們分享一下 TiDB 的批處理效率，剛纔提到的 3000 萬跑批是在一個小時左右完成的，後期隨着版本的升級和系統優化，還有很大的提高空間。

應用推廣

除了上面兩個比較典型的交易系統以外，北京銀行也在減值計提準備系統、金融服務互聯平臺、金融渠道開放平臺、城商行系統等場景都用到了 TiDB，涵蓋了包括支付、帳務覈算、金融渠道等方面全部的金融場景。

分佈式數據庫建設過程感覺總結

簡單總結一下分佈式數據庫建設過程當中的一些感覺。

• 業務轉型：你們都提到在金融互聯網的上半場，銀行是一個完敗的結局，其實互聯網金融這個場景給了你們一個公平的競技場，只有以客戶爲中心，才能生存下來。剛纔提到的網聯場景，用戶就是喜歡零點搶購，咱們就要有應對策略，咱們須要搭建更靈活、更大容量的系統去承載這些流量。
• 動態維護：隨着架構的轉型，分佈式架構在靈活部署等方面逐漸體現出優點。咱們須要更智慧、更優雅地去解決可能帶來的服務中斷的狀況。銀行對業務連續性保障要求很是高，咱們如今能夠充分利用分佈式數據庫的架構優點，真正實現零停機的集羣動態節點調整。
• 行內生態：隨着 TiDB 分佈式微服務架構的全面推廣，北京銀行內部也是以點帶面，有愈來愈多的項目組參與進來，學會從分佈式的架構出發，思考在這種架構和技術棧下，應該如何去進行業務層的規劃和設計。

金融場景業務與分佈式數據庫的明天

接下來談談咱們對將來的展望，有點像昨天、今天和明天。

整體目標

在將來，北京銀行的分佈式數據庫團隊，主要是着手兩方面的工做：

一方面是拓寬領域。首先從剛纔提到的這些專業系統的範疇出發，繼續下沉去探索分佈式數據庫在銀行的帳務類、客戶信息類的核心業務場景中的應用。並從數據庫技術角度出發，將分區表、悲觀鎖，甚至 HTAP 這種特性與銀行系統進行結合，不斷推動分佈式數據庫在金融領域的落地。而且隨着今年北京銀行順義研發中心的投產使用，咱們也面臨同城雙中心方案制定的挑戰。

另外一個大方面就是合力共進。這裏的力，包括協內力和協外力兩個方面。協內力方面剛纔我已經提到，隨着行內愈來愈多的項目組開始使用 TiDB，去進行微服務的轉移，咱們的系統開發人員須要拓寬思路，在分佈式的架構下，應該怎樣去設計和開發代碼。隨着 TiDB 分佈式數據庫的引入，對咱們的架構管理與運維管理都帶來一些挑戰，須要總結前期的經驗，把曾經掉過的坑進行概括，化繁爲簡，造成一套比較成熟的銀行業的建設方法論。協外力方面，北京銀行在分佈式數據庫建設的過程當中，參與了金融業內的標準制定與交流，在將來咱們會繼續保持這樣的姿態，爲行業建設貢獻一份力量。

分佈式金融業務平臺規劃

最後，跟你們分享北京銀行分佈式金融業務平臺的規劃。

首先是分佈式核心的下移的工做，包括上面提到的賬務覈算、客戶管理等一系列業務應用的遷移工做。

另外一個層面，研究 HTAP 混合業務場景的試點應用，這也是 TiDB 4.0 裏面比較有亮點的功能。TiDB 4.0 發佈以後，咱們在行內已經開始對 TiFlash 進行初步的評測，咱們相信 HTAP 混合型的數據庫是將來的技術發展方向，咱們將繼續去探索，找到 HTAP 真正的歸屬之處。

本文整理自陳振東在 TiDB DevCon 2020 上的演講。