呂韜 田峰 李征宇 張雪

摘? ?要： 分布式關系型數(shù)據(jù)庫具有廣泛應用和技術探究空間，其質(zhì)量指標關乎信息系統(tǒng)穩(wěn)定運行、業(yè)務連續(xù)性等，其中恢復點目標（RPO）是衡量分布式關系型數(shù)據(jù)庫可靠性的核心指標。討論了分布式關系型數(shù)據(jù)庫RPO的內(nèi)涵和外延，印證了分布式關系型數(shù)據(jù)庫理論上可以保證RPO等于0，擁有對數(shù)據(jù)完整性的完全保障能力。針對RPO指標，提出了一種基于場景的測試方法，以寫入數(shù)據(jù)庫的事務數(shù)量與數(shù)據(jù)庫中記錄數(shù)的差值表征數(shù)據(jù)丟失情況。搭建測試環(huán)境，應用LoadRunner測試工具，以平均響應時間、每秒虛擬用戶HTTP請求數(shù)、Tomcat日志等為依據(jù)，測試得到三款分布式關系型數(shù)據(jù)庫產(chǎn)品的RPO指標，實現(xiàn)了對數(shù)據(jù)庫容災能力的評價。

關鍵詞： 分布式關系型數(shù)據(jù)庫;恢復點目標（RPO）;容災能力; LoadRunner;平均響應時間

引言

信息技術、互聯(lián)網(wǎng)技術的深度應用，以及大數(shù)據(jù)挖掘、智能化發(fā)展，促使信息系統(tǒng)不斷擴展規(guī)模，要求信息系統(tǒng)向高性能、易擴展、泛兼容的技術方向演進，其中安全存儲、可靠傳輸、精準應用信息資源是信息系統(tǒng)中的關鍵技術。信息資源的可用性、完整性、有效性是關鍵指標，存儲信息資源的數(shù)據(jù)庫作為支撐信息系統(tǒng)穩(wěn)定運行的基礎軟件，技術體系不斷革新，從集中式向分布式架構演進成為重要技術趨勢[1]。

相對傳統(tǒng)的大型集中式關系型數(shù)據(jù)庫，分布式關系型數(shù)據(jù)庫具有成本低、部署靈活、性能高等優(yōu)勢，可以支撐當前互聯(lián)網(wǎng)應用的大規(guī)模、高并發(fā)、多模式業(yè)務類型，也是當前金融領域信息化升級的重要技術方向[2]。2019年10月，螞蟻金服科技研發(fā)的分布式關系型數(shù)據(jù)庫OceanBase成功登頂TPC-C[3]，反映出我國分布式關系型數(shù)據(jù)庫技術逐步成熟，正在被越來越多的行業(yè)所認可并投入實際應用。

科學、客觀、準確地評價一款分布式關系型數(shù)據(jù)庫產(chǎn)品的質(zhì)量是保證信息資源安全、信息系統(tǒng)可靠的 重要課題。除了功能、性能、安全等質(zhì)量屬性外，一些關鍵行業(yè)的信息系統(tǒng)對數(shù)據(jù)庫的可靠性提出了更高的要求：一方面需要數(shù)據(jù)庫廠商通過日志、副本等技術保障可靠性;另一方面也需要客觀評價可靠性的指標和方法?？紤]到分布式關系型數(shù)據(jù)庫一般具有多副本實時備份的技術特點，恢復點目標（Recovery Point Object，RPO）指標成為衡量其可靠性的核心指標[4]。為此，本文結合分布式關系型數(shù)據(jù)庫的技術特點，提出一種基于場景的分布式關系型數(shù)據(jù)庫恢復點目標的測試方法，以實現(xiàn)對分布式關系型數(shù)據(jù)庫可靠性的測評，并在工程實踐中進行驗證，以反映測試方法的正確性和合理性。

1? 分布式關系型數(shù)據(jù)庫與RPO

分布式關系型數(shù)據(jù)庫作為基礎軟件產(chǎn)品，符合軟件產(chǎn)品的所有質(zhì)量特性。一般軟件產(chǎn)品的質(zhì)量特性包括功能、效率、可靠性、安全性、兼容性、可擴展性等，對于特定的軟件產(chǎn)品，需要結合軟件本身的技術特點，在質(zhì)量特性的框架下進行設計，并細化測試指標，明確測試方法，最終達到評價軟件產(chǎn)品的目的。

1.1? 分布式關系型數(shù)據(jù)庫

一般來說，分布式關系型數(shù)據(jù)庫是用計算機網(wǎng)絡將物理上分散的多個數(shù)據(jù)庫單元連接起來，并采用關系模型加以組織的一個邏輯上統(tǒng)一的數(shù)據(jù)庫[5]。分布式關系型數(shù)據(jù)庫具有物理分布性、邏輯整體性和站點自治性的特點，從其所具有的能力上可以歸納為：

（1）管理、調(diào)度、處理分布式事務;

（2）支持跨數(shù)據(jù)中心的橫向擴展;

（3）具備高可用能力，具備進行實時備份及恢復的容災能力。

從以上的技術特點可以看出，相對于傳統(tǒng)的集中式關系型數(shù)據(jù)庫，分布式關系型數(shù)據(jù)庫的擴展性和容災能力更強，尤其是當一個或多個節(jié)點遇到故障時，分布式關系型數(shù)據(jù)庫能夠持續(xù)運行并迅速拉起備份節(jié)點，承擔故障節(jié)點的工作[6-7]。

1.2? RPO的內(nèi)涵與外延

RPO的作用是災難發(fā)生后，令容災系統(tǒng)把數(shù)據(jù)恢復到災難發(fā)生前時間點的數(shù)據(jù)，故RPO是衡量災難發(fā)生后會丟失多少生產(chǎn)數(shù)據(jù)的指標，具體表示為從災難發(fā)生到最近一次備份的時間度量。本質(zhì)上，RPO指標主要反映了業(yè)務連續(xù)性管理體系下備用數(shù)據(jù)的有效性，系統(tǒng)RPO越小，表示系統(tǒng)對數(shù)據(jù)完整性的保障能力越強，即故障發(fā)生后可能損失的數(shù)據(jù)就越少。

對于傳統(tǒng)的集中式關系型數(shù)據(jù)庫，由于其數(shù)據(jù)存儲機制為主節(jié)點執(zhí)行寫操作，因此一旦其主節(jié)點遇到故障，數(shù)據(jù)就存在丟失的可能性，且故障恢復時間受到軟硬件、機房基礎設施等多種因素影響，RPO指標較高;即使是引入了熱備份等相關機制的現(xiàn)代的集中式數(shù)據(jù)庫，雖然當主節(jié)點遇到故障時系統(tǒng)能夠快速切換到備份節(jié)點，但其“多讀單寫”的機制仍然無法完全保證其RPO等于0。

對于分布式關系型數(shù)據(jù)庫，為了實現(xiàn)真正的多讀多寫，一般通過中間件或同步協(xié)議保障多個數(shù)據(jù)庫副本之間的數(shù)據(jù)一致性，從數(shù)據(jù)處理機制上實現(xiàn)實時的備份，理論上可以保證RPO等于0。因此對分布式關系型數(shù)據(jù)庫進行RPO測試驗證成為一個新的課題[8-9]。

2? 分布式關系型數(shù)據(jù)庫RPO測試方法設計

結合分布式關系型數(shù)據(jù)庫的技術特點，我們創(chuàng)新地將RPO引入數(shù)據(jù)庫質(zhì)量測試，作為可靠性的測試指標之一，用以驗證分布式關系型數(shù)據(jù)庫的容災能力，對當前分布式關系型數(shù)據(jù)庫應用較多且對業(yè)務連續(xù)性要求較高的電子商務、金融行業(yè)具有重要的參考價值。

對分布式關系型數(shù)據(jù)庫進行RPO測試的主要思路是，在被測數(shù)據(jù)庫執(zhí)行一個連續(xù)事務的過程中，人為制造故障場景，如切斷一個或多個節(jié)點，在故障發(fā)生后，觀察被測數(shù)據(jù)庫是否仍可穩(wěn)定連續(xù)運行，并且在故障發(fā)生的時間段統(tǒng)計所有數(shù)據(jù)是否丟失，計算其RPO。

RPO的測試方法設計如下：

（1）通過客戶端持續(xù)對分布式關系型數(shù)據(jù)庫的一個節(jié)點進行寫操作，在客戶端記錄寫操作成功的次數(shù)，在數(shù)據(jù)庫端記錄每條插入數(shù)據(jù)的時間;

