一種兩地三中心高可用數(shù)據(jù)庫架構(gòu)設(shè)計(jì)及驗(yàn)證測試

李雁明，劉相坤，段應(yīng)杰，王凱旋

（中國鐵道科學(xué)研究院集團(tuán)有限公司 電子計(jì)算技術(shù)研究所，北京 100081）

隨著云計(jì)算和大數(shù)據(jù)技術(shù)的廣泛應(yīng)用，企業(yè)信息系統(tǒng)集中化部署成為主流趨勢。為保障企業(yè)信息系統(tǒng)安全高效運(yùn)營，滿足不同故障和災(zāi)難場景下對業(yè)務(wù)連續(xù)性的要求，為企業(yè)提供更加安全、穩(wěn)定、高效的信息化平臺(tái)，兩地三中心已成為企業(yè)數(shù)據(jù)中心建設(shè)的共識(shí)。數(shù)據(jù)庫作為信息系統(tǒng)的重要組成部分，需要解決高并發(fā)、海量數(shù)據(jù)訪問、持續(xù)提供服務(wù)、數(shù)據(jù)安全等越來越復(fù)雜的問題[1]，高可用數(shù)據(jù)庫設(shè)計(jì)與實(shí)現(xiàn)是兩地三中心建設(shè)的一項(xiàng)關(guān)鍵任務(wù)[2]。

高可用是信息系統(tǒng)提供連續(xù)性業(yè)務(wù)服務(wù)的一種能力。高可用數(shù)據(jù)庫架構(gòu)設(shè)計(jì)需要綜合考慮如何避免因服務(wù)器、網(wǎng)絡(luò)及軟件等發(fā)生故障而造成業(yè)務(wù)服務(wù)不可用。實(shí)現(xiàn)兩地三中心數(shù)據(jù)庫的高可用有多種途徑，各大廠商紛紛提出各自的數(shù)據(jù)庫高可用解決方案。以TiDB為代表的云原生分布式數(shù)據(jù)庫解決方案，基于分布式一致性算法，保障了集群數(shù)據(jù)的一致性和高可用，但對數(shù)據(jù)中心之間的網(wǎng)絡(luò)延時(shí)有較高要求；以O(shè)racle為代表的集中式數(shù)據(jù)庫解決方案，通過數(shù)據(jù)同步軟件實(shí)現(xiàn)數(shù)據(jù)在多個(gè)數(shù)據(jù)中心之間的實(shí)時(shí)邏輯復(fù)制，但在主數(shù)據(jù)庫發(fā)生故障時(shí)可能存在數(shù)據(jù)丟失情況。

本文借鑒商用數(shù)據(jù)庫高可用解決方案和國內(nèi)外相關(guān)研究，設(shè)計(jì)一種基于開源關(guān)系型數(shù)據(jù)庫管理系統(tǒng)PostgreSQL和開源分布式協(xié)調(diào)服務(wù)ZooKeeper的兩地三中心數(shù)據(jù)庫高可用架構(gòu)，并進(jìn)行了驗(yàn)證測試。

1 兩地三中心數(shù)據(jù)庫架構(gòu)

兩地三中心通常由同城的2個(gè)數(shù)據(jù)中心（即同城一中心和同城二中心）和1個(gè)異地的災(zāi)備中心構(gòu)成。

兩地三中心數(shù)據(jù)庫劃分為3個(gè)層次：為業(yè)務(wù)提供服務(wù)的數(shù)據(jù)訪問接入層、負(fù)責(zé)數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)存儲(chǔ)層、實(shí)現(xiàn)數(shù)據(jù)庫高可用保障的數(shù)據(jù)高可用層，其架構(gòu)如圖1所示。

圖1 兩地三中心數(shù)據(jù)庫架構(gòu)示意

Patroni是PostgreSQL的一個(gè)開源HA工具，用于檢測各個(gè)數(shù)據(jù)庫節(jié)點(diǎn)的狀態(tài)和配置，并負(fù)責(zé)數(shù)據(jù)庫的故障切換。Zookeeper是一個(gè)開源的分布式協(xié)調(diào)服務(wù)，用于管理數(shù)據(jù)庫集群，負(fù)責(zé)存儲(chǔ)數(shù)據(jù)庫節(jié)點(diǎn)的狀態(tài)和配置。

