高可用性軟件架構設計和實現論文

摘要：硬件宂餘可以極大地提高計算機應用系統的可用性，然而，一旦關鍵硬件出現故障或數據庫宕機，正在進行中的業務流程通常會中斷。探討了一種如何實現應用系統高可用性的軟件架構的設計方案，以彌補純硬件宂餘應用系統的不足。

關鍵詞：高可用性;軟件容錯;分佈式數據庫

在業內，計算機應用系統的可用性定義為計算機應用系統保持正常運行時間的百分比，通常用表1所示的“9”的個數來劃分可用性的類型。

通常，硬件宂餘(容錯計算機、雙機或多機集羣、磁盤陣列、SAN等)、數據複製、合理的災難備份和恢復策略都可以極大地提高計算機應用系統的可用性。正因為如此，當前，對於計算機應用系統的高可用性、業務的可持續性要求，業內通常以硬件系統的高可用性來應對或代替。常見的解決方案是雙機(或多機)集羣方案或直接採用容錯計算機來保障系統的高可用性，應用軟件的設計和開發往往僅注重業務流程的分析和過程控制。在這種完全依賴硬件來保障整個系統的可用性的系統裏，一旦關鍵硬件出現故障或數據庫宕機，正在進行中的業務流程(如需較長執行時間的事務處理、後台批處理過程等)必然會中斷，這是因為雙機切換也需要時間。對此，應用軟件本身並無多少作為，該類業務必須等待系統重新恢復後全部或部分重做。

本文以基於大型數據庫的應用系統為例，從“軟件容錯”設計的概念出發，參考“分佈式”數據庫結構設計，以“系統服務總線”為核心，給出了一種可行的高可用性軟件架構的設計方案，可以極大地提高應用軟件的可用性和業務系統的可持續性。無論是傳統的C/S架構，還是近年來流行的B/S架構，本文中給出的設計方案都有一定的參考意義。

1軟件結構模型

任何基於大型數據庫的應用系統，都可以抽象為對數據的“讀”和“寫”操作。至於客户端如何展現“讀”到的數據，以及“客户端”與“服務端”基於何種通信協議通信，不在本文討論之列。

軟件結構的設計其實就是針對“讀”和“寫”的一系列流程的設計。如何最大限度地保證系統中的所有“硬件”和“軟件”協同工作，正確完成每一次“讀”和“寫”的操作，也就是對系統“高可靠性”和“高可用性”的要求。

圖1是基於“軟件容錯”和“分佈式數據庫系統”的原理，並參照了計算機“總線”的工作原理給出的一種基於分佈式數據庫或文件系統的高可用性的軟件架構設計方案。系統採用3層架構：客户端、中間應用層和數據庫層。

2系統設計

2.1數據庫配置為了更清楚地闡述本文的設計方案，先對數據庫的配置及其功能進行描述。本系統中，數據庫按角色可劃分為如下三類數據庫：控制數據庫(COTROLL DB)、日誌數據庫(LOG DB)、業務數據庫(BUS DB_N)。

2.1.1控制數據庫

控制數據庫也可以是一個或多個系統控制(參數)文件。它存放要訪問的目標數據庫的節點(N)、端口、用户、文件頭、表、視圖等信息;存放對節點、業務數據庫、表或視圖的.授權或訪問控制信息;目標數據庫(或文件)的當前狀態(聯機/脱機、忙/空閒等);目標數據庫中的表或視圖的當前狀態(聯機/脱機、忙/空閒、加鎖/解鎖等)。

2.1.2日誌數據庫

日誌數據庫獨立於業務數據庫之外，用於記錄客户端節點信息、請求時刻和發來的所有請求的原始內容，但不做業務流程相關的處理、運算等。記錄每次數據操作分配的唯一的“事件號”(EVENT_ID)。對每一次客户端的“請求”，“系統服務總線”(SYSSRV)會分配唯一的標識符號，可以定義為有一定意義的字符串，比如，“當前時刻+流水號”。以上信息可以被壓縮、打包、加密後存放，以記錄格式保存於數據庫的表或文件中。它可以設計為數據庫中的一個或多個表，也可以是文件格式。