（2）斷開該節(jié)點的網(wǎng)絡，判斷數(shù)據(jù)庫是否穩(wěn)定運行不退出，以及寫操作能否迅速恢復，記錄斷網(wǎng)時間;

（3）待被測數(shù)據(jù)庫穩(wěn)定后，終止測試;

（4）對比寫操作成功次數(shù)與數(shù)據(jù)庫中的記錄數(shù)是否一致，并計算分析斷網(wǎng)之后插入數(shù)據(jù)的時間間隔。

RPO的判定方法如下：

按照GB/T 20889-2007《信息安全技術 信息系統(tǒng)災難恢復規(guī)范》[10]的要求，RPO約為0或者等于0的情況對應的容災等級為第5級、第6級，換算成可靠性的要求，其系統(tǒng)可用性應為99.99%及以上。因此，在測試完成后，應計算丟失記錄數(shù)與總成功插入記錄的比值，若丟失記錄數(shù)的比值小于0.01%，則認為被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO約為0;若比值小于0.001%，則認為被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO等于0。

3? RPO測試過程

分布式關系型數(shù)據(jù)庫的測試過程主要分為三個部分：一是按照被測數(shù)據(jù)庫的技術特點及實際業(yè)務場景需求搭建測試環(huán)境，準備能夠準確量化RPO指標的測試工具;二是根據(jù)RPO測試指標制定測試步驟，明確測試的次序和每步需要記錄的測試數(shù)據(jù);三是對所有的測試結果進行分析，評價被測產(chǎn)品的RPO能力。

3.1? 測試環(huán)境搭建

按照分布式關系型數(shù)據(jù)庫的技術特點，在硬件設備上一般需要準備6臺服務器及配套的交換機，用于部署被測數(shù)據(jù)庫，此外服務器還可復用部署測試相關的系統(tǒng)，需要一臺桌面終端。

測試工具建議選擇LoadRunner，此工具的作用一是模擬實際用戶，對Web應用系統(tǒng)進行持續(xù)訪問，從而對被測數(shù)據(jù)庫進行持續(xù)的寫操作;二是監(jiān)測在故障發(fā)生時數(shù)據(jù)庫的性能表現(xiàn)。

此外，為了模擬實際業(yè)務場景，還需開發(fā)一個小型的Web應用系統(tǒng)，此系統(tǒng)的作用一是對被測產(chǎn)品進行連續(xù)寫操作，二是在故障發(fā)生時，通過監(jiān)測此系統(tǒng)的運行狀態(tài)來判斷數(shù)據(jù)庫是否連續(xù)運行。

綜上，測試環(huán)境的軟硬件構成如圖1所示。

測試環(huán)境在搭建時，需要被測數(shù)據(jù)庫的廠商按照數(shù)據(jù)庫的特點進行節(jié)點分配，測試環(huán)境的標準拓撲圖如圖1所示。

3.2? 測試實施步驟

測試流程圖如圖2所示，以下對各個步驟進行介紹。

3.2.1? 測試環(huán)境部署與確認

按照圖1所示的測試環(huán)境拓撲圖搭建分布式關系型數(shù)據(jù)庫測試環(huán)境。搭建完成后，試運行被測數(shù)據(jù)庫，確保數(shù)據(jù)庫系統(tǒng)正常運行。

3.2.2? Web應用部署與確認

選擇一臺數(shù)據(jù)庫服務器部署Web應用系統(tǒng)，部署完成后，確保Web應用系統(tǒng)與數(shù)據(jù)庫連接成功且可對被測數(shù)據(jù)庫進行操作。在被測數(shù)據(jù)庫中，構造數(shù)據(jù)庫表單，要求表單最后一列為時間戳;在Web應用系統(tǒng)中，構建一條SQL語句，對被測數(shù)據(jù)庫進行操作，SQL語句為插入操作，且插入的最后一列為插入數(shù)據(jù)時的時間戳。

3.2.3? 測試工具部署及調(diào)試

在桌面終端部署LoadRunner工具，錄制腳本并調(diào)試，直至成功，確?？梢詫eb應用程序進行壓力測試。

3.2.4? 使用測試工具執(zhí)行壓力測試