1.1 數(shù)據(jù)訪問接入層

數(shù)據(jù)訪問接入層是面向應(yīng)用的數(shù)據(jù)訪問接口，根據(jù)應(yīng)用需求提供數(shù)據(jù)庫讀/寫服務(wù)。

數(shù)據(jù)訪問接入層主要由負(fù)載均衡器組成，其工作過程如圖2所示。

圖2 數(shù)據(jù)訪問接入層工作過程示意

負(fù)載均衡器通過Patroni的接口獲取數(shù)據(jù)庫的狀態(tài)信息，確定可提供數(shù)據(jù)讀寫服務(wù)的數(shù)據(jù)庫主庫和僅提供數(shù)據(jù)讀服務(wù)的數(shù)據(jù)庫備庫[3]。同城中心的3個(gè)備庫與主庫始終保持同步更新，存儲(chǔ)的數(shù)據(jù)完全一致；而災(zāi)備中心備庫以異步方式更新數(shù)據(jù)，存儲(chǔ)的數(shù)據(jù)相比主庫有一定延遲。正常情況下，負(fù)載均衡器不對災(zāi)備中心的異步備庫進(jìn)行探測，僅從數(shù)據(jù)完全一致的同城中心選擇同步備庫對外提供服務(wù)。

負(fù)載均衡器實(shí)時(shí)對同城中心數(shù)據(jù)庫節(jié)點(diǎn)進(jìn)行探測，可獲4個(gè)數(shù)據(jù)庫節(jié)點(diǎn)的主備狀態(tài)。當(dāng)數(shù)據(jù)庫主備庫發(fā)生切換時(shí)，負(fù)載均衡器快速進(jìn)行流量切換，將業(yè)務(wù)流量切換至正確的數(shù)據(jù)庫，屏蔽數(shù)據(jù)庫切換對上層業(yè)務(wù)的影響，為上層業(yè)務(wù)提供持續(xù)穩(wěn)定的數(shù)據(jù)訪問服務(wù)。

1.2 數(shù)據(jù)存儲(chǔ)層

數(shù)據(jù)存儲(chǔ)層作為數(shù)據(jù)存儲(chǔ)的載體，采用基于PostgreSQL數(shù)據(jù)庫的5節(jié)點(diǎn)數(shù)據(jù)副本模式，即兩個(gè)同城數(shù)據(jù)中心各部署2個(gè)數(shù)據(jù)庫節(jié)點(diǎn)，災(zāi)備中心部署1個(gè)數(shù)據(jù)庫節(jié)點(diǎn)，每個(gè)數(shù)據(jù)庫節(jié)點(diǎn)部署1個(gè)具有全部數(shù)據(jù)的數(shù)據(jù)副本[4]。數(shù)據(jù)庫的主庫由兩個(gè)同城中心通過選舉產(chǎn)生，主庫對外提供數(shù)據(jù)讀寫服務(wù)，備庫僅提供數(shù)據(jù)讀服務(wù)。異地災(zāi)備中心主要用于數(shù)據(jù)異地備份，正常情況下不會(huì)被選舉為主庫。數(shù)據(jù)庫的主庫到同城的3個(gè)備庫采用同步復(fù)制模式，確保一個(gè)同城中心整體發(fā)生故障時(shí)，另一個(gè)同城中心仍具有全部業(yè)務(wù)數(shù)據(jù)，且故障恢復(fù)后不丟失數(shù)據(jù)（即RPO為0）。同時(shí)，當(dāng)備庫發(fā)生故障時(shí)，主備庫間的同步復(fù)制自動(dòng)降級為異步復(fù)制[5]。為了降低數(shù)據(jù)復(fù)制對數(shù)據(jù)庫系統(tǒng)的性能影響，主庫到災(zāi)備中心的備庫采用異步復(fù)制模式。

為了保障業(yè)務(wù)服務(wù)的連續(xù)穩(wěn)定和數(shù)據(jù)同步的安全高效，數(shù)據(jù)存儲(chǔ)層將南北向流量（即數(shù)據(jù)中心外部用戶和內(nèi)部服務(wù)器之間交互的流量）和東西向流量（即數(shù)據(jù)中心內(nèi)部不同服務(wù)器之間交互的流量或不同數(shù)據(jù)中心之間的網(wǎng)絡(luò)流量）進(jìn)行邏輯隔離，南北向的業(yè)務(wù)流量采用業(yè)務(wù)網(wǎng)，東西向的數(shù)據(jù)同步流量采用數(shù)據(jù)同步網(wǎng)。

1.3 數(shù)據(jù)高可用層

數(shù)據(jù)庫高可用層采用Patroni+集群狀態(tài)信息配置存儲(chǔ)服務(wù)（DCS，Distributed Configuration System）的組合模式。Patroni運(yùn)行在每個(gè)數(shù)據(jù)庫節(jié)點(diǎn)上，通過探測數(shù)據(jù)庫節(jié)點(diǎn)及數(shù)據(jù)副本的狀態(tài)來進(jìn)行數(shù)據(jù)庫主備切換。DCS負(fù)責(zé)存儲(chǔ)數(shù)據(jù)庫節(jié)點(diǎn)的狀態(tài)信息，為Patroni的數(shù)據(jù)庫主備切換決策提供依據(jù)，采用基于ZooKeeper的分布式數(shù)據(jù)一致性解決方案。ZooKeeper采用與數(shù)據(jù)存儲(chǔ)層相同的5節(jié)點(diǎn)集群部署模式，分別部署在數(shù)據(jù)副本駐留的數(shù)據(jù)庫節(jié)點(diǎn)上，通過ZooKeeper原子廣播（ZAB，ZooKeeper Atomic Broadcast）協(xié)議來保障服務(wù)高可用。

2 關(guān)鍵技術(shù)

2.1 分布式事務(wù)一致性實(shí)現(xiàn)

在兩地三中心數(shù)據(jù)庫集群上實(shí)現(xiàn)分布式事務(wù)一致性是實(shí)現(xiàn)數(shù)據(jù)庫高可用的基礎(chǔ)。基于ZooKeeper的分布式事務(wù)一致性解決方案采用多副本方式，天然適用于兩地三中心架構(gòu)。ZooKeeper能夠保障事務(wù)請求的順序一致性、原子性、單一視圖性、可靠性及實(shí)時(shí)性。

（1）順序一致性：同一個(gè)客戶端發(fā)起的事務(wù)請求將按照發(fā)送的順序被寫入到ZooKeeper。

（2）原子性：所有事務(wù)請求的處理結(jié)果在整個(gè)集群中所有節(jié)點(diǎn)上的執(zhí)行情況完全一致，即整個(gè)集群所有節(jié)點(diǎn)都成功地執(zhí)行了某一個(gè)事務(wù)，或都不執(zhí)行。

（3）單一視圖性：客戶端連接到任一ZooKeeper服務(wù)器，看到的服務(wù)端數(shù)據(jù)模型都是一致的。

（4）可靠性：一旦服務(wù)端成功地執(zhí)行一個(gè)事務(wù)，并完成對客戶端的響應(yīng)，該事務(wù)所引起的服務(wù)端狀態(tài)變更會(huì)被一直保留下來。

（5）實(shí)時(shí)性：ZooKeeper可確保在一定時(shí)間段內(nèi)，客戶端能夠從服務(wù)端讀取到最新數(shù)據(jù)狀態(tài)[6]。

ZooKeeper使用ZAB協(xié)議。ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)ZooKeeper設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議，基于該協(xié)議ZooKeeper可實(shí)現(xiàn)多個(gè)副本間數(shù)據(jù)一致性。ZooKeeper定義有3種角色的節(jié)點(diǎn)：Leader、Follower和Candidate。在選舉過程中，一個(gè)節(jié)點(diǎn)只要求獲得半數(shù)以上投票，即可當(dāng)選為Leader。Leader節(jié)點(diǎn)負(fù)責(zé)處理客戶端的寫請求并進(jìn)行消息廣播，當(dāng)收到一個(gè)寫請求后，將其廣播給各個(gè)Follower節(jié)點(diǎn)，當(dāng)一半以上Follower節(jié)點(diǎn)應(yīng)答之后，Leader節(jié)點(diǎn)再向各Follower節(jié)點(diǎn)發(fā)送Commit命令，告知其提交相關(guān)事務(wù)[7]。Candidate 僅出現(xiàn)在 Leader選舉過程中，如果 Follower副本在一段時(shí)間內(nèi)沒有收到 Leader 副本的心跳，則判斷 Leader 可能已經(jīng)故障，此時(shí)啟動(dòng)選主過程，副本會(huì)變成 Candidate，直到選主結(jié)束。一旦Leader節(jié)點(diǎn)出現(xiàn)網(wǎng)絡(luò)中斷、崩潰、退出與重啟等異常情況時(shí)，ZAB協(xié)議就會(huì)進(jìn)入恢復(fù)模式，并通過選舉產(chǎn)生新的Leader。采取這種工作機(jī)制，ZooKeeper集群中只要有超一半的節(jié)點(diǎn)存活，集群就可對外提供服務(wù)。

兩地三中心ZooKeeper集群部署如圖3所示。Patroni通過Leader節(jié)點(diǎn)將數(shù)據(jù)直接寫入ZooKeeper集群，也可通過Follower節(jié)點(diǎn)將數(shù)據(jù)傳遞至Leader節(jié)點(diǎn)，再由Leader節(jié)點(diǎn)寫入ZooKeeper集群，通過Leader或Follower讀取ZooKeeper集群中的數(shù)據(jù)。

圖3 ZooKeeper集群部署示意

2.2 數(shù)據(jù)庫高可用保障

數(shù)據(jù)庫高可用是由ZooKeeper和Patroni共同保障的，其工作機(jī)制如圖4所示。ZooKeeper集群負(fù)責(zé)數(shù)據(jù)庫主備節(jié)點(diǎn)狀態(tài)及配置等信息的存儲(chǔ)。Patroni負(fù)責(zé)監(jiān)控和控制本地?cái)?shù)據(jù)庫，周期性地檢測本地?cái)?shù)據(jù)庫節(jié)點(diǎn)狀態(tài)，將數(shù)據(jù)庫節(jié)點(diǎn)狀態(tài)記錄在ZooKeeper集群中，同時(shí)讀取最新的配置信息和集群狀態(tài)，當(dāng)發(fā)現(xiàn)主數(shù)據(jù)庫故障后自動(dòng)進(jìn)行主備切換[8]。

圖4 數(shù)據(jù)庫高可用工作機(jī)制

擁有Leader密鑰的數(shù)據(jù)庫作為主數(shù)據(jù)庫，主數(shù)據(jù)庫的Patroni會(huì)定期向ZooKeeper發(fā)送更新Leader密鑰的請求[9]；當(dāng)主數(shù)據(jù)庫異常導(dǎo)致Patroni無法及時(shí)更新Leader密鑰時(shí)，Leader密鑰就會(huì)過期，從而觸發(fā)新的選舉。數(shù)據(jù)庫主備切換流程為：

（1）主數(shù)據(jù)庫發(fā)生故障，導(dǎo)致Leader密鑰被刪除，處于健康且存活狀態(tài)的所有備數(shù)據(jù)庫會(huì)發(fā)起對Leader密鑰的爭奪。Patroni之間可互相訪問，先與原來的主數(shù)據(jù)庫進(jìn)行通信，當(dāng)發(fā)現(xiàn)訪問超時(shí)，則訪問ZooKeeper查詢數(shù)據(jù)庫集群狀態(tài)，向滿足選舉條件的Patroni發(fā)送創(chuàng)建密鑰的請求，搶到Leader密鑰的數(shù)據(jù)庫成為新的主數(shù)據(jù)庫

