Categories
程式開發

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


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

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

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

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

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

在這兩年的建設過程中,北京銀行與PingCAP 進行專項的深度合作,這裡簡單介紹三個方面:

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

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

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

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

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

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

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

網貸業務平台

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

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

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

在這個過程中,有幾點經驗分享給大家:

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

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

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

然後跟大家分享一下TiDB 的批處理效率,剛才提到的3000 萬跑批是在一個小時左右完成的,後期隨著版本的升級和系統優化,還有很大的提升空間。

應用推廣

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

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

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

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

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

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

接下來談談我們對未來的展望,有點像昨天、今天和明天。

總體目標

在未來,北京銀行的分佈式數據庫團隊,主要是著手兩方面的工作:

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

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

分佈式金融業務平台規劃

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

最後,跟大家分享北京銀行分佈式金融業務平台的規劃。

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

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