網商銀行資料庫疊代記，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 是中國人自己的資料庫，希望行業同仁的交流能帶來更多創新的嘗試，帶動國産資料庫走向更廣闊的發展。