3 驗(yàn)證測試

3.1 測試環(huán)境

搭建兩地三中心數(shù)據(jù)庫的測試環(huán)境需要綜合考慮數(shù)據(jù)中心位置、網(wǎng)絡(luò)條件、計(jì)算及數(shù)據(jù)存儲(chǔ)等多方面因素。

（1）數(shù)據(jù)中心位置：本文測試環(huán)境選擇的兩個(gè)同城數(shù)據(jù)中心相距約10 km，兩個(gè)同城數(shù)據(jù)中心到災(zāi)備中心的距離均超過100 km。

（2）網(wǎng)絡(luò)連接：數(shù)據(jù)中心內(nèi)部均采用萬兆網(wǎng)絡(luò)互聯(lián)，兩個(gè)同城數(shù)據(jù)中心之間采用千兆網(wǎng)絡(luò)專線互聯(lián)，保障兩個(gè)同城中心之間具有較大的帶寬和較小的網(wǎng)絡(luò)延遲，以滿足兩個(gè)同城中心的主庫和備庫間的同步數(shù)據(jù)復(fù)制需求。同城數(shù)據(jù)中心與災(zāi)備中心采用千兆網(wǎng)絡(luò)互聯(lián)，在實(shí)際生產(chǎn)中采用此方式可降低經(jīng)濟(jì)成本。同時(shí)，為業(yè)務(wù)網(wǎng)和數(shù)據(jù)同步網(wǎng)配置獨(dú)立且相互隔離的網(wǎng)絡(luò)地址段。數(shù)據(jù)中心內(nèi)部及兩個(gè)同城中心間網(wǎng)絡(luò)延遲在2 ms以內(nèi)，同城中心到災(zāi)備中心網(wǎng)絡(luò)延遲在8 ms以內(nèi)。

（3）計(jì)算及數(shù)據(jù)存儲(chǔ)：采用物理服務(wù)器+本地盤存儲(chǔ)的數(shù)據(jù)庫部署模式[10]，而不是傳統(tǒng)物理服務(wù)器+集中存儲(chǔ)的數(shù)據(jù)庫部署模式。傳統(tǒng)的數(shù)據(jù)庫部署模式采用集中存儲(chǔ)主要是為了提高數(shù)據(jù)讀寫性能，并利用集中存儲(chǔ)硬件的冗余保護(hù)來保障數(shù)據(jù)存儲(chǔ)的安全性。而兩地三中心數(shù)據(jù)庫采用本地SSD盤存儲(chǔ)數(shù)據(jù)，既可滿足數(shù)據(jù)庫的讀寫性能要求，采用多副本存儲(chǔ)還能夠提高數(shù)據(jù)的安全性。數(shù)據(jù)庫采用物理服務(wù)器+本地盤存儲(chǔ)的部署模式，可降低復(fù)雜度，并有助于降低建設(shè)成本及后期運(yùn)維成本[11]。

3.2 故障場景測試用例

為了模擬較為復(fù)雜的生產(chǎn)場景，將主數(shù)據(jù)庫置于一個(gè)同城數(shù)據(jù)中心（同城一中心），ZooKeeper Leader置于另一個(gè)同城數(shù)據(jù)中心（同城二中心）。

深化課程考試體系改革，實(shí)現(xiàn)考核方式向多樣化轉(zhuǎn)變，考核內(nèi)容向注重綜合能力考核轉(zhuǎn)變，成績評定由終結(jié)性評價(jià)向形成性評價(jià)轉(zhuǎn)變。取消原有的“一考定成績”，推行形成性評價(jià)方案(見圖4)，提升評價(jià)的科學(xué)性和客觀性。將學(xué)生的線上學(xué)習(xí)情況、課堂參與情況、解決問題能力、計(jì)算思維能力等納入學(xué)習(xí)評價(jià)體系，更科學(xué)、客觀地衡量學(xué)生學(xué)習(xí)效果。在教學(xué)過程中，通過線上、線下的數(shù)據(jù)分析，把握學(xué)生整個(gè)學(xué)習(xí)過程，并及時(shí)反饋評價(jià)結(jié)果，使學(xué)生通過評價(jià)結(jié)果了解自己的不足，進(jìn)行及時(shí)、有效的改正。

