TiDB x 微衆銀行 | 耗時降低 58%,分佈式架構助力實現普惠金融

「我們已經用起來了」,是我們最喜歡聽到的話,簡簡單單幾個字的背後代表着沉甸甸的信任和託付。從今天開始,我們將通過**「相信開放的力量」**系列深度案例分享,從業務的角度,看看一個數據庫爲各行業用戶帶來的業務價值。 本篇文章將介紹 TiDB 助力微衆銀行金融核心場景的故事。

科技普惠大衆,數據連接智能

從一次驚喜,到每次陪伴

我們讓美好發生

微衆銀行是國內首家開業的民營銀行,由騰訊、百業源和立業等多家知名企業發起設立,於 2014 年 12 月獲得由深圳銀監局頒發的金融許可證,總部位於深圳。開業 5 年多來,微衆銀行始終堅持普惠金融的定位不變,積極運用金融科技構建普惠金融新業態、新模式,初步走出了一條商業可持續的普惠金融發展模式。

截至目前,微衆銀行服務個人客戶已突破 2.5 億人;個人經營戶超過 2000 萬,企業法人客戶超過 150 萬家,累計發放了超過 3200 億元的貸款,支持就業人口超過 400 萬。這些客戶全部爲民營企業,分佈在 27 個省的 200 餘座城市,其中,約三分之二的企業客戶和 37% 的個人經營貸款客戶屬首次獲得銀行貸款,充分體現了微衆銀行普惠金融的定位和特色。

客戶收益

微衆銀行成立以來始終以科技作爲驅動業務發展的核心引擎,已經具備完全自主可控、支持億級海量用戶和高併發交易的核心繫統,已實現年均日交易超過 3 億筆、單日交易峯值超過 6 億筆;每賬戶運維成本不到行業平均的十分之一。

從 2018 年開始調研並上線 TiDB 至今,微衆銀行已經有數十個業務系統在 TiDB 上投產,數據量從百 G 到幾十 T 不等,目前也有多個重要的系統正在 POC 或準備投產階段。今天這篇文章介紹兩個 TiDB 支撐的比較重要的場景:

  • 資產證券化系統批量場景下的 TiDB 實踐。
  • 交易數據存證 TiDB 實踐。

面臨挑戰

自成立之初,微衆銀行就非常有前瞻性的意識到底層基礎設施建設對銀行發展的重要性,選擇了建設分佈式架構 IT 基礎設施的道路。基於廉價通用的硬件設備和各類開源的軟件產品,微衆建立了基於單元化的鬆耦合、可擴展的分佈式架構。

爲了實現業務規模的水平擴展,微衆銀行設計了基於 DCN 的分佈式可擴展核心架構,從而即實現了整體擴展性,也保證了單 DCN 數據庫層面架構的簡潔性。DCN,即 Data Center Node(數據中心節點),是一個「自包含單位」,包括了完整的應用層,接入層和數據庫,每個 DCN 承載規定數據量的用戶。可以通俗的理解爲,一個DCN,即爲一個微衆銀行的線上的虛擬分行,這個虛擬分行只承載微衆銀行某個業務的一部分客戶。

基於 DCN 可以實現集羣規模的水平擴展,這種架構對於數據庫來說,是比較友好的,每個 DCN 的用戶規模是確定的,因此對數據庫的容量和性能要求也是可確定的。不必再採用複雜的中間件分庫分表的方式構建數據庫,而只用單實例模式承載,極大簡化了數據庫架構,也降低了業務開發成本。

但同時也遇到一些瓶頸。因爲一個 DCN 內部採用的是單實例的部署模式,對於有些無法通過 DCN 拆分進行擴展的業務場景,或者需要進行數據彙總類的業務場景,單實例的性能和容量就很容易到達瓶頸。

爲何選擇 TiDB

爲了解決上面提到的瓶頸,經過詳細的調研和評測,比對了國內外多款 NewSQL 數據庫產品,最終確定以國產開源 NewSQL 數據庫產品 TiDB 作爲切入點。2018 年,TiDB 作爲一款新興的開源 NewSQL 數據庫產品,吸引了微衆銀行,並最終選擇:

架構理念先進

TiDB 的架構理念較爲先進,原生分佈式的架構能夠很好解決水平擴展同時保持數據強一致的問題,同時兼容 MySQL 協議並能無縫的作爲從庫對上游 MySQL 進行實時同步,也讓業務的遷移成本降到最低;

