網商銀行資料庫迭代記，OceanBase助力金融創新實踐

2020年12月21日第十一屆中國資料庫技術大會（DTCC 2020）於北京如期舉行，網商銀行架構師，儲存底盤負責人楊祥合先生，在 “OceanBase 企業級分散式資料庫實踐專場” 分享了《網商銀行分散式資料庫應用實踐》的演講，以下為演講實錄：

 

隨著資料量爆發，業務日益複雜，現今 IT 環境中面對的場景複雜度和故障率也越來越高，甚至在國內出現了多起資料安全“黑天鵝”事件。以下分享將以網商銀行的架構歷史演進和對資料庫的應用徐徐展開，以期給諸位帶來啟發。

網商銀行架構史，斬獲人行科技獎

網商銀行是一家以普惠金融為使命的網際網路銀行，業務主要面向三農和小微企業。技術底盤架構在螞蟻金融雲和 OceanBase 上。作為 OceanBase 服務的第一家銀行，網商銀行對高併發、擴充套件性、資料一致性的需求一開始就存在。而在資料庫選型的過程中，首先考慮的是高可用和高彈性，其次是低成本和自研。

我們先從儲存架構和資料庫版本兩個方面來談談網商銀行的發展史。

儲存架構方面，從最初的兩地三中心，到後來從 OceanBase 0.5版本升級到 OceanBase 1.0版本，實現了三地五中心的單元化。“三地五中心”，即在三座城市部署五個中心，一旦其中一到兩個中心發生故障，甚至一個城市出現問題，業務都能夠在 30 秒內自動恢復。

2019年，將 OceanBase 在高可用、擴充套件性用於混合雲架構，在做多雲架構時，面對不同業務目標的多朵雲，可以一鍵將資料擴充套件到另一朵雲上。2020年，開始落地雲原生架構，配合全棧加密，從使用者資料進入到服務的全過程，整個生命週期資料傳輸加密，落在磁碟上的資料都是密文。

在資料庫方面，網商銀行基於分庫分表的資料庫架構，從設計之初就設定單元化的目標。使用分庫分表多叢集，解決了庫設計上的單點問題，資料庫的升級、備份等在不同叢集之間錯峰進行，避免影響全域性。

網商銀行架構師， 儲存底盤負責人 楊祥合

網商銀行到底有怎樣的技術實力？這在網商銀行成立之初，就在行業中引起了熱議。當時我們做了一個勇敢的決定，在生產系統中來一次斷網演練。當完成了相關的報備後，我們就正式開始了這次斷網演練，直接把生產系統中其中一個機房的流量全部斷掉。 讓行業震驚的是，網商銀行用了不到 1 分鐘便實現了快速恢復，這背後其實充分體現的就是 OceanBase 的高可用、快速恢復的自治能力。

整個三地五中心異地多活的專案落地之後，我們把專案上報到人行， 該專案最終獲得了人行科技發展二等獎。實際的生產環境中，網商銀行利用人行的視窗，定期做斷網演練，這是發現自身問題的重要舉措。

網商銀行架構一覽，從分庫分表到批場景

OceanBase 不只是資料庫，雲原生架構之後，可實現鏈路加密，在 ServiceMesh 做加密，資料庫做解密。目前，網商銀行資料庫叢集規模 100 多套，資料量達到 PB 級。線上庫和歷史庫架構中，歷史庫訪問量較低。雲原生微服務起來後，資料庫、業務系統不斷被拆分，需要下游的核心能力，包括建立一些基於 AI 能力的加持。

在分庫分表方面，網商銀行採用分割槽架構，在生產實踐當中，有熱點庫、熱點行、熱點表等挑戰，這些熱點利用分割槽的能力，每一個分割槽獨立到一臺機器。

銀行業務中的海量資料的處理方面，資料庫設計是每批次併發處理 13~130 億。具體邏輯為，每個批次查詢 5000-100 萬條，單表拆分片數 13 片到 2600 片，按照這個邏輯，網商銀行使用了 999 分片，最大每批次可處理 130 億賬戶。

