銀行需要分布式數據庫嗎?


技術優秀的你,未來一兩年很可能會被老板問到這個問題“我們要不要上分布式數據庫”,你有答案了嗎?Ivan試着來幫你分析一下,你看看能不能找到自己的答案。

我們都知道數據庫是IT系統的基石,提供高性能高可靠的服務是默認的前提。銀行系統目前的數據庫方案被多年實踐過的方案,理論上當然是沒問題的,但是未來會怎樣呢?

高性能

業務場景的變化帶來業務量的激增導致高性能的需求。
一個場景是小額支付的流行。以前,你去超市買個十幾塊錢的東西要刷卡,收銀員十有八九再贈送個白眼給你,所以Ivan一般就用現金了。現在,大街小巷的商戶攤販都支持掃碼支付了,幾塊錢買包瓜子刷微信也是很爽的,沒人跟你嘰歪。這樣,小額支付場景由原來的現金變成了掃碼支付,最終體現在銀行的交易量增長。大家對比刷卡的頻率和刷微信的頻率,大致也能明白交易量的增長情況吧。其次是理財業務,按照目前的監管政策銀行理財是5萬元起購,余額寶是1元起購。近年來一直有降低起購門檻的呼聲,未來銀行理財門檻的下降已經是大概率事件,銀行天然有維持理財產品業績的意願,這就肯定會推高交易量。
這兩類場景本質上都是銀行業務互聯網化帶來的沖擊,無論是推出互聯網同質化業務還是與互聯網企業合作,都導致銀行的交易模式與頻率會更加接近微信、支付寶。
當然你可能說我們是小銀行,交易量小,或者我們主要做對公業務搞定幾個大客戶就行,那確實這個問題就那么突出。但是,性能壓力對於股份制以上的銀行還是會存在的,分布式數據庫是可選的方案。

高可靠

銀行的高可靠方案很多都是采用SRDF,它的主要問題是成本。

SRDF方案下,數據庫主備模式,在高端共享存儲上保存數據庫文件和日志,使數據庫近似於無狀態化。主庫一旦出現問題,備庫啟動並加載共享存儲的文件,繼續提供服務。這套方案能夠做到RPO為零,RTO也比較小。但存在三個問題,一是對高端存儲的依賴,導致硬件成本比較高;二是備庫在日常都是處於空閑狀態,而且造成資源閑置,要知道主備機房通常都是1:1的比例容災,意味着一半的設備閑置;三是因為備庫不是active的,所以需要通過定期演練,確保其可用,增大了使用成本。

這三個問題更具普遍性,基本上所有銀行都會面對(監管要求,商業銀行取得金融許可證大致四年后都要建立災備中心),分布式數據庫是可以解決或部分解決的。
有的同學可能會說,不一定要用分布式數據庫呀,這些問題我們現在已經解決了。下面,讓我們來梳理一下通常會有哪些解決方案,有什么利弊。

可替代解決方案

垂直擴展

這是個最偷懶也最可靠的方法。升級加更多的內存、CPU,更換配置更高的機器,自然獲得更好的性能。但是,今天主機已經謝幕,小型機處理能力的上限短期就會觸碰到(對於股份制銀行以上規模)。何況現在X86的呼聲高漲,小型機也注定是明日黃花,所以硬件不能完全解決問題。

讀寫分離

這個方案也很成熟,但並不是對所有應用都有效。讀寫分離通常都是異步數據同步,存在一定的時延,如果你的查詢業務能夠容忍這個時延,確實是很好的辦法。但如果要求主從庫強一致性,視圖通過強同步方式實現,就會有很大的問題(我們在以后的副本同步專題再展開討論),再者寫性能並沒有得到提升,很多問題也沒有得到解決。

微服務

對數據庫而言多數就是垂直分庫分表,如果沒有分布式事務的干擾,分庫是個好辦法,付出代價就是微服務本身的改造成本。但微服務不代表沒有熱點服務,仍然可能造成性能壓力。其次,如果不是業務本身,僅為了分攤壓力而拆庫,會將很多事務的東西暴露到應用層,會加大應用的復雜度。
如果上述方式都不能解決問題,我們還有最后兩招,水平分庫分表和分布式數據庫。事實上,爭吵最多的也是這兩方案的擁護者,畢竟其他方案的利弊還是比較容易看清的。

水平分庫分表

也就是Sharding+Proxy。直接拆數據庫對應用影響太大,大家都感覺疼,所有加個Proxy讓應用感知不到,這個想法很棒。所以Proxy的方案還是蠻多的而且歷史悠久,比較代表性的Sharding-JDBC/TDDL/Atlas/MyCat。這類方案面臨的幾個問題
1、跨分片的SQL怎么處理
2、唯一鍵、外鍵等全局約束怎么處理
3、全局ID如何生成
4、分片通常是基於業務鍵Hash,要求數據存在一個穩定的業務鍵恰好能解決訪問熱點,業務是否支持。
5、是否支持分布式事務
這個方案也在不斷的演化來解決上述問題,直到DRDS及類似方案的出現,已經轉化為Proxy流派的分布式數據庫。

分布式數據庫

可以分為三類,一是Aurora為代表,以log is database為理念,但不適用於多數的銀行場景;二是Proxy流派,就是在Proxy的延續,內核還是關系型數據庫(多采用MySQL),增加了SQL解析適配、節點調度、全局事務控制等內容。二是NewSQL流派,通常是存儲引擎與計算引擎分離,訪問接口兼容傳統關系數據庫SQL,存儲采用KV存儲和LSM模型,主副本采用Paxos/Raft協議同步,支持分布式事務,完全的ShareNothing架構。目前基本主流的方案是在后兩者中選擇。(具體的介紹會在后續文章中展開)
記得看過一個很貼切的比喻,IT系統就像時裝,既要有實用性,還要符合時尚潮流。我們用來討論分布式數據庫也很合適,上面說了主要是實用性,還要講講時尚潮流。

時尚潮流

鼓勵創新和扶持民族產業是過去五年一個的主基調,相信在未來很長一段時間也不會變化,這應該就當今中國是最大的時尚潮流。銀行業處由於業務穩定的要求,在技術選擇上偏向保守,重視案例,所以頭部企業有很強的示范效應。我們談到的很多問題,可能真正有迫切要求的是在大中型銀行,但這種示范效應很可能會帶動其他銀行的技術轉型。
在公開媒體上我們可以看到,南京銀行、浙商銀行引入了OceanBase,中信銀行與中興通訊合作自研GoldenDB,三家銀行都已經在生產環境投產。宇宙行也提出了分布式數據庫的研究計划。開源數據庫方面,對標Google Spanner的TiDB/CockroachDB得到廣泛關注。
Ivan做一個大膽的預測,未來一兩年內頭部示范效應就會充分顯現,隨后的兩三年很可能會出現一次分布式數據庫為代表的基礎架構升級,涉及四大行、多數股份制銀行和少數城商行。
相信到看這里,你已經有了自己的答案。無論是否選擇,優秀的你怎么能不了解分布式數據庫呢,不能讓技術的貧窮限制了我們的想象力。
歡迎繼續關注分布式數據庫的系列文章。

原文首發在公眾號“金融數士”


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM