金融行業作為國民經濟的命脈和樞紐，對底層資料庫的能力要求在不斷提高，具有高性能、可擴展、高可用等特性的分布式資料庫是金融行業數字化轉型的重要支撐，

金融企業如何在不同的應用場景下，做好分布式資料庫的選型和落地呢？本文從業務、技術、行業角度出發，從市場發展到落地實踐，全方位全流程為您剖析分布式資料庫在金融場景中的應用與實踐，本文將會為您解答以下幾個問題：

• 如何在品目繁多的市場中選擇一款合適的資料庫？
• 從哪些維度去考察資料庫？
• 資料庫遷移程序中需要注意哪些要點呢？金融客戶的訴求是什么？
• 有無實際的案例可供參考呢？

一、金融業資料庫選型之路

資料庫市場會如何發展，在金融領域首先要看政策與監管，《金融科技（FinTech）發展規劃（2019-2021）》中明確指出要加強分布式資料庫的研發應用，做好分布式資料庫金融應用的長期規劃，加大研發與應用投入力度，韓鋒認為，當前分布式資料庫研發應用的成效就是看金融企業內部是否能夠平穩的推進分布式資料庫的使用，

在我國，資料庫市場起步較晚但發展勢頭強勁，基于國產資料庫的金融科技轉型已不再是難題，但是，品目繁多的資料庫市場和復雜的資料庫技術給金融企業帶來了不小的困擾，如何選擇一款合適的資料庫？從哪些維度去考察資料庫？有沒有參考呢？

選型之前先要了解市場上有什么，基于多年深耕資料庫市場的經驗，韓鋒為大家梳理了資料庫行業及技術的背景，提煉出了目前行業和技術的三大特點，并指出了背后的三大痛點，

1. 碎片化嚴重

數字化浪潮下，企業的資料意識越來越強，資料在企業生產經營的應用廣度和深度都在提升，由此也衍生出豐富的業務場景，

面對豐富的業務場景，市場上很難找到一款資料庫去適配所有的場景，現在的普遍現象是企業在不同的場景下，需要對應不同的產品，來解決相應的問題，且不同的產品提供的技術路線又不盡相同，企業當然很迷茫，由此，在多場景、多形態、多技術堆疊、多元路線的影響下，整個資料庫市場呈現出來的是一種碎片化狀態，

痛點一：在資料庫碎片化嚴重的背景下，企業如何在紛紜復雜的市場中，找到一款適合公司的資料庫產品呢？

2. 開源 or 商業

從近十年來的全球資料庫流行趨勢中我們不難發現，開源資料庫的流行程度逐年上升，甚至在 2021 年已經超過了商業資料庫，在國內，越來越多的國產資料庫廠商紛紛走向開源，開源對國產資料庫來說意義非凡，是實作彎道超車的最佳拐點，因為資料庫作為基礎軟體，技術門檻相對較高，整體的架構設計也較為復雜，開源則能夠大大降低資料庫的使用門檻，使得越來越多的開發者能夠參與到開源生態中去建設，無論是植根資料庫內核技術上，還是打磨資料庫應用場景方面，開源都能夠加速國產資料庫的普及與使用，

痛點二：對企業來說，開源和商業，到底怎么選？

從早期的架構選型，到中期的開發部署，再到后期的運營維護，開源資料庫和商業資料庫之間都有非常明顯的差異，需要企業基于自身的業務特點、公司實力從各個維度去評估，

3. 廠商分化

據統計，資料庫賽道上已有 200 多家廠商，并且還有越來越多的國內外廠商參與進行，國內的資料庫市場中可以分成四大類資料庫廠商，扎根資料庫領域多年的傳統廠商、深受資本關注的初創廠商、創新資源交付形態的云廠商、資料庫上下游的跨界廠商，在國外，可以分為資料庫老牌廠商以及活躍的開源廠商，

痛點三：在廠商分化，百花齊放的資料庫市場中，企業該如何選擇？

