從上世紀90年代正式起步至今，中國數(shù)據(jù)庫發(fā)展已走過近30年歲月。以2000年前后為拐點，以MySQL為首的開源數(shù)據(jù)庫，在互聯(lián)網(wǎng)廠商的推動下，逐步進入生產(chǎn)業(yè)務；而為了使單實例能力平庸的MySQL能夠滿足高性能要求，互聯(lián)網(wǎng)廠商開始將原來的數(shù)據(jù)庫與表通過各種邏輯進行拆分，形成了新的技術(shù)路線。這，就是分布式數(shù)據(jù)庫。
在2023華為金融創(chuàng)新數(shù)據(jù)基礎(chǔ)設(shè)施峰會，華為與一眾銀行、證券等金融行業(yè)伙伴，聯(lián)合發(fā)布OceanData分布式數(shù)據(jù)庫存儲解決方案，提出以專業(yè)全閃存存儲和存算分離架構(gòu)，使能分布式數(shù)據(jù)庫創(chuàng)新升級，助力金融行業(yè)數(shù)據(jù)庫平滑改造。此次發(fā)布引起行業(yè)熱議，什么是“分布式數(shù)據(jù)庫存儲解決方案”？華為為何與金融行業(yè)伙伴聯(lián)合發(fā)布？又為何如此強調(diào)“存算分離”？本文將從此話題出發(fā)，詳細剖析華為此次大會發(fā)布的方案內(nèi)容，和背后金融行業(yè)數(shù)據(jù)庫分布式改造不得不說的故事。
存算分離，金融數(shù)據(jù)庫改造的重要抉擇
在金融行業(yè)內(nèi)，數(shù)據(jù)庫使用的主要場景有核心交易、互金類APP、分析類應用、辦公等內(nèi)部應用等。其中核心交易場景常使用IBM大型機+DB2或小型機+Oracle，對數(shù)據(jù)庫的時延、強一致性和可用性有非常高的要求；互金類應用要求數(shù)據(jù)庫有高并發(fā)和易擴展能力，同時對數(shù)據(jù)一致性、數(shù)據(jù)庫可用性也提出了較高的訴求，常常使用MySQL類分布式數(shù)據(jù)庫+容器的技術(shù)。
如今，隨著金融業(yè)務規(guī)模逐步擴大和政策形式的變化，金融行業(yè)各業(yè)務場景數(shù)據(jù)庫系統(tǒng)正在逐步向國產(chǎn)數(shù)據(jù)庫改造；但除了辦公等非關(guān)鍵業(yè)務場景，核心業(yè)務場景改造仍進展緩慢。對于這一現(xiàn)象，其根本問題在于國產(chǎn)數(shù)據(jù)庫，尤其是分布式數(shù)據(jù)庫，大都采用存算一體架構(gòu)，使其在數(shù)據(jù)層面可用性、性能和可管理性都缺乏保障，難以滿足金融行業(yè)要求。
從技術(shù)角度分析，存算一體架構(gòu)的數(shù)據(jù)庫，的確難以滿足金融核心場景訴求。存算一體架構(gòu)指的是采用服務器本地盤存儲數(shù)據(jù)的架構(gòu)；由于服務器本地盤的可靠性不足，存算一體架構(gòu)下數(shù)據(jù)庫往往通過一主多備的形式提升系統(tǒng)可用性。但在主庫和備庫間同步數(shù)據(jù)時存在一組難以克服的矛盾：如果主備間采用同步復制，即備庫數(shù)據(jù)庫從邏輯上與主庫完全一致，則嚴重影響主庫性能；如果主備間采用半同步或者異步復制，則無法保證主備數(shù)據(jù)完全一致。這一矛盾在分布式系統(tǒng)性中無法調(diào)和，這也使得該類數(shù)據(jù)庫幾乎無法同時滿足金融核心高性能和強一致性的要求。
對于金融核心場景，容災是必要的能力。根據(jù)《商業(yè)銀行數(shù)據(jù)中心監(jiān)管指引》要求，總資產(chǎn)規(guī)模一千億人民幣以上的商業(yè)銀行和省農(nóng)信等，應該設(shè)立異地模式災備中心，且要求至少達到RTO <2天、RPO 0-30分鐘的容災水平；實際上對于五大行或頭部股份制核心系統(tǒng)，基本要求達到RTO分鐘級、RPO=0的最高水平。而開始提到存算一體架構(gòu)在主從復制間產(chǎn)生的問題，在容災場景下表現(xiàn)更為顯著，因為鏈路拉遠后故障場景更為復雜（如鏈路抖動、光纖劣化等），而當前還沒有廠商在服務器+以太網(wǎng)上對這一問題進行成熟優(yōu)化。因此，目前采用存算一體架構(gòu)的數(shù)據(jù)庫，幾乎都采用單集群拉遠+異步復制模式，核心業(yè)務下分布式數(shù)據(jù)庫強一致性容災的案例基本沒有。
在管理面上，存算一體同樣存在許多問題。由于計算和存儲強綁定，導致資源無法按需擴張，勢必導致一邊資源出現(xiàn)浪費；從實際落地來看，由于服務器容量有限，計算資源往往是浪費較多的一方。許多率先進行數(shù)據(jù)庫分布式改造的金融用戶，已擁有近萬臺服務器，但CPU資源利用率還不到10%；而這近萬臺服務器里有數(shù)十萬塊硬盤，對其健康度和故障的管理更是令運維大呼頭疼。
對以上問題進行根因分析，除了分布式系統(tǒng)無法擺脫的“CAP詛咒”以外，歸根結(jié)底還是因為服務器本身不太關(guān)注數(shù)據(jù)可靠性和易管理設(shè)計；而當前數(shù)據(jù)庫廠商基本只具備北向滿足用戶功能的能力，對南向提升數(shù)據(jù)高可用、高效率管理能力缺乏技術(shù)積累，無法彌補服務器在該方面的不足，最終導致數(shù)據(jù)庫整系統(tǒng)達不到金融核心要求。
如今，隨著政策形勢和業(yè)務需求變化，國產(chǎn)分布式數(shù)據(jù)庫走向核心已是大勢所趨；與其等待應用層緩慢的技術(shù)演進，把專業(yè)的事交給專業(yè)的人來做顯然是更可行的辦法。專業(yè)存儲專注于數(shù)據(jù)高可用、高性能、易管理，技術(shù)演進已近40年，擁有豐厚的技術(shù)積累和實踐經(jīng)驗，能夠更快的閉環(huán)分布式數(shù)據(jù)庫存在的諸多問題；更重要的是，使用專業(yè)存儲將引導分布式數(shù)據(jù)庫走向Share Storage的數(shù)據(jù)共享架構(gòu)，為改變主備間數(shù)據(jù)同步這一底層邏輯提供了可行性，而這一邏輯正是分布式數(shù)據(jù)庫無法擺脫性能與強一致性矛盾的根源。以上幾點構(gòu)成了分布式數(shù)據(jù)庫走向存算分離架構(gòu)的技術(shù)必然性。如今，不論是AWS Aurora、openGauss，還是PolarDB、TDSQL，都在向存算分離架構(gòu)靠攏，這絕不會是一種巧合
分布式新核心，如何撐起“核心”之名？
因為各種原因，部分大型銀行已經(jīng)啟動了核心系統(tǒng)分庫分表改造，并使用分布式數(shù)據(jù)庫打造新一代核心系統(tǒng)。這就是分布式新核心。然而，正如前面所述，銀行核心系統(tǒng)對于可靠性有非常嚴苛的要求，而當前的分布式數(shù)據(jù)庫大都無法滿足，導致分布式新核心運行的業(yè)務往往并不那么核心。如何讓分布式新核心撐起“核心”之名？華為OceanData分布式數(shù)據(jù)庫存儲解決方案給出了自己的答案。
華為OceanData分布式數(shù)據(jù)庫存儲解決方案基于存儲同步復制技術(shù)，實現(xiàn)了分布式數(shù)據(jù)庫的雙集群容災。相比于傳統(tǒng)分布式數(shù)據(jù)庫采用單級群拉遠的方式，該方案可以有效實現(xiàn)集群間故障隔離，是當前唯一滿足金融核心容災要求的方案。那么華為是如何做到的呢？
以下圖為例。當前分布式數(shù)據(jù)庫大部分采用圖左的復制方式，通過服務器間的以太網(wǎng)絡(luò)，將 主節(jié)點日志同步到各個從節(jié)點。不論采用邏輯復制還是物理復制，該方案最大的問題是因為服務器欠缺數(shù)據(jù)高可用保障能力，需要應用層大量處理遠程容災下的腦裂、鏈路抖動、壞塊、誤碼、丟包等等問題，當前任何數(shù)據(jù)庫都無法提供保障；許多數(shù)據(jù)庫僅通過PAXOS協(xié)議處理腦裂問題，就已經(jīng)對業(yè)務性能產(chǎn)生巨大影響了。這也是為何當前沒有分布式數(shù)據(jù)庫支持RPO=0的多地強一致性容災的原因。
華為OceanData分布式數(shù)據(jù)庫存儲解決方案，讓分布式數(shù)據(jù)庫將Redo Log流寫入存儲，并通過OceanStor存儲強大的同步復制功能，將日志復制到遠端容災數(shù)據(jù)中心的存儲當中；遠端數(shù)據(jù)中心通過日志實時回放，保證了備數(shù)據(jù)庫與主庫的數(shù)據(jù)一致。由于有專業(yè)存儲強大的復制能力保障，主庫事務執(zhí)行不必等待遠端備庫寫入成功，只要日志寫入完成就可以提交，使得其性能相比于當前分布式數(shù)據(jù)庫大幅提升。該方案中，主數(shù)據(jù)中心和容災數(shù)據(jù)中心的數(shù)據(jù)庫是兩個互相隔離的集群，從數(shù)據(jù)面到管理面都是完全隔離的，這很好的解決了因管理節(jié)點或存儲故障導致整個集群發(fā)生癱瘓的問題。相信不少人已經(jīng)發(fā)現(xiàn)，華為方案與oracle ADG實現(xiàn)方式有異曲同工之妙，而Oracle正式憑借企業(yè)級存儲成熟而強大的復制能力做到了這一點。
除了存儲同步復制以外，針對遠程容災難以解決的鏈路質(zhì)量劣化問題，OceanData解決方案也有自己的獨家解法。傳統(tǒng)的容災方案中，只能通過主數(shù)據(jù)中心和容災中心間的心跳包感知復制鏈路劣化，需要花費數(shù)分鐘時間才能察覺，并倒換到冗余的鏈路上，可能導致金融企業(yè)數(shù)千筆交易失??；華為的解決方案通過波分設(shè)備與存儲設(shè)備聯(lián)動感知的SOCC技術(shù)，可在毫秒級時間內(nèi)感知到鏈路劣化，并在兩秒內(nèi)完成鏈路倒換，時刻保證復制鏈路的暢通無阻，避免因抖動對前端業(yè)務造成性能影響或者交易失敗。專業(yè)存儲強大而有效的可靠性保障手段，始終是金融企業(yè)核心價值的守護神；即使在分布式新核心時代，這一點也絲毫不例外。
金融微服務改造，如何擁有金融級高可靠？
容器技術(shù)以其輕量化部署和敏捷化管理的特點，開始逐步在金融行業(yè)獲得廣泛應用；許多金融企業(yè)選擇將互聯(lián)網(wǎng)金融APP等敏態(tài)業(yè)務部署到容器上；而對于部分傳統(tǒng)應用，也掀起了一股微服務化改造的熱潮。
根據(jù)《容器有狀態(tài)應用調(diào)研報告》，由于各類應用需求，數(shù)據(jù)庫是容器化部署最多的應用。然而，容器對于應用的可靠性保障機制事實上比較缺乏，尤其對于分布式數(shù)據(jù)庫這類有狀態(tài)應用，很多故障場景都需要人工介入保障；但對于金融企業(yè)的應用，可靠性都是最不能忽視的重要特性。想象在微服務改造環(huán)境下，成千上萬個Pod同時運行，如果所有錯誤都需要人工介入處理，運維成本無法想象，容器集群穩(wěn)定性將完全不可控。
針對這一痛點，華為OceanData分布式數(shù)據(jù)庫存儲解決方案通過自研容器存儲接口，打造出一套高可靠又不失敏捷的分布式數(shù)據(jù)庫容器化部署方案，讓金融微服務改造的應用，也擁有金融級高可靠。
首先，我們需要介紹下傳統(tǒng)容器的故障處理機制。以目前最常用的Kubernetes為例，在使用有狀態(tài)應用時，一般采用StatefulSet控制器進行容器管理。當一個節(jié)點故障，節(jié)點上的所有Pod與Kubernetes管理節(jié)點失聯(lián)；此時由于Kubernetes無法判斷該節(jié)點是否真的故障了，上面的Pod和服務是否已經(jīng)停止，它不會自動將Pod在另一個正常節(jié)點重新啟動，以避免引起不可預測的業(yè)務錯誤。此時需要人工介入，將故障的節(jié)點從集群中強行刪除，Kubernetes才會重新在新的節(jié)點上拉起Pod和服務。
即使解決了故障拉起問題，采用存算一體架構(gòu)的數(shù)據(jù)庫還會面臨另一個問題：數(shù)據(jù)恢復。由于故障節(jié)點本地盤上的數(shù)據(jù)無法訪問，新節(jié)點需要全量重構(gòu)數(shù)據(jù)后才能成為真正的從庫，這往往依賴于主節(jié)點到從節(jié)點的復制。根據(jù)業(yè)務壓力，單節(jié)點重構(gòu)一般耗時6-10小時，期間業(yè)務性能和可靠性都會受到影響。
針對上述痛點，華為OceanData分布式數(shù)據(jù)庫存儲解決方案從兩方面著手，提升數(shù)據(jù)庫可靠性。
首先，還是基于存算分離，將數(shù)據(jù)庫改造為Share Storage架構(gòu)，通過專業(yè)存儲保障數(shù)據(jù)高可用，服務器故障數(shù)據(jù)不丟；當新節(jié)點拉起時，可將數(shù)據(jù)重新掛載給新節(jié)點，只需要增量同步故障恢復期間寫入的數(shù)據(jù)即可，這樣補從時間可縮短至5分鐘左右，對業(yè)務影響和可靠性風險都大大降低了。
其次，通過存儲與主機間的IO狀態(tài)，主動感知服務器故障，并通過華為自研容器存儲接口實現(xiàn)故障節(jié)點的主動驅(qū)逐，并將故障POD的PV掛載給新拉起的POD，彌補原生Kubernetes依賴人工處理故障的問題。華為解決方案依托存算分離優(yōu)勢，有效解決了云原生應用中存在的固有問題，使金融微服務改造真正達到金融級高可用要求。
傳統(tǒng)核心應用分布式數(shù)據(jù)庫，不分庫分表行不行？
說完了分布式改造的場景，最后來討論這個話題：使用分布式數(shù)據(jù)庫，能不能不分庫分表？相信這是許多DBA的心聲。傳統(tǒng)核心做分布式改造，涉及到大庫表的拆分、切片，存儲過程的改寫，上層業(yè)務要做單元化修正、事務一致性保證、串并邏輯修正等，這些都需要花費大量時間和人力，且很難做到完美。即使完成了改造，跨表Join和事務執(zhí)行效率等還是降低許多，很多存儲過程無法使用，大事務無法使用，對后期的開發(fā)也造成了許多困難。
分庫分表雖然在高并發(fā)場景的確有一定優(yōu)勢，但對于大部分非互聯(lián)網(wǎng)企業(yè)而言，其代價和收益不成正比。是否有辦法幫助金融企業(yè)平滑渡過這最難的一關(guān)呢？華為OceanData分布式數(shù)據(jù)庫存儲解決方案同樣給出了回應。
追本溯源，為什么分布式數(shù)據(jù)庫需要分庫分表？其根本動機是，以MySQL為代表的開源生態(tài)數(shù)據(jù)庫，其實例能力完全無法與Oracle等商用數(shù)據(jù)庫比擬。Oracle在使用RAC以后，可以多實例并發(fā)讀寫，性能強上加強，單個節(jié)點故障也不影響業(yè)務；而MySQL等由于不支持RAC，多節(jié)點最多只能一寫多讀，性能有瓶頸，且主從切換業(yè)務會斷，為了減少性能影響面和爆炸半徑，只能做分庫分表。假如能讓MySQL這類開源生態(tài)數(shù)據(jù)庫，也擁有多讀多寫的能力，甚至擁有和RAC類似的機制，是否可以不需要再分庫分表了呢？
華為OceanData分布式數(shù)據(jù)庫存儲解決方案正是從這一突破口入手破解難題。華為在共享存儲的基礎(chǔ)上，推出了多寫使能接口，包含兩大引擎—“參天”多寫使能引擎和“DBStor”共享加速引擎—以實現(xiàn)MySQL等開源生態(tài)的多讀多寫。
“參天”多寫使能引擎在ShareStorage的基礎(chǔ)上，進一步實現(xiàn)ShareMemory。它將傳統(tǒng)在持久化層分布式改造的邏輯，改為在緩存層分布式改造；通過緩存層高性能數(shù)據(jù)處理和RDMA的高性能通信能力，彌補持久化層數(shù)據(jù)同步帶來的性能與可靠性問題?！皡⑻臁倍鄬懯鼓芤嬷饕瓿闪怂拇蠊δ埽?/p>
全局資源管理：完成全局節(jié)點資源的注冊、頁面與鎖資源的傳輸?shù)裙ぷ?，將散布在各個節(jié)點緩存中的資源進行統(tǒng)一管理與調(diào)配，是全局并發(fā)讀寫提供執(zhí)行層面保障；
全局鎖管理：完成不同節(jié)點間鎖資源的請求、釋放等管理邏輯，支持spinlock、分布式latch、死鎖檢測等，它是全局并發(fā)讀寫時的事務一致性的主要保障者；
全局頁面管理：完成不同節(jié)點間的頁面資源的加載、請求、釋放等管理邏輯，它為全局資源視圖的一致性提供邏輯層面保障，以支持并發(fā)讀寫和分布式MVCC；
全局集群管理：完成在共享存儲上注冊節(jié)點信息，管理各自節(jié)點的進程狀態(tài)、網(wǎng)絡(luò)狀態(tài)等，并與其它節(jié)點及共享存儲互通狀態(tài)信息的工作；單節(jié)點故障時，會觸發(fā)仲裁、選主等故障恢復流程，與共享存儲共同確保整集群對外正常提供業(yè)務。
在全局一份數(shù)據(jù)共享的基礎(chǔ)上，“參天”多寫使能引擎解決了緩存層上的數(shù)據(jù)統(tǒng)一，使得過去的主從節(jié)點間可以保持實時強一致性，進化為多主架構(gòu)，進而實現(xiàn)并發(fā)讀寫，大大提升了數(shù)據(jù)庫集群的性能、吞吐量和可靠性。
“DBStor”共享加速引擎主要是在ShareStorage的基礎(chǔ)上實現(xiàn)讀寫能力增強，其主要功能包括：
數(shù)據(jù)庫IO協(xié)議棧簡化：減少主機側(cè)數(shù)據(jù)庫IO在數(shù)據(jù)庫、文件系統(tǒng)、塊設(shè)備間頻繁的上下文切換，進而降低IO直通時延；
數(shù)據(jù)庫算子下推：感知數(shù)據(jù)庫語義，并將大表掃描等部分SQL運算下推至存儲完成，并提供索引存儲，大幅優(yōu)化SQL執(zhí)行效率；
高速網(wǎng)絡(luò)：通過華為NoF+高速網(wǎng)絡(luò)處理IO，大幅優(yōu)化傳輸時延，保障網(wǎng)絡(luò)穩(wěn)定無抖動。
“DBStor”共享加速引擎增強了開源數(shù)據(jù)庫的執(zhí)行效率，使其性能大幅增加，大大彌補了其與Oracle之間的處理能力差距。
從過去到現(xiàn)在，金融核心系統(tǒng)的訴求并沒有發(fā)生根本變化，因此解題思路也應該是相似的。華為OceanData分布式數(shù)據(jù)庫存儲解決方案秉承這一理念，以專業(yè)存儲+創(chuàng)新引擎，填補了分布式數(shù)據(jù)庫在Oracle ASM和 RAC上缺乏對標產(chǎn)品的空白，將持久化層分布式邏輯轉(zhuǎn)移到緩存層，破解了“分布式數(shù)據(jù)庫必分庫分表”的業(yè)界難題。從當前現(xiàn)網(wǎng)實踐效果來看，大表性能已經(jīng)基本匹配Oracle；節(jié)點故障業(yè)務不中斷，可靠性也已向Oracle看齊。自此，核心系統(tǒng)分布式數(shù)據(jù)庫改造，終于有了免分庫分表的平滑改造方案。
在需求與政策的大趨勢，金融行業(yè)數(shù)據(jù)庫改造已經(jīng)在所難免。但是，不論是哪一種改造方式，高可用都是金融行業(yè)不變的核心訴求。過去幾十年來，通過傳統(tǒng)數(shù)據(jù)庫與高可靠專業(yè)存儲的良好配合，金融行業(yè)逐步形成了值得信賴的高可用系統(tǒng)建設(shè)體系；如今，在分布式數(shù)據(jù)庫新生態(tài)下反復摸爬與碰壁中，我們可以看到存算分離+專業(yè)存儲體系，依然是數(shù)據(jù)庫高可靠的堅實守護者。
免責聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個人觀點，與極客網(wǎng)無關(guān)。文章僅供讀者參考，并請自行核實相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。
免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。
