TiDB 在銀行核心金融領域的研究與兩地三中心實踐

時間 2020-02-01

標籤 tidb 核心金融領域研究兩地中心實踐简体版

原文原文鏈接

做者介紹：
于振華，北京銀行軟件開發部資深架構師，長期從事銀行核心系統研發、規劃，參與過多個核心信息系統建設工做，包括1、二代支付系統、第四代銀行核心系統建設、分佈式核心系統建設等企業級項目工做。當前主要研發方向集中在構建先進、高效、面向 OLTP 的銀行交易系統，提高銀行信息系統服務能力。

本文整理自於振華老師在 TiDB DevCon 2019 上的演講實錄，演講主題爲《TiDB 在銀行核心金融領域的研究與實踐》。前端

今天參加 TiDB DevCon 2019 可以和這麼多各行各業的朋友一塊兒來交流 TiDB 的實踐狀況，這個機會很是可貴，由於平時都是咱們技術團隊和 TiDB 團隊單向的交流，橫向的這種客戶之間交流的機會不多，像剛纔幾位老師講的，我以爲都頗有意思，也但願經過我們此次大會，你們能擦出不同的火花。數據庫

北京銀行和 PingCAP 團隊進行了深度的合做，目前有幾套重要的實時交易類系統已經對接，包括比較重要網聯繫統、銀聯無卡支付、金融互聯服務平臺等。如今怎麼來評價一款產品到底穩不穩，很大程度上要看這款產品在金融，尤爲是核心金融的場景有沒有應用，能不能支持金融場景的要求。咱們是在 2018 年 3 月份、5 月份、6 月份進行了投產。通過半年多的時間，咱們看到 TiDB 也可以支持金融場景了。從側面來說，分佈式數據庫技術，確實已經到達了必定的成熟度。設計模式

1、背景介紹

我相信這幾年，尤爲是這三四年，你們應該都有感觸。不管是工做方式，仍是生活方式，都發生了很大的變化，各類信息、科技產品鋪面而來，有人說是這種變化叫工業科技革命 4.0。不知道這種提法準確不許確，但這種變化確實對咱們銀行的系統產生了比較大的挑戰。緩存

<center>圖 1</center>服務器

在圖 1 中，我列出了幾項，好比高併發的要求，要求你具有很快的擴展能力。再好比產品發佈，要求你具有快速的發佈能力，在座的應該有不少作產品、作實施的團隊，你們應該頗有感觸，好比可能前一天還無人問津的產品，次日可能就會賣的很火爆，來的每一個項目都是緊急項目，都要求你在最快的時間發佈出去。固然還包括一些老生常談的問題，像傳統架構成本難以控制，還有自主可控亟待攻關，其實在傳統閉源的生態裏面，咱們很難達到自主可控的要求。網絡

2、系統分析

<center>圖 2</center>架構

在這種背景下，咱們從全局的角度出發，對銀行以往的技術形態作了系統性的分析，圖 2 中列舉了一些典型的架構形態，有一些在如今的銀行架構裏邊仍是存在的，好比單體的應用，再好比傳統的數據庫，如今用的最多的 DB2 和 Oracle，還有傳統的單機或者集羣部署模式，以及瀑布開發模型，固然還有面向傳統架構的運維模式。併發

今天咱們來談分佈式數據庫，它是一個新技術，但不能說把以往技術架構就否認掉。以往的技術形態好很差？坦白講，我認爲很好，很差的話不可能支撐了這麼多年的金融業務發展，但站在今天這樣的時間點來講問題也是存在的。像剛纔講到的，高併發的要求、擴展能力、成本、以及產品交付能力都存在一些不盡如人意的地方。運維

在這種狀況下，咱們啓動了北京銀行新一輪的架構轉型的工做，分佈式數據庫也歸入到咱們的工做範圍裏。咱們和 PingCAP 很早就接觸了，在一年多的工做過程當中，要談的技術細節、技術方案、工做流程等等這些內容會不少，若是真的來總結一下這項工做是怎麼作的話，我總結出如下三條。你們一看可能會以爲很虛，可是你若是真的來實踐這件事，也許會有一樣的感觸。分佈式

第一個就是「務實」。架構轉型不是一個爲了技術而技術，爲了新產品而新產品的工做，而是確實要對你的業務發展、開發、運維的效率有所提高。