生產(chǎn)環(huán)境中常見的故障有服務(wù)器硬件故障、數(shù)據(jù)庫故障、業(yè)務(wù)網(wǎng)故障、數(shù)據(jù)同步網(wǎng)故障及極端情況下的整個(gè)數(shù)據(jù)中心故障[12]。根據(jù)生產(chǎn)環(huán)境中常見的故障，設(shè)計(jì)了12種故障場景測試用例：

（1）兩個(gè)同城中心間業(yè)務(wù)網(wǎng)異常；

（2）兩個(gè)同城中心間數(shù)據(jù)同步網(wǎng)異常；

（3）同城二中心與同城一中心、災(zāi)備中心間數(shù)據(jù)同步網(wǎng)均異常；

（4）同城一中心與同城二中心、災(zāi)備中心間數(shù)據(jù)同步網(wǎng)均異常；

（5）災(zāi)備中心與同城一中心、同城二中心間數(shù)據(jù)同步網(wǎng)均異常常；

（6）三個(gè)中心數(shù)據(jù)同步網(wǎng)全部異常；

（7）同城一中心整體故障；

（8）同城二中心整體故障；

（9）災(zāi)備中心整體故障；

（10）同城一中心與同城二中心整體故障；

（11）同城一中心與災(zāi)備中心整體故障；

（12）同城二中心與災(zāi)備中心整體故障。

4 測試結(jié)果及結(jié)論

4.1 測試結(jié)果

（1）兩個(gè)同城中心間業(yè)務(wù)網(wǎng)異常

數(shù)據(jù)同步網(wǎng)正常，ZooKeeper集群正常，數(shù)據(jù)庫集群正常。同城二中心數(shù)據(jù)訪問接入層因無法連接到主庫，僅能提供讀服務(wù)，無法提供寫服務(wù)，而同城一中心可正常提供服務(wù)。

（2）兩個(gè)同城中心間數(shù)據(jù)同步網(wǎng)異常

同城一中心ZooKeeper無法連接到ZooKeeper Leader，故脫離集群。ZooKeeper集群仍有3個(gè)節(jié)點(diǎn)正常運(yùn)行，故集群仍可正常提供服務(wù)。同城一中心的主庫可訪問災(zāi)備中心ZooKeeper，故主庫正常。同城二中心所有數(shù)據(jù)節(jié)點(diǎn)無法連接到同城一中心主數(shù)據(jù)節(jié)點(diǎn)，致使同城二中心的同步備庫降級為異步備庫，但并未脫離集群，在降級過程中，數(shù)據(jù)庫短暫停止服務(wù)，業(yè)務(wù)閃斷后恢復(fù)正常。

（3）同城二中心與同城一中心、災(zāi)備中心間數(shù)據(jù)同步網(wǎng)均異常

同城二中心ZooKeeper無法連接到同城一中心和災(zāi)備中心的ZooKeeper，成為少數(shù)派脫離集群，ZooKeeper Leader重新在同城一中心和災(zāi)備中心選舉產(chǎn)生，重新選舉Leader對業(yè)務(wù)無影響。同城二中心所有數(shù)據(jù)庫無法連接到新的ZooKeeper集群，致使同城二中心數(shù)據(jù)庫脫離集群，同時(shí)同城一中心主庫到同城二中心備庫的同步復(fù)制降級為異步復(fù)制，在降級過程中，數(shù)據(jù)庫短暫停止服務(wù)，業(yè)務(wù)閃斷后自動(dòng)恢復(fù)正常。

（4）同城一中心與同城二中心、災(zāi)備中心間數(shù)據(jù)同步網(wǎng)均異常