批場景中，利用分庫分表的基礎上，使用表分割槽提高併發跑批能力。如銀行工資代發、團體險等需使用表分割槽的能力，如企業人員匯入，原本一個單表匯入做成多個分割槽，把不同的資料打散不同的分割槽上提升效能。

業界有廠商宣稱，庫高可用是人為切主對業務無影響。我們認為應增加主庫當機 1 分鐘內自動恢復，且資料保持一致的要求。網商銀行資料庫的標準是在此基礎上，兩個機房同時故障，也能夠達到 RPO=0、RTO<1分鐘。

金融業選型建議，從資料庫到歷史庫

資料庫選型，效能隱私雙保險

一是主備模式不適合金融高併發場景。主庫出問題需層層上報，強拉備庫為主會丟資料。如果採用強同步模式，經測試效能會降 10 倍，這種效能下降是無法接受的。

據中國信通院釋出雲資料庫標準選型建議，一致性協議應該成為金融資料庫標配。 高可用架構=快速恢復+最小影響面。快速恢復依賴一致性協議的加持。最小影響面分橫縱兩個緯度，橫向拆分成多個叢集、做分庫分表和表內分片，縱向拆分成多個機房，讓不同範圍的使用者編號進入到不同的機房，這樣單機房/單個分庫的故障影響面影響降到最小。

國家越來越重視使用者隱私，使用者安全的主題下，將全行資料加密提上日程。資料從金融閘道器進入網商那一刻起就變成密文，密文傳輸、密文儲存；銀行的備份和傳統企業不一樣，既要有同程備份又要有超遠端的備份，中間有網路傳輸加密、透明加密，傳輸到超遠端機房，再做一層儲存透明加密。

 歷史庫選型，讓資料遠離丟失風險

冷熱分離為什麼會帶來資料丟失的風險？因為，線上資料庫透過讀取校驗整個資料，CRC 驗證 block 完整性，冷資料如果發生故障，沒有讀請求來驗證資料塊是否正常，從而難以發現壞塊，極端情況甚至會導致多個副本永久丟失。

OceanBase 資料庫有一個後臺的程式，不間斷掃描資料進行校驗，以此發現問題，讓資料庫的備份真正的有效。如果幾個月後才發現問題，為時晚矣，因為資料備份儲存不了那麼久。根據我們的歷史庫選型原則，一定要有後臺校驗，讓資料遠離丟失風險；此外，還要關注加密，保護使用者隱私。

高效能探索實踐，創新迭代扛大促

網商銀行和 OceanBase 一路創新前行，不斷探索向上。

線上效能摸底—鏈路壓測

網商銀行用的全鏈路壓測方法進行容量摸底。透過壓測程式碼上傳到平臺，將產出的流量打入金融閘道器，閘道器呼叫一層層業務服務。直接在生產系統進行壓測，標透過標記區分是壓測的業務，中介軟體把壓測流量打到影子庫中去；整體上，流量穿越所有的微服務鏈路，透過全鏈路壓測進行容量摸底，確保鏈路上無單點流量瓶頸。

每年大促活動前，透過全鏈路壓測進行容量摸底。

  混合雲彈性架構—大促彈出(20%)

假如網商銀行一朵雲上機器資源已用盡，能否並讓流量跑到另一朵雲上？透過混合雲的彈性架構，資料庫的一鍵擴充套件，應用上做單元化適配。今年大促最終彈出 20% 的流量到新雲上，充分驗證了 OceanBase 的快速的擴充套件能力。

OceanBase 致力於打造金融行業銀行業的資料庫，同時最令人驕傲的一點是 OceanBase 是中國人自己的資料庫，希望行業同仁的交流能帶來更多創新的嘗試，帶動國產資料庫走向更廣闊的發展。