企業要對業務場景有明確的認識，資料庫在金融行業的應用非常廣泛，場景非常豐富，而分布式資料庫往往需要有明確的適用場景，因此，選型的資料庫產品是不是適用于這些場景呢？韓鋒認為前提是企業要認識到自己的場景到底是什么，下圖是金融業資料庫使用場景的簡單劃分，主要包括業務、資料規模、一致性要求、負載特點、分析能力等方面，韓鋒強調，客戶在選型的時候，要明晰一款資料庫是很難甚至是不可能適用于所有場景的，

更進一步地，韓鋒提供了更多維度的考察點，如下圖所示包括性能、擴展能力等多個具體的技術細節上，我們可以看到不同場景下的差異是非常明顯的，韓鋒以資料分片為例，從技術角度上為大家詳細闡述了如何考察資料庫的能力，

資料庫是非常復雜的系統工程軟體，在選型時要注意的細節其實還有很多，韓鋒總結了幾個觀點，給企業的選型之旅提供方向，

第一，尊重路線之爭，無關乎技術領先性，最好的資料庫產品是適合企業業務的，而不一定是技術最先進的，選型一定要結合業務，不要寄希望于大一統的方案，

第二，成熟度有待完善，但時不我待提前規劃，分布式資料庫確實是一種新興技術，成熟度有待完善，但企業在這個程序中不能“等靠要”，還是得參與進去，不斷打磨，才能越用越好，

第三，國產資料庫百花齊放，機會無限，這一現狀倒逼企業需要具備清晰的考察標準，嚴格考察市場現有產品，才能最終篩選出真正有實力，

第四，謹慎技術選型，不迷信廠商宣傳，真正選型程序離不開測驗，要想對產品有非常全面且準確的了解，需要在企業自己的環境中測驗，這樣的結果才更具有說服力，

第五，選產品選的是標準，很多企業擔心廠商系結問題，韓鋒認為這個問題有一部份是兼容性帶來的，因此，在選擇產品的同時，我們要關注標準，盡量兼用某個通用協議的產品，相對自由度較大，便于后續更換資料庫，

最后，保留技術敏感度，緊跟時代步伐，資料庫技術迭代很快，金融企業客戶要時刻關注技術發展，基于自身的業務進行思考是否升級，在具體措施上，可以選擇架構前置、謹慎選型，區域試點、多線布局、掌握主動、自建增強等策略，

點擊觀看講師分享視頻，了解更多細節哦！

二、分布式資料庫在金融場景下的實戰

作者｜王東，南云鵬

在互聯網金融的大背景下，農商銀行面臨著多重挑戰，具體表現在第三方金融、大型金融機構大幅占據市場；客戶在服務體驗上的要求不斷提升；年輕客源流失嚴重；存款理財等負債資金成本越來越高；線下渠道使用率大幅降低等，

農商銀行這類金融機構普遍承擔著發展落實鄉村振興戰略，推動貧訓金融的落地重任，又是支持縣域經濟發展與服務三農的金融主力軍，要想做好貧訓金融的作業，金谷銀行亟需借助金融科技力量來解決上述的難題，經過充分調研，金谷銀行立刻啟動了互聯網金融平臺的建設作業，

金谷銀行表示當時的預期就是搭建一套需 IT 人員配置少、技術力量要求不高，穩定的、管理簡單、高可用、高并發且易于擴展的基礎架構，選型期間重點考慮四個方面：首先是大并發與高可用，在面向互聯網的業務在技術架構上，一定要考慮 7 x 24 小時不間斷業務與交易峰值的場景；其次是易于維護與管理，這與農商銀行自身的特點高度相關，農商銀行普遍存在 IT 基礎薄弱，人力資源有限的問題，因此操作簡單，學習成本比較低的平臺更適合，第三，采用分布式存盤，這是因為集中式存盤成本高、管理難度大、技術要求也比較高，最后是技術選型的前瞻性和架構設計的合理性，

南云鵬自畢業后就一直在金融機構從事 IT 技術相關的作業，基于 15 年的作業經驗，他整理分享了在傳統資料庫運維管理中存在的一些難題，

