?金融行業，作為數據使用的“高地”，長期以來非常重視數據技術發展。作為金融行業的重要組成部分，銀行業一致致力于構建穩健的數據基礎設施。作為數據的主要載體，數據庫在其中扮演著非常重要的角色。隨著近些年來，以分布式、云原生、多模異構等為代表的新型數據庫產品出現，銀行業正在經歷新的一輪技術迭代更新周期。但因銀行業務系統非常復雜，很難找到一種“完美”產品覆蓋所有業務場景。如何根據金融業務場景，找到最適合的數據庫成為廣大金融從業者需面對的問題。本文，嘗試從銀行業業務特點出發，從業務特點、技術特征、技術路線等角度，闡述如何解決這一問題。

1. 銀行業業務場景分析

銀行業務非常復雜，在一個中等體量的銀行中，會存在數百上千的業務系統。這些系統可按照其業務特點進行分類，不同分類的業務系統的使用人群、訪問特征、可用性等乃至對底層基礎設施的要求也有所不同。下面針對業務系統本身，做個簡單分類。

2. 業務場景技術特點分析

1)業務應用分類

銀行業務非常復雜，在一個中等體量銀行中，會存在數百上千業務系統。下面從業務應用角度對系統做個簡單分類。

• 流水型系統

流水型系統實現實時支付、證券交易、訂單等業務的發起方和接收方之間的轉接功能，典型的流水型系統是銀行渠道系統、轉接清算系統、非銀行支付機構的快捷支付（協議支付）系統等。對于此類系統，業務請求和業務請求響應需要實時轉發至業務發起方和業務接收方，對系統的實時性有較高的要求，但關鍵數據（如交易涉及的賬戶數據）的一致性由業務發起方和接收方保證，流水型系統對業務的流水信息進行記錄。流水型系統的冪等性處理是架構設計的重點和難點，可采用多層冪等保障機制，如用戶發起業務流量環節冪等、實時業務處理環節冪等、交易對賬環節冪等。

• 賬戶型系統

賬戶型系統主要實現賬戶信息、用戶信息等業務數據的處理和記錄。此類系統需要優先保障關鍵數據的一致性，當災難或故障發生時，應在達到關鍵數據一致性的前提下，實現業務可用性。賬戶型系統的數據一致性是架構設計的重點和難點，應結合業務模型選擇解決方案，如關鍵數據采用同步復制等手段、將只讀數據和可寫數據分離、業務處理層與數據存儲層協調工作等。

• 計算型系統

計算型系統實現清分清算、風險控制、商戶結算等相關的計算，還包括金融領域的各種科學、工程、數據分析、音視頻處理等相關的計算。此類系統對輸入的業務進行計算，并將結果輸出至其他系統，計算過程所需數據全部來源于單次計算業務請求或外部系統。此類系統重點保障計算應用的可用性和準確性。采用多活技術的計算型系統，可實現多點計算、多點輸出結果。這樣可將多個子信息系統的輸出結果相互核對，提高準確性，還可在部分多活子信息系統出現災難或故障時，直接取用其余多活子信息系統的計算結果

• 查詢型系統

查詢型系統實現對用戶提供各種用戶信息、交易記錄、交易行情、訂單記錄、發布信息等相關查詢。此類系統中的查詢應用不會對系統存儲的數據進行修改（或者查詢業務流量比率遠遠大于有數據寫入和修改的業務流量的系統），數據主要由外部系統導入。此類系統重點保障查詢應用的可用性，以及被查詢數據的多副本存儲、被查詢數據的多副本之間的一致性，以保證各多活子系統查詢結果相同。采用多活技術的查詢型系統，可實現多點查詢。多個子信息系統之間可分擔查詢流量，并且在部分多活子信息系統出現災難或故障時，可通過其他多活子信息系統查詢信息。

 典型場景介紹 

• 日間聯機業務（OLTP）

聚焦到銀?核?就是客?賬戶查詢、存/取/匯/貸款業務、小額?付業務、代收代繳費批量處理場景等。這類場景特點是業務時效性要求高、不同業務類型SQL混合請求、強事務?致性，小事務高并發。

• 日終批處理業務（OLTP+OLAP）

例如計提結息、總分核對、會計科?記賬、借貸平衡檢查這類時效性要求低?點的業務。在業務時效性要求相對較低，批量提交SQL，單位時間內對單個數據表讀寫量大，大事務高并發。處理上，?先要做分布式處理，然后進?分布式聚合處理、查詢，最后按系統測算量和現有數據量的??分批提交事務。

2)場景技術分類

根據上述不同要求，根據業務場景從技術角度進行分類。可按照如下維度進行區分。其中重點從數據規模、事務一致性、負載特征、數據分析能力、應用適配能力等角度進行對比，并給出建議架構。

3)技術指標分類

上述場景比較抽象，可再從場景的技術指標角度進行分類。下面的適配系統僅為參考，還需看業務系統的具體特點。如下圖

3. 分布式技術方案推薦

近些年來分布式數據庫非常活躍，很多銀行也在做分布式數據庫選型或者已采用分布式數據庫。分布式數據庫的實現路線有多種，主要有以下幾種。

1)分布式技術路線

• 分布式中間件+單機數據庫

這類產品，一般采用了典型的“Share Nothing”架構，實現存儲與計算分離，通過上層無狀態的計算節點提供彈性可擴展的計算能力，下層通過增強單機數據庫提供基礎存儲能力及本地算力。這一架構通過硬件堆疊，可近似線性地提供計算性能和存儲容量，具有可支持超大規模集群的能力。

• 原生分布式數據庫

這類產品，一般也是采用“Share Nothing”架構，實現存儲與計算分離。與上面不同的是，底層多采用自研或裸存儲引擎，數據按規則打散并存儲多個副本，通過paoxs/raft等分布式協議保證多個副本間數據一致。上層實現數據庫基礎的優化器、執行器等組件，對分布式事務、全局MVCC等支持更為徹底。此外，由于其底層的存儲引擎不是依賴某一產品，可根據需要組織數據，因此在適配場景上更有優勢，例如在某些分析類場景可選擇列存。

• 云原生數據庫

在某種程度上講，云原生數據庫也是一種分布式，但與前兩者區別是非Share Nothing架構，而是Share Everything模式。其底層是與分布式云存儲，本質上來說仍然是一種集中式架構。上層的計算部分，是無狀態的一組結點組成。針對這種架構不足展開說明，原因是這種方式是需要對底座有比較重的依賴，無法在金融行業相對要求獨立環境中部署，除非整個底層都更換。因此，使用選擇上存在一定困難。

2)分庫分表類推薦場景

下面針對第一種架構，即“分布式中間件+單機數據庫”，結合之前談到的場景及技術特點，描述下這種架構的適用場景的技術特點。這里說明下，此類產品演進迭代很快，功能也在不斷增強，下面觀點僅代表個人觀點，不代表全部產品能力。