同城一中心ZooKeeper無法連接到同城二中心和災(zāi)備中心的ZooKeeper，成為少數(shù)派脫離集群，此時(shí)ZooKeeper變?yōu)?節(jié)點(diǎn)集群，Leader無需切換，可正常提供服務(wù)。同城一中心主備庫均無法連接到ZooKeeper集群，致使同城一中心數(shù)據(jù)庫脫離集群，此時(shí)同城二中心的一個(gè)同步備庫升級為主庫，在主備切換的過程中，數(shù)據(jù)庫短暫停止服務(wù)，業(yè)務(wù)閃斷后自動(dòng)恢復(fù)正常。

（5）災(zāi)備中心與同城一中心、二中心間數(shù)據(jù)同步網(wǎng)均異常

災(zāi)備中心ZooKeeper無法連接到同城一中心和二中心的ZooKeeper，成為少數(shù)派脫離集群，此時(shí)ZooKeeper變?yōu)?節(jié)點(diǎn)集群，Leader無需切換，可正常提供服務(wù)。災(zāi)備中心數(shù)據(jù)庫均無法連接到ZooKeeper集群，致使災(zāi)備中心數(shù)據(jù)庫脫離集群。業(yè)務(wù)網(wǎng)正常，同城一、二中心數(shù)據(jù)訪問接入層均可正常提供讀寫服務(wù)，業(yè)務(wù)不會(huì)受到影響。

（6）三個(gè)中心數(shù)據(jù)同步網(wǎng)全部異常

當(dāng)三個(gè)中心數(shù)據(jù)同步網(wǎng)全部異常，ZooKeeper集群無法正常運(yùn)行，此時(shí)數(shù)據(jù)庫集群無法正常運(yùn)行，需要人工干預(yù)，將某一數(shù)據(jù)庫提升為主庫。

（7）同城一中心整體故障

同城一中心ZooKeeper脫離集群，此時(shí)ZooKeeper變?yōu)?節(jié)點(diǎn)集群，Leader無需切換，可正常提供服務(wù)。同城一中心數(shù)據(jù)庫脫離集群，同城二中心一個(gè)同步備庫升級為主庫，當(dāng)發(fā)生主備切換時(shí)，數(shù)據(jù)庫短暫停止服務(wù)，業(yè)務(wù)閃斷后自動(dòng)恢復(fù)正常。

（8）同城二中心整體故障

同城二中心Zookeeper脫離集群，ZooKeeper Leader重新在一中心和災(zāi)備中心選舉產(chǎn)生，Leader的重新選舉對業(yè)務(wù)無影響。同城二中心數(shù)據(jù)庫脫離集群，同城一中心數(shù)據(jù)庫正常，無需切換主備庫，但同城一中心主庫到二中心備庫的同步復(fù)制降級為異步復(fù)制，在降級過程中，數(shù)據(jù)庫短暫停止服務(wù)，業(yè)務(wù)閃斷后自動(dòng)恢復(fù)正常。

（9）災(zāi)備中心整體故障

ZooKeeper 集群仍有 4 個(gè)節(jié)點(diǎn)正常運(yùn)行，故集群仍可正常提供服務(wù)，兩個(gè)同城數(shù)據(jù)庫節(jié)點(diǎn)均正常，業(yè)務(wù)不會(huì)受到影響。

（10）同城一中心與同城二中心整體故障

ZooKeeper 集群無法正常工作，此時(shí)數(shù)據(jù)庫集群無法正常運(yùn)行，需要人工干預(yù)，將災(zāi)備中心數(shù)據(jù)庫節(jié)點(diǎn)提升為主庫。

（11）同城一中心與災(zāi)備中心整體故障

ZooKeeper 集群剩余節(jié)點(diǎn)不超過總節(jié)點(diǎn)數(shù)的50%，此時(shí)數(shù)據(jù)庫集群無法正常運(yùn)行，需要人工干預(yù)，將同城二中心一個(gè)數(shù)據(jù)庫節(jié)點(diǎn)提升為主庫。

（12）同城二中心與災(zāi)備中心整體故障

ZooKeeper 集群剩余節(jié)點(diǎn)不足一半總節(jié)點(diǎn)數(shù)，此時(shí)數(shù)據(jù)庫集群無法正常運(yùn)行，需要人工干預(yù)，將同城一中心一個(gè)數(shù)據(jù)庫節(jié)點(diǎn)提升為主庫。