通過LoadRunner實現(xiàn)100用戶并發(fā)對創(chuàng)建表單的插入操作（壓力測試執(zhí)行前，務必清除已創(chuàng)建表單中所有數(shù)據(jù)）。參數(shù)設置：thinktime=0;運行時長20 min。執(zhí)行壓力測試，并觀察測試工具Transactions（事務總數(shù)）的Total Passed與Total Failed數(shù)值，若Total Failed出現(xiàn)非0數(shù)據(jù)，則停止壓力測試，并返回至章節(jié)3.2.3，重新對測試工具和Web應用進行部署調(diào)試。

3.2.5? 故障模擬

在測試中平穩(wěn)運行5 min后，手動關閉其中一個計算節(jié)點，模擬該節(jié)點運行發(fā)生故障并退出。執(zhí)行斷網(wǎng)操作后，觀察LoadRunner工具響應時間曲線圖，若Hits per Second數(shù)值降至零，且Total Failed出現(xiàn)非0數(shù)據(jù)、Total Passed數(shù)值停止增長、數(shù)據(jù)庫單一節(jié)點故障引起數(shù)據(jù)庫不可用，則說明該分布式關系型數(shù)據(jù)庫的配置不正確，返回章節(jié)3.2.1對分布式測試環(huán)境重新進行部署與確認。執(zhí)行斷網(wǎng)操作后，待Hits per Second數(shù)值降低并穩(wěn)定后，繼續(xù)保持壓力，20 min壓力測試完成后，記錄測試數(shù)據(jù)。

3.2.6? 記錄分析測試結果

測試完成后，記錄LoadRunner的事務通過數(shù)、未通過數(shù)，Web應用系統(tǒng)的成功連接數(shù)，被測數(shù)據(jù)庫表單中的記錄數(shù)等數(shù)據(jù)。

3.3? 測試結果記錄及處理

首先，測試工具LoadRunner通過的Transactions數(shù)量，該測試結果是對事務進行綜合分析的結果，是性能分析的第一步。其一，通過分析測試時間內(nèi)用戶事務的成功與失敗情況，可以直接判斷出系統(tǒng)是否運行正常，若Transactions的Total Failed數(shù)值持續(xù)增長，則判定客戶端通過Web應用訪問數(shù)據(jù)庫失敗，需中斷測試工作;其二，運行正常的情況下，在測試完成后，通過記錄Transactions的Total Passed數(shù)值，記錄測試工具端客戶端成功發(fā)送數(shù)據(jù)庫的事務數(shù)量X1。

其次，記錄Web應用通過的Transactions數(shù)量X2，該數(shù)值可直觀反映出客戶端成功執(zhí)行SQL語句并成功寫入數(shù)據(jù)庫的事務數(shù)量。

再次，登錄數(shù)據(jù)庫端通過SQL語句查詢數(shù)據(jù)庫表所有記錄數(shù)X3，X3數(shù)值為本次測試過程中實際成功寫入數(shù)據(jù)庫的事務數(shù)量。

最后，根據(jù)以上測試數(shù)，對測試結果進行計算分析：

（1）若X1=X3，則客戶端成功發(fā)送數(shù)據(jù)庫的事務數(shù)量等于成功寫入數(shù)據(jù)庫端的事務數(shù)量，整個測試過程中未發(fā)生數(shù)據(jù)丟失，測試過程中RPO等于0。

（2）若X1>X3，則客戶端成功發(fā)送數(shù)據(jù)庫的事務數(shù)量大于成功寫入數(shù)據(jù)庫端的事務數(shù)量，為了保證測試的嚴謹性，需查看Web應用通過的Transactions數(shù)量X2。

① 若X2≤X3，說明成功寫入數(shù)據(jù)庫端的事務數(shù)量大于或等于Web應用成功發(fā)送的數(shù)據(jù)量，測試過程中未發(fā)生數(shù)據(jù)丟失，測試過程中RPO等于0（注：在并發(fā)壓力測試過程中，因網(wǎng)絡延遲、響應超時等原因導致數(shù)據(jù)庫寫入成功的響應結果未反饋Web服務器端）。

② 若X2>X3，則Web應用成功發(fā)送的數(shù)據(jù)量大于成功寫入數(shù)據(jù)庫端的事務數(shù)量，測試過程中發(fā)生的數(shù)據(jù)丟失情況需要按照以下公式進行計算：