1. 傳統架構下資料庫版本和種類較多，人員學習成本高，掌握知識泛而不精，因為沒有統一平臺，甲方只能跟著乙方走，乙方提供什么甲方就被動地接受什么，

2. 煙囪式資料庫，運維自動化程度較低，導致作業及時性差，維護成本高，運維人員在維護資料庫的同時，還要維護作業系統，還要兼顧硬體環境等，

3. 日常運維的作業比較繁瑣，所有的操作基本都是人工完成，包括用戶、表空間等等，這些人工操作，存在很大的風險，因為出錯率比較高，難以形成統一的標準，

4. 集中式的架構橫向擴展能力較差，面對性能不足、容量不足、空間不足等場景，用戶能做的只有增加 CPU、增加記憶體、增加存盤或者換機器的方式，但這些解決方案都無法保證業務的連續性，

5. 集中架構下高可用性也難以保障，業務服務能力完全依賴于高性能的主機，一旦主機出現問題，解決方案將十分復雜，對開發人員的要求也比較高，

此外，在資料備份恢復歸檔管理、統一監控管理和運維標準上都存在著困難，這就導致運維作業雜亂、繁瑣，基本上遇到一個事情是一套方法，或者一套臨時性的方案應對，

在運維架構設計的程序中，金谷銀行結合實際的業務需求制定了一套合理合適的運維架構，幫助規范日常作業，同時滿足監管要求，

運維整體架構分成基礎環境層、規范制度層、業務層、工具平臺以及監控層，最底層的作業包括業務如何落地、運維架構如何搭建、如何開展相應的運維作業、如何減少系統的例外場景以及如何保證業務系統的連續性等，基礎環境依托在騰訊云平臺上，在這個基礎上金谷銀行制定了自己的規范與制度，

在規范制度層，金谷銀行針對作業系統中間件、網路配置、資料庫等日常基礎的標準環境，制定了相應的機械性與規范性的檔案，這樣能夠保證所有的業務系統，盡可能地在一個安全、規范的環境下開展運維的作業，也減少運維人員日常的管理難度，在容量管理、問題管理、應急管理等領域，金谷銀行也制定了相應的制度，這些制度一方面保證了資源的合理利用，另一方面也幫助銀行內部進行知識沉淀，

在業務層主要是做一些部署和集成的作業，在此基礎上，金谷銀行構建了工具平臺，包括堡壘機、運維管理平臺以及自動化發布工具，堡壘機是日常運維操作的一個入口，所有對后端業務系統的操作都是通過堡壘機進行的；運維管理平臺是對資源進行管理，比如資源的增加或減少以及對物理主機的管理等；Jenkins 是自動化開源發布工具，負責日常系統的變更、生產版本的發布以及發布完的結果反饋，

運維監控平臺的構建納管了所有業務的監控，主要建設了系統監控平臺、業務監控平臺以及行為監控平臺，其中，系統監控平臺監控著物理主機 CPU、記憶體等物理資訊、基礎資訊等，同時監控了一些業務系統的服務埠，比如說開啟 7001、8003 等，保證業務是健康存活的狀態，如果業務埠宕掉了，也會有及時的短信告知等；業務監控平臺是偏向于交易型別，比如說熱點事件、大量的訪問行為或攻擊行為等，確保系統不被羊毛黨、黑灰產惡意攻擊；行為監控指的是內部操作行為的監控，以便追溯風險源，

最后，南云鵬基于日常作業中的實際操作經驗，詳細闡述了資料備份恢復、切換演練、容量管理和巡檢作業中的操作流程、注意事項及優化方案，

點擊觀看講師分享視頻，了解更多細節哦！

三、金融應用場景對分布式資料庫的訴求