第二個，我以爲多是最重要的，就是要作到「速贏」。不管是你在什麼樣的企業來作技術升級，技術轉型，或多或少的都會遇到一些阻力，尤爲是在傳統企業。那作到速贏，迅速的釋放價值，讓你周圍的人、讓你的團隊、讓你的組織，迅速看到它的價值，會讓你將來的工做開展更加平滑。

第三個是「全棧」。由於是總體的架構轉型工做，咱們但願建設一套平臺，它可以釋放總體的價值，而不是在意一城一池的得失。今天原本我想介紹北京銀行的應用架構和分佈式數據庫架構，由於時間關係今天只說一下分佈式數據庫建設的狀況。

3、進展狀況

在介紹具體內容以前，先跟你們同步一下，咱們如今的工做進展。2018 年 3 月，咱們投產了行業內首個面向核心金融業務的分佈式數據庫，採用的是兩地三中心五副本的架構模式。以分佈式數據庫爲基礎，5 月份咱們投產了網聯支付清算平臺，這也是很重要的一個帶資金業務的實時交易系統，6 月份投產了銀聯無卡支付平臺。這張圖（圖 3）可能稍微有點老，如今咱們投產的還包括金融互聯服務平臺，IFRS9 減值系統。咱們將來要作的事其實和剛纔劉奇講的比較一致，包括 HTAP，包括容器雲的這些方案等等，這也是咱們目前最迫切的需求。

3.1 專項評測

如今回想起來，北京銀行開展分佈式數據庫建設的工做，實際上是在行業裏面算很早的，也是由於咱們開展這件工做的時間比較早，因此在整個過程當中遇到了不少的困難困惑。行裏的技術力量集中在 DB二、Oracle 上可能比較多，對於分佈式數據庫的掌握來說，須要有一個週期。咱們作的第一步，爲了保證產品可用，建設了面向金融業務的評測體系。

圖 4 左上角是面向這個功能的測試，好比數據庫有沒有高可用性，能不能作線性擴展，有沒有在線升級能力，這些都是咱們的測試點。圖 4 左下角這塊，是面向性能的測試，咱們並無採用市面上已經有的工具，好比 TPCC、Sysbench 等等。由於咱們實際分析下來以爲市面已經有的這些工具和咱們的金融場景有一些距離，用它們來測試可能不會有很好的參考意義，因此咱們自研了這套面向分佈式數據庫的金融性能評測體系，可以讓咱們明確出分佈式數據庫能夠應用在金融場景，而且對於功能和性能，讓你們能有一個可度量的工具。

在這個過程當中，要感謝支付清算協會、信通院等上級單位和組織給予咱們的幫助，另外，咱們也和硬件廠商英特爾進行了比較深的合做，好比今年（2018 年）新的硬件平臺，咱們也作了專項的分佈式數據庫測試，爲將來咱們硬件的架構選型提供了有效的參考。

3.2 部署模式

對於分佈式數據庫的技術層面來說，剛纔幾位講師介紹的比較多了，我就來說一些北京銀行比較不同的、走在前面的一些地方。你們看到圖 5 這套架構是北京銀行的數據存儲層的架構。北京銀行的架構採用兩地三中心五副本的模式部署。

跨城長距離的分佈式數據庫建設具備很大的挑戰。好比北京和西安大概一千多千米，兩地距離比較遠，延時比較高，咱們實測的延時大概是十七毫秒左右。這十七毫秒，若是放在一條 SQL 來說，一來一回三十幾毫秒，這樣的延時咱們確定是接受不了。因此在這種狀況下，咱們用了一個五副本的模式：北京兩個 IDC，各放置兩副本，西安一個 IDC 放置一個副本，採用 2:2:1 的模式。這樣作的好處就是當前端應用請求過來以後，不須要用到北京到西安的這個網絡，北京的四個副本中成功三個，就能夠給前端實時返回，並且北京的部分實例容許失效。這樣作 SQL 平均延時，大概在 1.2 毫秒左右，.95 延時大概 5 毫秒左右，這是比較不錯的一個成績（網聯、銀聯的業務其實要比互聯網業務複雜不少）。

這裏給你們分享一個咱們實際在生產過程當中遇到的一個小故事。在某個週六的中午我接到咱們運維值班人員的電話，他說 TiKV 存儲服務器壞了一臺，當日我第一時間問的是：壞了一臺有沒有影響服務。他說沒有影響服務，服務仍是正常的。我說那就趕忙找硬件廠商給修一下機器。當時還以爲挺高興的，不經意間在生產系統驗證了一把。到了次日週日的中午，他又給我打了一個電話，說又壞了一臺服務器。當時有一些擔憂，是否是咱們這批採購的硬件服務器有什麼問題，想到這點就立馬作排查，固然第一時間問的仍是有沒有影響服務，他說沒有影響服務。這樣連着兩天壞了兩臺存儲服務器都沒有影響服務，也證實了多副本方案的有效性。

