分布式關系型數據庫恢復點目標測試方法

呂韜 田峰 李征宇 張雪

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

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

引言

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

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

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

1? 分布式關系型數據庫與RPO

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

1.1? 分布式關系型數據庫

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

（1）管理、調度、處理分布式事務;

（2）支持跨數據中心的橫向擴展;

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

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

1.2? RPO的內涵與外延

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

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

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

2? 分布式關系型數據庫RPO測試方法設計

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

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

RPO的測試方法設計如下：

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

（2）斷開該節點的網絡，判斷數據庫是否穩定運行不退出，以及寫操作能否迅速恢復，記錄斷網時間;

（3）待被測數據庫穩定后，終止測試;

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

RPO的判定方法如下：

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

3? RPO測試過程

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

3.1? 測試環境搭建

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

測試工具建議選擇LoadRunner，此工具的作用一是模擬實際用戶，對Web應用系統進行持續訪問，從而對被測數據庫進行持續的寫操作;二是監測在故障發生時數據庫的性能表現。

此外，為了模擬實際業務場景，還需開發一個小型的Web應用系統，此系統的作用一是對被測產品進行連續寫操作，二是在故障發生時，通過監測此系統的運行狀態來判斷數據庫是否連續運行。

綜上，測試環境的軟硬件構成如圖1所示。

測試環境在搭建時，需要被測數據庫的廠商按照數據庫的特點進行節點分配，測試環境的標準拓撲圖如圖1所示。

3.2? 測試實施步驟

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

3.2.1? 測試環境部署與確認

按照圖1所示的測試環境拓撲圖搭建分布式關系型數據庫測試環境。搭建完成后，試運行被測數據庫，確保數據庫系統正常運行。

3.2.2? Web應用部署與確認

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

3.2.3? 測試工具部署及調試

在桌面終端部署LoadRunner工具，錄制腳本并調試，直至成功，確保可以對Web應用程序進行壓力測試。

3.2.4? 使用測試工具執行壓力測試

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

3.2.5? 故障模擬

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

3.2.6? 記錄分析測試結果

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

3.3? 測試結果記錄及處理

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

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

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

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

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

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

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

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

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

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

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

c. 若X4<0.001%，則認為被測的分布式關系型數據庫產品RPO等于0。

4? 測試結果及分析

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

4.1? A款數據庫測試結果及分析

按照測試要求搭建A款數據庫測試環境，部署測試工具，測試結果如下：

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

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

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

（4）測試結束后在數據庫通過SQL語句

select count （1） form t_gh;

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

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

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

（2）

X4>0.01%，表明被測的分布式關系型數據庫產品RPO不等于0。

（6）通過查看數據庫寫入日志記錄發現，數據庫記錄時間戳不連續的時間間隔為80 s，日志部分截圖如圖7所示。因此，被測的分布式關系型數據庫產品RPO為80 s。

4.2? B款數據庫測試結果及分析

按照測試要求搭建B款數據庫測試環境，部署測試工具，測試結果如下：

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

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

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

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

（5）測試結束后，在數據庫通過SQL語句

select count （1） form t_gh;

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

（6）通過以上測試數據可以看出，X1>X3，X2

4.3? C款數據庫測試結果及分析

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

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

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

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

（5）測試結束后，在數據庫通過SQL語句

select count （1） form t_gh;

查看數據庫該表中的記錄數X3為4 867 958。

（6）通過以上測試數據可以看出，X1>X3，X2

5? 結束語

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

致謝

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

參考文獻

[1] 王昆， 高可用分布式任務調度與執行系統設計與實現[D]. 西安： 西安電子科技大學， 2019.

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

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

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

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

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

[7] 王君軍. 分布式異構數據庫系統的網絡容災技術研究[D]. 長春： 長春理工大學， 2011.

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

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

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