4.2 測試結(jié)論

通過對本文提出的兩地三中心數(shù)據(jù)庫的測試與分析，可得到以下結(jié)論：

（1）當(dāng)兩個(gè)同城中心間發(fā)生網(wǎng)絡(luò)故障時(shí)，無論是業(yè)務(wù)網(wǎng)或數(shù)據(jù)同步網(wǎng)故障，業(yè)務(wù)幾乎不會(huì)受到影響，系統(tǒng)服務(wù)恢復(fù)時(shí)間（RTO，Recovery Time Objective）約為0，恢復(fù)點(diǎn)目標(biāo)（RPO，Recovery Point Objective）為0。但業(yè)務(wù)網(wǎng)故障時(shí)，僅有一個(gè)同城中心的數(shù)據(jù)訪問接入層可提供服務(wù)。

（2）當(dāng)任一同城數(shù)據(jù)中心數(shù)據(jù)同步網(wǎng)或整體發(fā)生故障時(shí)，業(yè)務(wù)幾乎不會(huì)受到影響，RTO 約為 0，RPO 為 0；當(dāng)災(zāi)備中心數(shù)據(jù)同步網(wǎng)或整體發(fā)生故障時(shí)，業(yè)務(wù)不會(huì)受到影響，RTO為 0，RPO 為 0。

（3）當(dāng)兩個(gè)同城數(shù)據(jù)中心同時(shí)發(fā)生故障或數(shù)據(jù)同步網(wǎng)整體發(fā)生故障時(shí)，由于 ZooKeeper 集群無法正常工作，此時(shí)業(yè)務(wù)會(huì)受到影響，需要人工干預(yù)來恢復(fù)業(yè)務(wù)。

5 結(jié)束語

本文提出一種用于兩地三中心的高可用數(shù)據(jù)庫架構(gòu)，能夠?qū)崿F(xiàn)分布式事務(wù)一致性及故障場景下數(shù)據(jù)庫高可用；并結(jié)合實(shí)際生產(chǎn)過程中可能出現(xiàn)的故障，設(shè)計(jì)了12種故障場景測試用例進(jìn)行驗(yàn)證。結(jié)果表明，按照該架構(gòu)部署兩地三中心數(shù)據(jù)庫，除了兩個(gè)同城數(shù)據(jù)中心同時(shí)發(fā)生故障或者數(shù)據(jù)同步網(wǎng)整體發(fā)生故障的情況外，其它故障發(fā)生時(shí)，數(shù)據(jù)庫均可自動(dòng)進(jìn)行故障隔離，且數(shù)據(jù)零丟失，能夠持續(xù)穩(wěn)定地提供數(shù)據(jù)訪問服務(wù)，不會(huì)影響到業(yè)務(wù)。該數(shù)據(jù)庫架構(gòu)使用了開源的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)PostgreSQL和開源的分布式協(xié)調(diào)服務(wù)ZooKeeper，不但節(jié)約軟件成本，透明可靠、安全性高，還可針對實(shí)際需要進(jìn)行定制。此外，數(shù)據(jù)存儲(chǔ)介質(zhì)使用的是服務(wù)器本地盤而非集中存儲(chǔ)，有利于降低數(shù)據(jù)庫建設(shè)成本和運(yùn)維成本。

本文提出的兩地三中心高可用數(shù)據(jù)庫架構(gòu)中，ZooKeeper集群對網(wǎng)絡(luò)傳輸?shù)姆€(wěn)定性具有一定的要求，數(shù)據(jù)中心間的網(wǎng)絡(luò)抖動(dòng)會(huì)對數(shù)據(jù)庫的高可用產(chǎn)生一定的影響，下一步將繼續(xù)優(yōu)化數(shù)據(jù)庫集群的網(wǎng)絡(luò)設(shè)計(jì)，降低網(wǎng)絡(luò)對數(shù)據(jù)庫高可用性的影響。