銀行業是相對傳統的金融行業，數字化轉型程序中首先追求穩定，金融 IT 側是趨于保守的，從銀行業部署架構趨勢來看，早期通常是將服務器集中部署在大型機上，為的就是穩定、高效、多并發，隨著應用的發展，銀行業的流行架構開始變成基于服務器來搭建不同的應用，Oracle 資料庫開始席卷市場，后來，X86 服務器興起引起應用架構開始發生變化，盡管這時候資料庫市場還離不開 Oracle、DB2，但去 IOE 理念已經萌芽了，如今，在國產化浪潮下，自主可控的必然要求使得國產分布式資料庫的流行，銀行業需要將曾經部署在 Oracle、DB2 等資料庫上的資料遷移至國產資料庫上，這時候資料庫遷移程序中的問題開始顯現了，

基于公司多年的資料庫遷移經驗，孫亮以兩個國產資料庫對接案例為切入口向大家詳細的闡述了遷移程序中的注意事項及優化項，總結來看，首先是分片鍵的配合，一定要帶上 Shardkey，在資料量很大的情況下，能夠保證精準分配；在報表規范、交易介面、資料傳遞程序中，要考慮到分片鍵如何向下傳遞，其次是** SQL 的優化特性，需要注意唯一性的要求**，高唯一性的資料欄位向前放，可以達到更好地索引命中的可能，

接下來是資料庫序列，每個資料庫的序列都不相同，這導致在資料庫遷移程序中需要重新對資料序列做分支方案，做歸攏操作，現在的解決方案是先在技術平臺上做獨立的序列組件，通過序列組件去做整體的序列，最后，日終并發程序當中存在資料分布不均勻的情況，這也是對資料性能的影響，我們需要重點關注分片鍵是否設定得合理，是否可以達到資料平均化，或者把資料能夠真正離散掉，

結合銀行業的特點，孫亮為大家分享了幾點在金融應用中常見訴求，金融行業的應用軟體最高優先級關注點就是穩定性，孫亮認為很多不太優雅甚至是不太合理的基礎轉型，其實都是考慮到優先穩定性的要求，目前整個金融行業很關注的一點就是，遷移到國產資料庫下，穩定性是如何保障的？同時容災程序當中 RPO、RTO 真實的情況下能做到什么樣的情況？包括同城、異地 RPO 也是重點關注的，雖然同城可以做到 RPO 為 0，但如果切到異地，RPO 不能為 0，容災還是有一定的風險，金融行業是一定要考慮的，

在遷移程序中，我們關注遷移的難易程度，簡單說就是 SQL 語法的兼容性，我們更期望于國產資料庫這一側，能夠將這些語法盡量做到統一，減少上層大量的適配、改造，資料庫的性能也是關注的重點，容量到底有多大？在金融行業或者在金融軟體用戶側，我們認為資料庫的容量其實更多指的是在指定表寬度下，單表最多能容納多少條記錄，才會產生性能拐點，這就是表容量，而不是一些國內外一些資料庫宣傳時提到的每個資料檔案能夠支撐多少 T 的資料，

另外以往缺陷率能否在現有版本當中進行修復也是需要重點關注的，如果大家都認為缺陷修復了，但由于分支的問題而被規避掉了，結果又被重新觸發起來，這樣得不償失，因此這類問題需要國產資料庫在內核構建中就得處理掉，

除此之外，基于公司的實施經驗，孫亮還提出了在問題排查、運維部署以及術語對齊上的訴求，同時，對國產資料庫提出了更高的要求，異地同步能否做到 RPO 為 0？多地多活是否可以在資料庫層面實作？分布式事務是否能在資料庫層面做到 XA 事務，讓分布式事務變得和本地事物一樣簡單容易呢？

最后，孫亮基于行業經驗及市場觀察，對現有的三款分布式資料庫型別進行了對比總結，其維度包括了一致性、性能（回應時間、并發能力、批量性能）、擴展性、生態、自主可控、高可用及部分形態（是否支持云原生部署等），可作為客戶選型前的參考，

點擊觀看講師分享視頻，了解更多細節哦！

四、金融級分布式資料庫探索實踐

分布式資料庫是基于業務與技術的需求和發展以及監管要求下，解決當下以及未來趨勢發展等問題，更優更穩定地滿足金融銀行業發展的選擇，短期看雖有不足，用長遠和發展的眼光看，對支撐金融需求、滿足監管要求、提升自主可控能力、有效降低風險、合理控制系統建設成本等諸多方面都有助力和支撐作用，是金融銀行業基礎設施、基礎軟體建設的重點之一，

