趙海
大連農(nóng)商銀行
系統(tǒng)架構(gòu)師
畢業(yè)于大連理工大學(xué)系統(tǒng)工程研究所。2007年加入IBM，任軟件工程師，主要從事日本生命保險(xiǎn)等項(xiàng)目的軟件開發(fā)工作。2009年開始專注于日本松下電器項(xiàng)目的系統(tǒng)運(yùn)維及優(yōu)化工作。2011年加入惠普中國，任高級(jí)系統(tǒng)工程師，專注于客戶案例解決及方案咨詢工作。2013年加入IBM Devops Solution Team，參加云計(jì)算項(xiàng)目建設(shè)及部署，以及后期的咨詢及解決方案提供工作。2014年加入某城商銀行系統(tǒng)規(guī)劃設(shè)計(jì)中心，任系統(tǒng)架構(gòu)師，專注于銀行數(shù)據(jù)中心解決方案規(guī)劃及設(shè)計(jì)工作。
原題：金融行業(yè)雙活數(shù)據(jù)中心建設(shè)思路及方法
【摘要】：隨著雙活數(shù)據(jù)中心建設(shè)成為業(yè)界的熱門話題，也產(chǎn)生了很多盲從現(xiàn)象，很多企業(yè)在雙活數(shù)據(jù)中心的建設(shè)意義以及建設(shè)方法上并沒有清晰的認(rèn)識(shí)。本文就金融行業(yè)雙活建設(shè)項(xiàng)目的意義、目標(biāo)、原則以及建設(shè)思路和具體實(shí)施方案進(jìn)行深入探討，旨在給企業(yè)在建設(shè)雙活數(shù)據(jù)中心項(xiàng)目過程中提供參考。
1. 引言
近年來，隨著互聯(lián)網(wǎng)金融的快速發(fā)展，金融企業(yè)數(shù)據(jù)中心建設(shè)面臨著新的挑戰(zhàn)。那就是對(duì)RTO和RPO的極限追求。從而也就誕生了近年來的熱點(diǎn)話題-雙活數(shù)據(jù)中心建設(shè)。
那么我們?yōu)槭裁匆ㄔO(shè)雙活數(shù)據(jù)中心，它能給我們帶來什么樣的價(jià)值？什么樣的數(shù)據(jù)中心架構(gòu)叫做雙活數(shù)據(jù)中心？如何認(rèn)識(shí)適合自己業(yè)務(wù)模式的雙活模式？建設(shè)階段我們應(yīng)該以什么樣的原則來指導(dǎo)我們的建設(shè)工作？具體的建設(shè)思路以及具體的建設(shè)方案應(yīng)該如何把握？基于這些問題本文進(jìn)行深入研究并展開探討。
2. 雙活數(shù)據(jù)中心建設(shè)意義
從科技工作層面來講，其實(shí)雙活數(shù)據(jù)中心并不是一個(gè)行業(yè)標(biāo)準(zhǔn)或者規(guī)范。行業(yè)的標(biāo)準(zhǔn)是對(duì)RTO和RPO約束，銀監(jiān)局和中國人民銀行對(duì)商業(yè)銀行業(yè)最嚴(yán)格的要求標(biāo)準(zhǔn)是5級(jí)容災(zāi)標(biāo)準(zhǔn)，RPO=15分鐘，RTO=30分鐘。而根據(jù)國際標(biāo)準(zhǔn)share78，六級(jí)容災(zāi)標(biāo)準(zhǔn)是RPO=0，RTO=分鐘級(jí)；七級(jí)容災(zāi)標(biāo)準(zhǔn)是RPO=0，RTO近似為0。雙活的概念也就由此而來，為了達(dá)到國際最高標(biāo)準(zhǔn)。
那么決策是否建設(shè)雙活數(shù)據(jù)中心的依據(jù)也就在于此，首先確定自己企業(yè)合適的目標(biāo)，是不是要必須追求7級(jí)標(biāo)準(zhǔn)？是不是所有業(yè)務(wù)都必須追求這個(gè)目標(biāo)？如果不是那么首先要對(duì)企業(yè)業(yè)務(wù)進(jìn)行細(xì)分并詳細(xì)規(guī)劃每一個(gè)業(yè)務(wù)的容災(zāi)目標(biāo)。浙江決定要不要建設(shè)雙活數(shù)據(jù)中心以及建設(shè)什么樣的雙活數(shù)據(jù)中心。
3. 雙活數(shù)據(jù)中心建設(shè)思路
其實(shí)對(duì)于雙活數(shù)據(jù)中心的定義，從來就沒有一個(gè)標(biāo)準(zhǔn)的定義或者是行業(yè)標(biāo)準(zhǔn)。所有的描述或者所謂的定義暫時(shí)都來自廠商的描述。按照目前技術(shù)發(fā)展的現(xiàn)狀以及行業(yè)建設(shè)狀況調(diào)查分析，本文認(rèn)為雙活的基礎(chǔ)架構(gòu)基本如下圖所描述：
圖1 雙活數(shù)據(jù)中心架構(gòu)基礎(chǔ)輪廓
雙活模式主要分三種，主要區(qū)別在于途中（A、B、C、D、E、F幾個(gè)位置的技術(shù)架構(gòu)差異），接下來詳細(xì)探討。
3.1 數(shù)據(jù)中心級(jí)別的廣義雙活
雙活認(rèn)定的標(biāo)準(zhǔn)以數(shù)據(jù)中心工作模式為基準(zhǔn)，只要兩個(gè)數(shù)據(jù)中心正常時(shí)都工作，災(zāi)難時(shí)能自動(dòng)切換，那么認(rèn)為是雙活數(shù)據(jù)中心模式。如圖1中的位置參數(shù)表示如下：
A = 業(yè)務(wù)定義（讀寫）
B = 業(yè)務(wù)定義（讀寫）
A ≠ B
E = 數(shù)據(jù)庫HA模式
F = 存儲(chǔ)復(fù)制
表3.1.1 數(shù)據(jù)中心級(jí)別雙活架構(gòu)
功能層
模式描述
Client
AB分別是兩個(gè)獨(dú)立業(yè)務(wù)，分別在兩個(gè)數(shù)據(jù)中心完成讀寫。
DNS
DNS分屬兩個(gè)數(shù)據(jù)中心，分別實(shí)現(xiàn)本中心內(nèi)解析。在客戶端設(shè)置其主備模式。
Network
兩數(shù)據(jù)中心分屬不同子網(wǎng)，之間沒有關(guān)系，無需二層打通。
LB
兩個(gè)數(shù)據(jù)中心各自擁有自己的負(fù)載均衡集群，之間沒有任何關(guān)聯(lián)。
APP
每個(gè)數(shù)據(jù)中心擁有全部業(yè)務(wù)的應(yīng)用服務(wù)，共工作模式為AS（不是HA）。
DB
E代表AB業(yè)務(wù)數(shù)據(jù)庫均為主備模式，按照業(yè)務(wù)分庫。
Storage
F代表存儲(chǔ)端的同步復(fù)制。
注1：數(shù)據(jù)復(fù)制可以選擇存儲(chǔ)的同步復(fù)制也可以選擇數(shù)據(jù)庫層面的同步復(fù)制。
表3.1.2 故障切換模型設(shè)計(jì)
故障點(diǎn)
切換策略
Storage
存儲(chǔ)訪問切換到另外的數(shù)據(jù)中心，本地寫變?yōu)檫h(yuǎn)程寫。
DB
應(yīng)用訪問數(shù)據(jù)失敗，負(fù)載均衡聯(lián)動(dòng)DNS健康探測，域名解析到備數(shù)據(jù)中心，客戶端請求引入備中心。
APP
負(fù)載均衡聯(lián)動(dòng)DNS健康探測，域名解析到備數(shù)據(jù)中心，客戶請求引入備中心。
LB
負(fù)載均衡聯(lián)動(dòng)DNS健康探測，域名解析到備數(shù)據(jù)中心，客戶請求引入備中心。
DNS
客戶端啟用備DNS，客戶端請求被引入備數(shù)據(jù)中心。
這種雙活架構(gòu)屬于廣義上的雙活模式，兩個(gè)數(shù)據(jù)心之間除了存儲(chǔ)端的復(fù)制，基本沒有其他聯(lián)系。其實(shí)這種模式的雙活是傳統(tǒng)主備模式容災(zāi)組合架構(gòu)的簡單升級(jí)版。唯一區(qū)別的是傳統(tǒng)容災(zāi)模式下的存儲(chǔ)復(fù)制是基于異步單向模式的，而雙活架構(gòu)下的復(fù)制是基于同步雙向模式的。具體架構(gòu)描述如下圖:
圖3.1 數(shù)據(jù)中心級(jí)雙活架構(gòu)
這種模式下需要的基本關(guān)鍵技術(shù)必備的功能如下所述：
①域名解析設(shè)備需要實(shí)現(xiàn)動(dòng)態(tài)及全局智能解析，當(dāng)本地應(yīng)用無法訪問時(shí)，DNS能跟負(fù)載均衡設(shè)備實(shí)現(xiàn)聯(lián)動(dòng)的健康檢查而偵測到這一故障。并且按照解析的動(dòng)態(tài)規(guī)則實(shí)現(xiàn)解析變化。
②負(fù)載均衡設(shè)備需要實(shí)現(xiàn)本地集群化，保證本地負(fù)載均衡功能的高可用性。
③應(yīng)用最好以虛擬化方式實(shí)現(xiàn)，這樣可以平衡資源的嚴(yán)重浪費(fèi)與高可用的冗余部署之間的矛盾。
④數(shù)據(jù)庫在兩個(gè)數(shù)據(jù)中心也需要雙份部署，同一個(gè)業(yè)務(wù)部署在兩個(gè)數(shù)據(jù)中心的數(shù)據(jù)庫節(jié)點(diǎn)之間沒有任何聯(lián)系，因?yàn)榫W(wǎng)絡(luò)二層沒有打通，無法實(shí)現(xiàn)HA。一般來講需要手動(dòng)切換。當(dāng)然如果不用存儲(chǔ)復(fù)制技術(shù)而是用的ORACLE的ADG技術(shù)或者是DB2的DR技術(shù)，那么可以實(shí)現(xiàn)半自動(dòng)化或全自動(dòng)。
⑤如果采用的存儲(chǔ)層面的復(fù)制技術(shù)，那么必須是同步復(fù)制，必須是雙向復(fù)制。
3.2 業(yè)務(wù)級(jí)別的廣義雙活
雙活認(rèn)定的標(biāo)準(zhǔn)以業(yè)務(wù)是否可以在雙中心內(nèi)同時(shí)進(jìn)行為判定標(biāo)準(zhǔn)。只要同類業(yè)務(wù)能分布在兩個(gè)數(shù)據(jù)中心執(zhí)行，就認(rèn)為是雙活數(shù)據(jù)中心模式。如圖1中的位置參數(shù)表示如下：
A = 業(yè)務(wù)定義
B = 業(yè)務(wù)定義
A = B
D = 跨數(shù)據(jù)中心應(yīng)用集群（區(qū)分優(yōu)先級(jí)）
E = HA
F = HA
表3.2.1 業(yè)務(wù)級(jí)別雙活架構(gòu)
功能層
模式描述
Client
AB是同一個(gè)業(yè)務(wù)。
DNS
DNS分屬兩個(gè)數(shù)據(jù)中心，分別實(shí)現(xiàn)本中心內(nèi)解析。在客戶端設(shè)置其主備模式。
Network
兩數(shù)據(jù)中心二層實(shí)現(xiàn)大聯(lián)通。
LB
負(fù)載均衡實(shí)現(xiàn)兩個(gè)小集群，也可以實(shí)現(xiàn)大集群，但是會(huì)話同步較復(fù)雜。
APP
既然網(wǎng)絡(luò)實(shí)現(xiàn)了二層打通，那應(yīng)用也應(yīng)該實(shí)現(xiàn)大應(yīng)用集群，分布兩端。
DB
數(shù)據(jù)庫實(shí)現(xiàn)跨數(shù)據(jù)中心HA。
Storage
存儲(chǔ)實(shí)現(xiàn)跨數(shù)據(jù)中心HA以及同步復(fù)制。
表3.2.2故障切換模型設(shè)計(jì)
故障點(diǎn)
切換策略
Storage
存儲(chǔ)訪問切換到另外的數(shù)據(jù)中心，本地寫變?yōu)檫h(yuǎn)程寫。
DB
數(shù)據(jù)庫啟用HA切換，應(yīng)用實(shí)現(xiàn)跨數(shù)據(jù)中心訪問DB。
APP
負(fù)載均衡根據(jù)優(yōu)先級(jí)將請求指向另外一端。
LB
負(fù)載均衡聯(lián)動(dòng)DNS健康探測，域名解析到備數(shù)據(jù)中心，客戶請求引入備中心。
DNS
客戶端啟用備DNS，客戶端請求被引入備數(shù)據(jù)中心。
這種雙活架構(gòu)雖然實(shí)現(xiàn)了同類業(yè)務(wù)在前端的負(fù)載分擔(dān)，但是在數(shù)據(jù)庫層面還是屬于單點(diǎn)模式。這種模式比前一種模式最大的技術(shù)變更就是要求網(wǎng)絡(luò)上的二層打通。具體實(shí)現(xiàn)架構(gòu)如下所示：
圖3.2 業(yè)務(wù)級(jí)雙活架構(gòu)
以上架構(gòu)，各個(gè)層面應(yīng)該具備的功能描述如下：
①雙中心DNS設(shè)備為主備模式，域名全局解析，DNS設(shè)備跟負(fù)載均衡設(shè)備能實(shí)現(xiàn)聯(lián)動(dòng)健康檢查。
②網(wǎng)絡(luò)層面必須實(shí)現(xiàn)二層聯(lián)通以保證數(shù)據(jù)庫層面的跨數(shù)據(jù)中心HA以及應(yīng)用服務(wù)器的應(yīng)用大集群。
③負(fù)載均衡層，如果是兩個(gè)小集群方式，那么不能將其放入大二層，只保證其三層可達(dá)就可以了，否則客戶端無法實(shí)現(xiàn)請求路由切換；如果是大集群方式，那么可以放入大二層網(wǎng)絡(luò)，但是要設(shè)計(jì)好會(huì)話同步問題；
④數(shù)據(jù)庫在兩個(gè)數(shù)據(jù)中心實(shí)現(xiàn)跨數(shù)據(jù)中心HA部署，主要是以操作系統(tǒng)的HA，將數(shù)據(jù)庫服務(wù)作為HA的服務(wù)方式來實(shí)現(xiàn)，例如IBM的HyperSwap。
⑤存儲(chǔ)層面需要實(shí)現(xiàn)HA以及同步復(fù)制，例如IBM的SVC集群解決方案，NETAPP的MCC解決方案。
3.3 應(yīng)用級(jí)別的雙活
應(yīng)用級(jí)別的雙活，本文將其定義為同一個(gè)應(yīng)用系統(tǒng)的IO可以從兩個(gè)數(shù)據(jù)中心分別訪問數(shù)據(jù)庫節(jié)點(diǎn)，當(dāng)然這個(gè)訪問又會(huì)分為讀操作和寫操作。那么相應(yīng)的這種模式下的雙活又分為兩種：一種是讀寫分離的模式；另外一種是混合模式，也就是業(yè)內(nèi)相對(duì)較為徹底的雙活架構(gòu)。如圖3.1.1中的位置參數(shù)表示如下：
A = 業(yè)務(wù)定義
B = 業(yè)務(wù)定義
A = B
E = 數(shù)據(jù)庫AA集群模式
F = HA/AA
表3.3.1 業(yè)務(wù)級(jí)別雙活架構(gòu)
功能層
模式描述
Client
AB是同一個(gè)業(yè)務(wù)。
DNS
DNS分屬兩個(gè)數(shù)據(jù)中心，分別實(shí)現(xiàn)本中心內(nèi)解析。在客戶端設(shè)置其主備模式。
Network
兩數(shù)據(jù)中心二層實(shí)現(xiàn)大聯(lián)通。
LB
負(fù)載均衡實(shí)現(xiàn)兩個(gè)小集群，也可以實(shí)現(xiàn)大集群，但是會(huì)話同步較復(fù)雜。
APP
既然網(wǎng)絡(luò)實(shí)現(xiàn)了二層打通，應(yīng)用實(shí)現(xiàn)大應(yīng)用集群，分布兩端。
DB
數(shù)據(jù)庫實(shí)現(xiàn)跨數(shù)據(jù)中心AA集群，例如ORACLE ExtendRAC。
Storage
存儲(chǔ)實(shí)現(xiàn)跨數(shù)據(jù)中心HA/AA模式。
表3.3.2 故障切換模型設(shè)計(jì)
故障點(diǎn)
切換策略
Storage
存儲(chǔ)鏈路切換或者虛擬化網(wǎng)關(guān)內(nèi)部隱式切換。
DB
應(yīng)用訪問切換到其他節(jié)點(diǎn)。
APP
負(fù)載均衡設(shè)備按照優(yōu)先級(jí)策略將請求引入另一端。
LB
負(fù)載均衡聯(lián)動(dòng)DNS健康探測，域名解析到備數(shù)據(jù)中心，客戶請求引入備中心。
DNS
客戶端啟用備DNS，客戶端請求被引入備數(shù)據(jù)中心。
這種雙活架構(gòu)雖然實(shí)現(xiàn)了應(yīng)用IO級(jí)別的雙活，是目前金融行業(yè)較為徹底的雙活。具體架構(gòu)如下：
圖3.3 應(yīng)用級(jí)雙活架構(gòu)
各個(gè)層面應(yīng)該具備的功能與3.2區(qū)別最大的幾個(gè)關(guān)鍵點(diǎn)描述如下：①數(shù)據(jù)庫在兩個(gè)數(shù)據(jù)中心實(shí)現(xiàn)跨數(shù)據(jù)中心集群模式。②存儲(chǔ)層可以選擇HA方式也可以選擇EMC提供的VPLEX虛擬化集群方式。
本節(jié)初始曾提到基于該架構(gòu)，可以通過控制應(yīng)用鏈接數(shù)據(jù)庫的具體模式，將讀寫分離，那么為什么要這么做呢？在這里本文需要將本架構(gòu)下的關(guān)鍵風(fēng)險(xiǎn)點(diǎn)提出：
1）雙數(shù)據(jù)中心的連接依賴的是運(yùn)營商的裸光纖，其本身的延時(shí)和鏈路的穩(wěn)定性是數(shù)據(jù)庫AA集群最大的威脅。拿ORACLE來舉例說明，ORACLE RAC 的各個(gè)節(jié)點(diǎn)共享同一份數(shù)據(jù)，兩節(jié)點(diǎn)同時(shí)讀寫的場合下，為了保證數(shù)據(jù)的一致性它們會(huì)同步緩存，鎖信息以及全局配置信息等，由于關(guān)系數(shù)據(jù)庫的特點(diǎn)，不可避免會(huì)產(chǎn)生熱點(diǎn)數(shù)據(jù)問題，那么數(shù)據(jù)庫節(jié)點(diǎn)之間就可能會(huì)發(fā)生IO頻繁等待的問題。這種問題一旦成為常態(tài)化，那么整個(gè)集群性能會(huì)呈倍數(shù)級(jí)性能衰減，嚴(yán)重的時(shí)候可能將整個(gè)數(shù)據(jù)庫集群掛起。另外由于光線的抖動(dòng)不僅僅會(huì)引起性能的蝴蝶效應(yīng)，而且可能會(huì)因仲裁、光線鏈路切換的混合參與導(dǎo)致腦裂等嚴(yán)重異常問題，不穩(wěn)定時(shí)刻內(nèi)涉及到的設(shè)備越多，系統(tǒng)越復(fù)雜，產(chǎn)生異常問題的可能性就越大。
2）仲裁一致性問題，以上雙活架構(gòu)會(huì)涉及到存儲(chǔ)集群、數(shù)據(jù)庫集群兩個(gè)仲裁機(jī)制的協(xié)同問題。如果發(fā)生數(shù)據(jù)中心之間的鏈路斷裂問題，有可能僅僅影響網(wǎng)絡(luò)、有可能僅僅影響SAN、也有可能是裸光纖的瞬時(shí)全部斷裂。這個(gè)時(shí)候如果存儲(chǔ)和數(shù)據(jù)庫的仲裁結(jié)果恰恰相反，那么就是兩個(gè)數(shù)據(jù)中心同時(shí)的災(zāi)難了。數(shù)據(jù)庫的仲裁盤在存儲(chǔ)虛擬化之后的邏輯磁盤上，存儲(chǔ)的仲裁中心在兩個(gè)數(shù)據(jù)中心之外的第三點(diǎn)上。由于網(wǎng)絡(luò)和存儲(chǔ)同時(shí)斷裂，數(shù)據(jù)庫假設(shè)先感知到網(wǎng)絡(luò)斷裂，那就要發(fā)生仲裁，雙中心資源對(duì)等情況下，ORACLE選擇實(shí)例號(hào)小的子集群存活。由于存儲(chǔ)對(duì)SAN中斷的感知落后了，那么它根據(jù)第三方仲裁點(diǎn)來仲裁存儲(chǔ)的存活，如果沒有其他策略來保障，它的仲裁結(jié)果完全有可能與數(shù)據(jù)庫已經(jīng)做出的判斷相反。
3）雙重?zé)狳c(diǎn)問題，如果我們將ORACLE RAC假設(shè)在存儲(chǔ)的AA集群之上。本質(zhì)上EMC VPLEX也是一個(gè)ORACLE RAC，因?yàn)樗獙?shí)現(xiàn)同一時(shí)刻內(nèi)存儲(chǔ)的雙向復(fù)制，也就是說兩個(gè)虛擬化網(wǎng)關(guān)就相當(dāng)于RAC節(jié)點(diǎn)，同樣會(huì)有熱點(diǎn)問題，同樣會(huì)同步一個(gè)全局配置以及緩存，只不過它是基于塊兒的熱點(diǎn)。這兩個(gè)層面上雙重競爭，系統(tǒng)變得異常復(fù)雜，非常容易出問題。
4）存儲(chǔ)復(fù)制無法解決邏輯校驗(yàn)。存儲(chǔ)復(fù)制技術(shù)是以塊兒為單位的復(fù)制技術(shù)。雖然能很好完成數(shù)據(jù)復(fù)制功能，但是如果源數(shù)據(jù)塊兒已經(jīng)發(fā)生了邏輯錯(cuò)誤，存儲(chǔ)是無法識(shí)別到這一錯(cuò)誤的。直接結(jié)果就是復(fù)制到對(duì)端的數(shù)據(jù)無法被應(yīng)用識(shí)別，最終應(yīng)用還是中斷。典型的案例比如說ASM的磁盤頭部邏輯性損壞。
如果解決以上面臨的風(fēng)險(xiǎn)點(diǎn)呢？對(duì)于熱點(diǎn)問題，這是關(guān)系型數(shù)據(jù)庫的固有特點(diǎn)，要保證數(shù)據(jù)的強(qiáng)一致性，那熱點(diǎn)就不可消除。只能通過以下方式來改善：
1）業(yè)務(wù)高度去耦，能做到數(shù)據(jù)庫分區(qū)的盡量分區(qū)，比如說銀行的交易系統(tǒng)，我們是否可以根據(jù)終端的地域?qū)傩詫⒈矸謪^(qū)，當(dāng)然應(yīng)用層也需要做相應(yīng)的區(qū)分鏈接處理。
2）業(yè)務(wù)讀寫分離，減少鎖的等待。這就需要應(yīng)用本身能做到高度隔離，而且讀寫需要分別使用不同的數(shù)據(jù)庫鏈接方式。
對(duì)于第二個(gè)風(fēng)險(xiǎn)點(diǎn)，仲裁一致性問題，有以下幾種解決思路：
1）通過存儲(chǔ)層和數(shù)據(jù)庫層的仲裁觸發(fā)時(shí)間以及判定時(shí)間的控制參數(shù)，保證數(shù)據(jù)庫仲裁發(fā)生在存儲(chǔ)之后。
2）數(shù)據(jù)庫在資源對(duì)等情況下，按照實(shí)例號(hào)大小策略來判斷仲裁結(jié)果，存儲(chǔ)在資源對(duì)等情況下同樣可以設(shè)置其策略，我們需要保證這兩個(gè)策略結(jié)果的一致性。
3）ORACLE的仲裁策略，首先保證集群中獲取投票資源最多的子集存活，資源對(duì)等情況下才會(huì)選擇實(shí)例號(hào)小的存活。如果設(shè)置兩邊的節(jié)點(diǎn)數(shù)不一致，那么這種情況下，數(shù)據(jù)庫的仲裁結(jié)果就是可知的，根據(jù)這個(gè)可知結(jié)果將存儲(chǔ)側(cè)的仲裁方式設(shè)置為固定方式。
4）部分或者全部利用數(shù)據(jù)庫復(fù)制技術(shù)代替存儲(chǔ)復(fù)制技術(shù)。數(shù)據(jù)庫復(fù)制技術(shù)可以是以日志的復(fù)制來實(shí)現(xiàn)的，對(duì)于數(shù)據(jù)庫來講，只要redo日志存在，那么數(shù)據(jù)一定能恢復(fù)。而且類似ASM磁盤頭部邏輯錯(cuò)誤，一定不會(huì)復(fù)制到對(duì)端。也就保證了對(duì)端數(shù)據(jù)庫不會(huì)因?yàn)檫壿嬪e(cuò)誤而無法啟動(dòng)數(shù)據(jù)庫應(yīng)用。
3.4 三種架構(gòu)的對(duì)比分析
本節(jié)將重點(diǎn)通過架構(gòu)對(duì)比、功能對(duì)比、實(shí)現(xiàn)復(fù)雜度對(duì)比等方面來分析這三種架構(gòu)的優(yōu)劣。
表3.4 雙活架構(gòu)對(duì)比
中心級(jí)
業(yè)務(wù)級(jí)
應(yīng)用級(jí)
RTO
小時(shí)級(jí)
分鐘級(jí)
近似0
RPO（理論）
0
0
0
網(wǎng)絡(luò)
-
大二層
大二層
應(yīng)用
-
大集群
大集群
數(shù)據(jù)庫
冷備
HA
AA
存儲(chǔ)
HA
HA
AA/HA
切換
手動(dòng)
自動(dòng)
自動(dòng)
復(fù)雜度
簡單
一般
復(fù)雜
業(yè)務(wù)請求
單中心
雙中心
雙中心
應(yīng)用訪問
單中心
雙中心
雙中心
數(shù)據(jù)讀出
單中心
單中心
雙中心
數(shù)據(jù)寫入
單中心
單中心
雙中心
RTO風(fēng)險(xiǎn)
高
中
低
RPO風(fēng)險(xiǎn)
低
低
中
仲裁風(fēng)險(xiǎn)
-
低
高
帶寬要求
低
中
高
3.5 本文認(rèn)為的合理雙活架構(gòu)
由以上分析我們可以看出，對(duì)于容災(zāi)指標(biāo)高的架構(gòu)所面臨的風(fēng)險(xiǎn)項(xiàng)也是最多的，在風(fēng)險(xiǎn)和容災(zāi)目標(biāo)面前我們需要一個(gè)平衡。具體架構(gòu)實(shí)現(xiàn)如下圖：
圖3.5 折中雙活架構(gòu)
根據(jù)以上架構(gòu)，可以看到：
1）增加數(shù)據(jù)庫復(fù)制技術(shù)保護(hù)，以防塊復(fù)制的邏輯校驗(yàn)缺失造成數(shù)據(jù)丟失風(fēng)險(xiǎn)。
2）存儲(chǔ)層面以HA方式代替AA模式集群。
3）根據(jù)應(yīng)用隔離的程度控制應(yīng)用鏈接數(shù)據(jù)庫節(jié)點(diǎn)的模式，實(shí)現(xiàn)業(yè)務(wù)讀寫分離。
4.總結(jié)及展望
本文認(rèn)為目前所研究分析的雙活架構(gòu)是屬于折中解決方案，并不是一個(gè)科學(xué)合理的解決方案。分布式架構(gòu)才是解決問題的科學(xué)合理架構(gòu)，但是關(guān)系型數(shù)據(jù)庫對(duì)數(shù)據(jù)的強(qiáng)一致性要求無法從數(shù)據(jù)庫單方面來實(shí)現(xiàn)整體架構(gòu)的分布式部署，但是可以實(shí)現(xiàn)分布式部署的數(shù)據(jù)庫（NOSQL）又無法滿足數(shù)據(jù)的強(qiáng)一致性。通過從應(yīng)用、網(wǎng)絡(luò)、數(shù)據(jù)庫、存存等一系列層面實(shí)現(xiàn)系統(tǒng)性整體的分布式架構(gòu)實(shí)在是一件很困難的事情，需要耗費(fèi)大量的人力物力，并不是每一個(gè)金融企業(yè)都能實(shí)現(xiàn)的事情。本文相信當(dāng)人類認(rèn)識(shí)OLTP模式的觀念發(fā)生變革之后，或許有可能很容易地實(shí)現(xiàn)真正的OLTP分布式架構(gòu)。比如區(qū)塊鏈技術(shù)就從根本上顛覆了賬務(wù)平衡的傳統(tǒng)理論觀點(diǎn)。相信會(huì)有類似的新技術(shù)能夠?qū)崿F(xiàn)完美替代。
點(diǎn)擊