開源的運營方式

TiDB 以開源方式運營,並且建立了非常活躍的開源社區以及衆多的用戶。開源的運營模式,版本迭代快速有效,與微衆擁抱開源的理念相契合。此後,在開源社區運營領域也和微衆有着較好的合作,爲微衆提供了不少開源社區的運營經驗。

專業的售後服務

TiDB的專業售後支持團隊 PTC(PingCAP Tech Center)的優質服務 ,在數據庫領域和開源社區領域都有着深厚的技術基礎和經驗積累。針對客戶的技術支持也非常快速到位。對於任何一個重要業務的接入,從評估、測試到灰度上線,都會積極參與,並給出建設的方案和意見。

微衆銀行 TiDB 業務實踐

資產證券化系統批量場景下的 TiDB 實踐

資產證券化系統,目前每天要從上游系統同步數千萬級別的基礎數據來支持業務展開,並且預計後續將接入更多的產品數據,這樣不僅面臨時效性要求的壓力,DB 容量也將會成爲瓶頸;此外由於系統依賴上游系統的表結構,經常需要跟隨上游系統做 DDL 變更,PT-OSC 方案限制較多。

存在的問題:

  • 單機 MySQL 數據庫不支持容量水平擴展,隨着業務的規模增大,DB 容量瓶頸問題將會日益凸顯;
  • 單機 MySQL 數據庫不支持性能水平擴展,無法通過擴容資源來線性提升批量效率;
  • 單機 MySQL 數據庫對基礎數據全表清庫、數據高併發插入等場景,由於併發線程過高易引起主備延遲等問題做了限流,這將會降低批量的整體時效;
  • 單機 MySQL 數據庫的在線 DDL 特性存在鎖表,易引起主備延遲、IO 突增等問題而PT-OSC 方案同樣限制較多;

無疑 TiDB 是可以比較方便地處理這些問題,並且未來隨着 TiFlash 上線後,還可進一步的運用在離線報表統計邏輯上,縮減處理時長。

**「藉助 TiDB 的水平擴展性,整個批量耗時降低了 58% 左右。」**微衆銀行數據平臺室經理胡盼盼表示,未來微衆銀行將會結合自身的業務需求,以及 TiDB 的新特性,探索更多的業務場景。

數據存證系統 TiDB 遷移實踐

數據存證系統是微衆銀行非常重要的系統,存儲了具有法律效力的證據類數據,這些數據對客戶來說是非常重要的。

隨着越來越多的業務系統的接入,該場景的數據增長速度非常快,比如每一次轉賬都需要生成一個證據,並且不是簡單的一條記錄,而是發生糾紛時法院認可的證據,所以也決定了這些數據不能刪除,這意味着這些海量的數據一定需要一個分佈式數據庫方案承載。另外由於這些業務數據屬於無法按照 DCN 拆分的全局數據,沒辦法很好的橫向擴展,於是在數據庫層面遇到了很大的瓶頸。

微衆 TiDB 部署架構圖

如上圖所示,基於這些場景特點,微衆同樣選擇了 TiDB 的解決方案。有幾個基本的遷移原則:

  • 數據不能錯、不能丟;
  • 服務敏感度非常高,需要儘量無縫切換到 TiDB 架構上;
  • 因爲是比較嚴肅的金融場景,如果在遷移過程中有任何困難,期望能夠隨時回切到 MySQL。

遷移整體方案步驟流程比較長,但會更加安全。經過一系列遷移操作與觀察後,各方面的性能指標都非常穩定,因此微衆銀行決定將反向同步 MySQL 斷掉,也就意味着數據存證系統這樣一個非常重要的系統,完全跑在了 TiDB 上。

「回顧整個遷移過程,也是比較流暢且順利的。」微衆銀行數據平臺室經理胡盼盼表示。

與客戶同行,相信開放的力量

每次數據庫架構改善與落地,無論是 TB 級還是 PB 級,都需要付出努力,但這也值得每一個企業去做。在當下這個時代,不管企業的規模如何,都要學會藉助開源的力量,避免去重複的造輪子。

每一個看似輕鬆的背後都有不爲人知的努力,每一個看似光鮮亮麗的背後,都有不爲人知的付出。分佈式數據庫建設之路道阻且長,TiDB 願與微衆銀行及每個客戶一起,攜手並肩把事情做好。

相關文章
相關標籤/搜索