近年來，銀行業在內外部金融環境的快速變化中持續進行轉型和發展，從零售轉型到互金 / 直銷以及多渠道豐富金融產品的興起，從追求業務多元化到追求場景化創新，基于持續不斷的技術發展、業務創新積累下，再到金融數字化轉型深入推進，這些對金融系統的技術架構有了更為嚴格的標準和要求以及訴求，面對此背景和發展的時代，我們首先要滿足高可用及雙中心級以上容災，這是銀行或金融業對技術架構最基本的要求，在此基礎之上要滿足交易高頻高效、低延遲的金融場景處理要求，再衍生到高吞吐能力，在適配和實踐中，需要按照銀行系統的分類進行，每類系統特點對資料庫要求和特性也不一樣，

金融業務系統資料庫的場景維度可簡單劃分成為兩類，第一類是日間交易場景，聚焦到銀行核心就是客戶資訊查詢、存貸款業務、支付賬務業務、代繳費批量處理場景等，這類場景的特點就是要求時效性和強一致性，所以必須滿足高并發、高性能，第二類是日終批處理場景，例如計提結息、總分核對、會計科目記賬、借貸平衡檢查這類時效性要求低一點的業務，在批量提交 SQL 時并發量大，單位時間對單表的讀寫量大，這種情況首先要做分布式處理，然后進行分布式聚合處理、查詢，最后按系統測算量和現有資料量的大小分批提交事務，

基于多年的行業架構經驗，賈瓅園從金融資料庫實施角度出發，重點介紹了作業評估中的七個重要維度供參考，在實際應用程序中，企業應結合自身業務特點來評估維度的優先級，并且，一定要進行測驗，以測驗結果為準作為最終的評估依據，

1. 批量業務場景需求評估，這一點關乎金融資料庫的安全性和資料強一致性，從客戶端來看，直接影響到用戶體驗以及銀行間的清算作業，因此，要重點評估大批量資料操作時，對資料庫的吞吐影響情況，

2. 資料有效遷移需求評估，在投產程序中，遷移的時效性也直接影響到體驗以及銀行業行間清算、投產相關的安全平穩度，

3. 未來 5 年資料庫容量評估，資料庫建設往往是系統工程，涉及到業務系統的匹配、硬體的匹配、網路匹配，甚至是團隊的技術知識匹配，其投入成本巨大，不可能僅使用一兩年就更換，

4. 高峰值 TPS/QPS 需求評估，基于我國的人口紅利，在應用場景中不乏有大量用戶使用，而金融系統應用以穩定性為先，因此并發壓力特點下對資料庫性能的要求非常高，

5. 高可用、容災需求評估，兩地三中心，吞吐量要求、IO 要求等都是重點考量點，業務屬性較強的系統，需要與資料庫高可用架構和容災設計相配合，在保障高吞吐量的前提下，同時保持故障切換的靈活性與時效性，對業務影響較低且滿足監管要求，

6. 備份需求評估，因為云化將是未來分布式資料庫的發展方向，所以面對傳統的網路環境、流量限定等也會有一定的要求，存盤方面也從原來的集中式存盤，變為分布式存盤，這些變化不僅僅是每個單項的技術發展，還可能是綜合影響，

7. 應用接入需求評估，什么系統可以直接適配？什么系統需要轉化改造？這些需求評估在銀行選型期間是考慮的重點，

此外，賈瓅園聚焦資料庫語法維度，在六大使用場景中為開發者提供了適配優化方案，這六大使用場景包括了 SQL 陳述句、函式 / 關鍵詞、設定 / 語法、索引、資料型別轉換、分片 / 磁區優化，

點擊觀看講師分享視頻，了解更多細節哦！

標籤：其它

上一篇：史上最全Mysql規范

下一篇：干貨，分布式資料庫在金融核心場景的落地實踐｜騰訊云資料庫