X4=（X2-X3）/X2 （1）

a. 若X4≥0.01%，則認為被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO不等于0，在執(zhí)行故障模擬的過程中出現(xiàn)事務丟失，且丟失數(shù)據(jù)量大于每秒寫入數(shù)據(jù)庫的數(shù)據(jù)。計算事務丟失數(shù)據(jù)量，查看數(shù)據(jù)庫事務日志中事務連續(xù)寫入時間記錄，分析數(shù)據(jù)庫記錄時間戳不連續(xù)的時間間隔。

b. 若0.001%≤X4<0.01%，則認為被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO約等于0。

c. 若X4<0.001%，則認為被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO等于0。

4? 測試結果及分析

為了驗證提出的基于場景的分布式關系型數(shù)據(jù)庫恢復點目標的測試方法，搭建實驗測試環(huán)境，對A、B、C三款分布式關系型數(shù)據(jù)庫產(chǎn)品進行RPO測試，并對測試結果進行分析。

4.1? A款數(shù)據(jù)庫測試結果及分析

按照測試要求搭建A款數(shù)據(jù)庫測試環(huán)境，部署測試工具，測試結果如下：

（1）測試過程中平均響應時間Average Response Time（單位：s）。從圖3可以看出，模擬單節(jié)點故障后，切換過程中響應時間有明顯的提升;切換完成后，整個響應時間趨于穩(wěn)定，數(shù)據(jù)庫連接正常。

（2）測試過程中每秒虛擬用戶HTTP請求數(shù)（Hits per Second）。從圖4可以看出，當模擬單節(jié)點故障后，每秒虛擬用戶HTTP請求數(shù)出現(xiàn)較大浮動的下降;運行4 min后，每秒虛擬用戶HTTP請求數(shù)趨于穩(wěn)定且恢復至故障前水平。整個過程中，數(shù)據(jù)庫連接正常。

（3）LoadRunner測試工具記錄的通過Transactions數(shù)量。如圖5所示，X1=7 860 902，該數(shù)值為客戶端發(fā)送至Web應用并成功響應的Transactions數(shù)量。

（4）測試結束后在數(shù)據(jù)庫通過SQL語句

select count （1） form t_gh;

查看數(shù)據(jù)庫該表中的記錄數(shù)，得到X3=7 814 974，如圖6所示。

（5）對比差值X1-X3=45 928，即數(shù)據(jù)庫端丟失數(shù)據(jù)條數(shù)為45 928，計算數(shù)據(jù)丟失比，得

X4=（7 860 902-7 814 974）/7 860 902=0.584%

（2）

X4>0.01%，表明被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO不等于0。

（6）通過查看數(shù)據(jù)庫寫入日志記錄發(fā)現(xiàn)，數(shù)據(jù)庫記錄時間戳不連續(xù)的時間間隔為80 s，日志部分截圖如圖7所示。因此，被測的分布式關系型數(shù)據(jù)庫產(chǎn)品RPO為80 s。

4.2? B款數(shù)據(jù)庫測試結果及分析

按照測試要求搭建B款數(shù)據(jù)庫測試環(huán)境，部署測試工具，測試結果如下：

（1）測試過程中Average Response Time。從圖8可以看出，模擬單節(jié)點故障后，切換過程中響應時間有明顯的提升;切換完成后，整個響應時間趨于穩(wěn)定，數(shù)據(jù)庫連接正常。

（2）測試過程中每秒虛擬用戶HTTP請求數(shù)。從圖9可以看出，模擬單節(jié)點故障后，每秒虛擬用戶HTTP請求數(shù)出現(xiàn)較大幅度的下降;運行2 min后，每秒虛擬用戶HTTP請求數(shù)趨于穩(wěn)定，且恢復至故障前水平。整個過程中，數(shù)據(jù)庫連接正常。

（3）LoadRunner測試工具記錄的通過Transactions數(shù)量。如圖10所示，X1的數(shù)值為17 070 507，測試過程中Transactions的Total Failed數(shù)值為0 ，未出現(xiàn)報錯。

（4）查看Tomcat日志記錄不通過Transactions數(shù)量為100（如圖11所示），實際通過的Transactions數(shù)量X2=17 070 407。

（5）測試結束后，在數(shù)據(jù)庫通過SQL語句