2.1.3業務數據庫

業務數據庫記錄所有業務相關的數據信息。所有業務數據庫的相關業務邏輯的數據結構相同，即，N個節點的業務數據庫中與業務模式相關的表、視圖、過程或其他程序設置相同。

需要特別指出的是：

(1)控制數據庫、日誌數據庫和業務數據庫可以是不同數據庫廠家或品牌的產品。比如，日誌數據庫可以採用低端的數據庫產品或開源數據庫系統，業務數據庫可以採用高端的大型數據庫產品。

(2)控制數據庫、日誌數據庫和業務數據庫在物理上和邏輯上是可以相互隔離的，這可以極大地提高系統的整體安全性。目標數據庫和要訪問的表或視圖對客户端來説是“不可見”的，由控制數據庫動態定義和控制。

(3)所有類別的數據庫在物理上位於一個或多個節點上，即節點N>=1;任意一個節點N上建有一個或多個業務數據庫(邏輯數據庫>=1);任意一個節點是一個完整的、可獨立工作的計算機。根據性能要求，可以是高性能PC機、PC服務器、小型機、集羣或超級計算機，或是它們的“混合體”;任意一個節點是指定網絡中的一個指定節點。

2.2應用層設計

中間應用層由5個後台進程構成：(1)系統服務總線(SYSSRV);(2)數據庫寫進程(DBWRT_N);(3)數據庫讀進程(DBRED_N);(4)數據庫在線恢復進程(DBRCY);(5)日誌檢查進程(LOGCHK)。

2.2.1系統服務總線

這是一個後台監聽、分發、調度總進程。設計目標具有一定的“自我修復”和“自我複製”動能。它可以根據負載情況，自我複製或開啟子進程響應新的負載;可以動態配置可服務的節點或客户端;可以為特定節點或客户端指定專用進程;它通過“DBWRT”和“DBRED”“讀/寫”日誌數據庫或日誌文件。

2.2.2寫進程

寫進程負責向所有節點寫數據。它可以配置成多進程/單進程模式;多進程模式，指對應每個業務數據庫N都有獨立的“寫”進程;單進程模式，指對應多個業務數據庫只有一個主進程，主進程開啟多個線程提供“寫”服務。

2.2.3讀進程

讀進程負責向所有節點讀數據，它可以配置成多進程/單進程模式。多進程模式指對應每個業務數據庫N都有獨立的“讀”進程，單進程模式指對應多個業務數據庫只有一個主進程，主進程開啟多個線程提供“讀”服務。

根據需要，讀進程可以配置成：向所有在線節點併發讀數據，返回最快的結果集，拋棄其他的結果集，並中斷其他讀進程;也可以配置成：隨機讀某個節點的數據，如果失敗或超時，則再隨機讀餘下的在線節點，直到“讀”成功或失敗;還可以配置成向所有節點順序讀數據，過程類似上面“隨機讀”。

以上“讀寫”業務數據庫的進程，設計上支持多種數據庫訪問接口，針對“表”或“視圖”提供統一格式的、標準的、動態的SQL數據操作接口和方法，完成對數據庫中表或視圖的增、刪、改、查和批處理操作。它們可以設計為數據庫中的存儲過程，也可以是C++，Java程序的API或混合體。

2.2.4數據庫在線恢復進程

該進程負責檢查全部或部分節點數據庫(包括所有授權控制數據庫、業務數據庫和日誌數據庫)或文件的工作狀態;檢查數據庫或文件表中數據的一致性;將以上檢查結果寫入日誌數據庫(或日誌文件)。

當某個業務數據庫中的表寫入失敗時，它負責從“日誌數據庫”的表或日誌文件中讀出原始數據，接着寫入出現問題的業務數據庫的表中，並檢查結果。或從其他節點的數據庫中讀相關數據並寫入到出現問題的業務數據庫的表中。

接收外部命令，根據“時間點”或“事件號”從特定時刻、特定數據庫(包括日誌數據庫)、特定表恢復數據到特定目標數據庫的表或文件。

2.2.5日誌檢查進程

該進程負責讀、寫日誌文件，檢查數據操作結果的一致性。如果不一致，則報告給“系統服務總線”，將問題數據庫或數據庫中的表、視圖設置為“離線”狀態。

3系統實現

3.1系統初始化啟動配置好的後台進程即完成系統初始化過程。

3.2數據“寫”流程

數據“寫”流程的主要步驟如下：(1)客户端通過給定協議(或混合多種通信協議)向後台“系統服務總線”發送“寫”請求。

(2)激活“數據庫寫進程”，將客户端的“請求”寫入“日誌數據庫”(或日誌文件)，並分配一個唯一的“事件號”。

(3)“系統服務總線”查詢“授權/控制數據庫”(或/配置文件)得到客户端請求訪問的數據存放的目標數據庫(或文件)節點N(或文件存放的節點N)、端口、用户、表、文件頭等信息。節點N可以是多個，即節點N>=1。

(4)“系統服務總線”向N個“數據庫寫進程”發送數據“寫”訪問請求，並得到各節點的返回結果集。

(5)只要有1個節點寫入成功，“系統服務總線”就將寫入成功的標誌發回客户端;“數據庫寫進程”將各節點的返回結果狀態寫入“日誌數據庫”(或日誌文件)中。

(6)“日誌監控”查詢“日誌數據庫”(或日誌文件)，比較N個節點的寫入狀態。如發現寫錯誤、失敗、超時等狀態，則將該“業務數據庫”(或文件、表、視圖)標誌為“非正常聯機數據庫”(或文件、表、視圖不可用)。

(7)激活“數據在線恢復進程”，進程為“非正常聯機數據庫”，則執行數據庫數據“同步”。在線同步恢復如失敗，則將該“數據庫”標誌為“需要DBA維護”的類別，留待DBA或軟件維護工程師處理。

3.3數據“讀”流程

數據“讀”流程的主要步驟如下：(1)客户端通過給定協議(或混合多種通信協議)向後台“系統服務總線”發送“讀”請求。

(2)激活“寫進程”，將客户端的“請求”寫入“日誌數據庫”(或日誌文件)，並分配一個唯一的“事件號”。

(3)“系統服務總線”查詢“授權/控制數據庫”(或/配置文件)得到客户端請求訪問的數據存放的目標數據庫節點N(或文件存放的節點N)、端口、用户、表等信息。

節點N可以是多點，即節點N>=1。

(4)“系統服務總線”查詢“授權/控制數據庫”(或/配置文件)得到可用的、空閒的目標數據庫節點N(或文件存放的節點N)。

(5)激活“讀進程”(或隨機、或順序)向N個節點的“業務數據庫”(或文件)發送數據“讀”訪問請求，並得到各節點的返回結果集。

(6)“系統服務總線”將最快返回的結果集發回客户端;拋棄其他結果集，中斷其他讀進程。

在本系統的設計和實現中，由於採用了“分佈式”數據庫或文件系統部署，只要N個節點中至少有一個節點的“業務數據庫”正常工作，因為一個或幾個“業務數據庫”系統(或節點硬件)故障所引起的業務系統的不可持續性理論上將可以完全避免，因而提高了系統的“容錯”性。

由於N個數據庫同時在線，且節點是否可用、空閒等狀態可實時監控，這為特定業務快速訪問和獨享訪問提供了先決條件。如可以指定某特定“業務數據庫”僅為某個或幾個特定客户端服務提供“讀”訪問。

因為設計了統一、標準的增、刪、改、查的過程方法或API，前端開發人員甚至不必寫任何SQL語句就可以完成對數據庫中表或視圖的操作，可以大大地縮短編程和調試時間。

需要指出的是，雖然“系統服務總線”具有“自我修復”和“自我複製”的特點，但因為“節點”硬件故障或“授權/控制數據庫”(或/配置文件)或“日誌數據庫”故障而引起的全系統不可用依然存在，因此，建議該節點採用性能好、可靠性高的中、高端服務器。