3.3 兩地三中心

圖 6 展現的是整個包括應用、F5 到 TiDB、PD、TiKV 等整個部署的模式。目前咱們接着有網聯、銀聯這兩個比較大的系統，這兩個系統業務量相對來說比較大，天天有一兩百萬筆的業務。在西安，咱們還部署了一個從集羣，那這個從集羣是作什麼呢？這個從集羣就是爲了對接一些 OLAP 或者說比較大的報表的狀況，從而避免它對主集羣的負載產生過大的影響。

4、應用實踐

4.1 出現過的問題

有人說「當你有了錘子，好像什麼問題都看上去像釘子」。咱們期待從傳統數據庫過渡到分佈式數據庫，什麼問題均可以解決。但事實上，確定是沒有一個萬能的技術方案。圖 7 右下角，我列了一些從咱們項目開展之初到如今，產生一些問題或者說一些小插曲。

好比咱們剛纔介紹了行裏的 DB二、Oracle 應用的比較多。DB二、Oracle 之前用的是 READ COMMITTED 的隔離級別，那如今到了 TiDB 的 Repeatable Read 的這種形式可能還須要適應。咱們建設初期也出現過這種問題：這邊 Insert 的數據，那邊卻查不到，就由於 TiDB 是這種快照的隔離級別。

還有執行計劃的索引沒有選中的問題，這個在咱們實際的生產過程當中也遇到過，明明有索引，卻沒有精確選中那一個索引。形成 SQL 運行的特別慢，內存吃的也比較多。這個問題，我以爲是能夠解決好的，臨時解決方案就是手動強制加 Hint，將來我相信 TiDB 在版本升級上也會考慮這一點，讓執行計劃更加準確。

還有熱點數據的問題，熱點數據期望數據庫來解決，現階段來看是不可能了。不管是傳統數據庫，仍是分佈式數據庫，要引入另外的應用緩存的組件才能夠解決，在傳統方案裏邊，咱們作的技術方案也有不少，像比較傳統的散列方式，把熱點數據散列出去來解決，如今有了緩存，能夠引入緩存解決這件事。

咱們應用架構採用微服務的形態，對比單體應用形態，微服務對於數據庫的要求會更高。由於傳統的單體應用，事務的 SQL 數量比較多，劃分紅微服務的話，不管是應用邏輯，仍是數據庫的處理邏輯，都會比較細粒度，事務提交次數成倍增加，對於 MVCC 的樂觀提交模型有必定的壓力，在咱們實測的過程當中，越細粒度的可能表現的性能越很差。

以上就是咱們實踐過程當中出現的一些小插曲。

4.2 與互聯網行業在應用實踐上的區別

今天不少來自互聯網企業的朋友也分享了本身的經驗，那在金融行業作分佈式數據庫落地和互聯網行業有什麼不一樣呢？

首先來說，銀行的發展時期和不少互聯網新興科技公司是不一樣的，銀行有很成熟的硬件體系、部署模式、軟件的設計模式、開發模式、運維模式，站在這種平臺上來作新型技術落地會更加的困難。爲何會獲得這個結論？由於如今也有不少的軟件廠商，不少作產品的人，你們都但願作新建系統的事情。但對於龐大的歷史系統作遷移的話，確定不會是一刀切的方案，由於代價太大了。因此須要並行運行，對於這種新舊架構並行，不少時候就沒有了方案，作不了。其實如今咱們也在作這項工做，作一個新舊系統優雅的並行方案，包括業務邏輯的並行，還有業務數據的並行，若是你們有興趣的話，也能夠和咱們私下交流這部份內容，我以爲這是很重要的一個事情。

第二點就是組織架構不一樣。就拿微服務來講，單體的應用發展這麼多年，每個應用它的技術負責人是誰，對應的業務負責人是誰，是哪一個部門，都很明確。若是作微服務化，進行拆分，不少狀況下很難肯定權責，若是要企業組織架構來適應系統架構也不太現實。固然歷史資產、業務場景和互聯網企業也是不同的，銀行信息化歷史資產更多、業務比互聯網更加複雜。