select count （1） form t_gh;

查看數(shù)據(jù)庫該表中的記錄數(shù)，得到X3=17 070 408，如圖12所示。

（6）通過以上測試數(shù)據(jù)可以看出，X1>X3，X2

4.3? C款數(shù)據(jù)庫測試結果及分析

（1）測試過程中Average Response Time。從圖13中可以看出，模擬單節(jié)點故障后，響應時間較故障前提升4倍;切換完成后，整個響應時間趨于穩(wěn)定，數(shù)據(jù)庫連接正常。

（2）測試過程中每秒虛擬用戶HTTP請求數(shù)。從圖14可以看出，當模擬單節(jié)點故障后，每秒虛擬用戶HTTP請求數(shù)出現(xiàn)較大幅度的下降，整體性能下降，但整個過程中數(shù)據(jù)庫未出現(xiàn)中斷，連接正常。

（3）LoadRunner測試工具記錄的通過Transactions數(shù)量。如圖15所示，X1的數(shù)值為4 867 970，測試過程中Transactions的Total Failed數(shù)值為0 ，未出現(xiàn)報錯。

（4）查看Tomcat日志記錄通過Transactions數(shù)量X2為4 867 936，如圖16所示。

（5）測試結束后，在數(shù)據(jù)庫通過SQL語句

select count （1） form t_gh;

查看數(shù)據(jù)庫該表中的記錄數(shù)X3為4 867 958。

（6）通過以上測試數(shù)據(jù)可以看出，X1>X3，X2

5? 結束語

本文提出了一種基于場景的分布式關系型數(shù)據(jù)庫恢復點目標的測試方法，將RPO測試指標引入分布式關系型數(shù)據(jù)庫質(zhì)量測試，能夠對被測數(shù)據(jù)庫的容災能力進行評價，且通過實際的工程實踐證明了方法的可行性與正確性，對數(shù)據(jù)庫的應用方具有很高的參考價值，也為后續(xù)數(shù)據(jù)庫相關產(chǎn)品的測試評價提供了思路與方法。

致謝

感謝中國軟件評測中心的領導和同事，在本文寫作過程中，他們提供了許多無私的幫助，使得這篇文章得以順利完成。感謝審稿專家在百忙之中審閱我們的文章，您們的意見為提高我們文章的質(zhì)量帶來了很大幫助。歡迎讀者批評和指正。

參考文獻

[1] 王昆， 高可用分布式任務調(diào)度與執(zhí)行系統(tǒng)設計與實現(xiàn)[D]. 西安： 西安電子科技大學， 2019.

[2] 中國人民銀行. 中國金融業(yè)信息技術“十三五”發(fā)展規(guī)劃[OL]. http：//www.pbc.gov.cn/zhengwugongkai/127924/128038/128109/3333998/index.html. 2017-06-27.

[3] 螞蟻金服科技. 螞蟻金服自研數(shù)據(jù)庫OceanBase如何登 頂TPC-C[OL]. https：//segmentfault.com/a/1190000020597597. 2019-10-05

[4] 陳宏， 郭素芹， 羅順輝， 等. 信息系統(tǒng)災難備份策略及關鍵技術研究[J]. 電力信息化， 2011， 9（10）：8-13.

[5] 邵側英. 分布式數(shù)據(jù)庫系統(tǒng)及其應用： 第2版[M]. 北京： 科學出版社， 2005.

[6] 葉驕龍. 面向數(shù)據(jù)庫的CDP容災系統(tǒng)關鍵技術研究[D]. 杭州： 杭州電子科技大學，2015

[7] 王君軍. 分布式異構數(shù)據(jù)庫系統(tǒng)的網(wǎng)絡容災技術研究[D]. 長春： 長春理工大學， 2011.

[8] 朱濤， 郭進偉， 周歡， 等. 分布式數(shù)據(jù)庫中一致性與可用性的關系[J]. 軟件學報， 2018， 29（1）： 131-149

[9] 張宇. 分布式數(shù)據(jù)庫一致性和可用性方法優(yōu)化方案研究[D]. 成都： 成都理工大學， 2014.

[10] 信息安全技術 信息系統(tǒng)災難恢復規(guī)范： GB/T 20889-2007[S]. 北京： 中國標準出版社， 2007.