淺談事務管理器的事務恢復處理方案

隨來社會的進步，計算機的廣泛應用，很多事務處理過程中事務的恢復工作一般依賴于計算機數(shù)據(jù)庫管理系統(tǒng)，而事務管理器必須做好分布式事務處理的事務恢復處理。這需要做好二個階段的工作：在正常的事務處理過程中，交易中間件在穩(wěn)定存儲器中完整記錄事務恢復時的必要信息；在事務的恢復階段，恢復系統(tǒng)根據(jù)穩(wěn)定存儲器中記錄的事務相關信息恢復事務。本文就對該系統(tǒng)進行講解。

在OMG組織的OTS（對象事務服務）中規(guī)定了一套事務失敗恢復的模型。該模型是基于假定回滾的策略恢復失敗的事務。假定回滾是事務二階段提交協(xié)議的一種效率優(yōu)化策略，事務發(fā)起者在決定提交之前和資源在準備好之前都不用寫任何日志。這樣在失敗發(fā)生后重新啟動時，所有未記錄日志的事務都認為已經(jīng)做過回滾操作。

ACID，指數(shù)據(jù)庫事務正確執(zhí)行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（CONsiSTency）、隔離性（IsolATIon）、持久性（Durability）。一個支持事務（TransacTIon）的數(shù)據(jù)庫系統(tǒng)，必需要具有這四種特性，否則在事務過程（Transaction processing）當中無法保證數(shù)據(jù)的正確性，交易過程極可能達不到交易方的要求。

本文分析了OTS的事務失敗模型的恢復機制，用Java語言實現(xiàn)了交易中間件的事務恢復子系統(tǒng)，從而保證了分布式交易處理的完整性和一致性。

1 OTS中的事務失敗模型和恢復機制

1.1 事務的失敗模型

事務服務在應用、系統(tǒng)或通信失敗時，要提供事務的原子性結果。下面描述失敗發(fā)生時各應用實體的行為。

（1）事務創(chuàng)建者

局部失敗：在事務創(chuàng)建者發(fā)出提交命令之前的失敗將引起事務回滾。在事務創(chuàng)建者發(fā)出提交命令之后而在事務結果報告之前的失敗，依賴于時機導致提交或回滾。這種情況下事務的完成情況與事務創(chuàng)建者的失敗無關。

外部失?。喝魏卧谑聞談?chuàng)建者發(fā)出提交命令之前的外部失敗，都將引起事務的回滾。在事務創(chuàng)建者發(fā)出提交命令之后而在事務結果報告之前的失敗，意味客戶端可能不會通知事務的結果，這依賴于失敗的特征和提交命令是否使用report_heuristics選項。但這也不是可靠的方法，因為可能得到事務不存在的結果。

（2）事務服務器

局部失敗：事務服務器失敗后，事務服務如果實現(xiàn)可選的檢查方法，將引起事務的回滾。如果沒有實現(xiàn)可選的檢查方法，事務是否回滾取決于事務的提交命令是否發(fā)出。當未檢查的客戶端在收到所有服務器的應答之前發(fā)出提交命令時就是這種情況。

外部失?。喝魏卧谑聞辗掌鲌?zhí)行過程發(fā)生的外部失敗都將引起事務的回滾。事務對象的方法執(zhí)行時發(fā)生失敗，將不會影響方法的執(zhí)行。方法將會正常結束，返回結果到客戶端。最后事務回滾異常返回到發(fā)出提交命令的客戶端。

（3）恢復服務器

可恢復服務器在失敗發(fā)生時的行為決定于Coordinator與可恢復服務器的資源對象之間的二階段提交協(xié)議。

1.2 事務失敗后的繼續(xù)完成

通常，完成方法是在失敗發(fā)生點繼續(xù)完成事務。這意味著Coordinator常常有責任向注冊的資源發(fā)送提交命令。某些失敗情況下也需要資源初始化恢復程序。

資源代表與某一事務關聯(lián)的可恢復數(shù)據(jù)的集合。當失敗恢復時，已經(jīng)準備好的資源使用RecoveryCoordinator對象的reply_completion方法確定事務的結果和完成事務。

根Coordinator在日志記錄決定提交前的失敗可能是單方面的回滾事務。如果所有資源都準備好，需要初始化的恢復過程如下：若根Coordinator的結果是提交，則發(fā)出提交命令繼續(xù)完成協(xié)議；若根Coordinator的結果是回滾，則發(fā)出回滾命令繼續(xù)完成協(xié)議。

2 事務的恢復處理

事務恢復，就是能夠在容錯的方式下繼續(xù)完成事務。通過日志的記錄信息，在恢復過程中使用這些有用的信息恢復事務。

事務恢復的二個階段是：①正常操作時，在事務處理過程中存儲必要的信息到日志順序文件，后臺進程對已完成的順序文件做歸檔操作。②恢復過程中，通過歸檔文件和日志文件的信息恢復事務。

2.1 事務的正常階段

（1）事務的狀態(tài)及保存點

在OTS中，事務的惟一標識是事務標識。事務標識由三個字段的數(shù)據(jù)結構表示：全局事務標識，用GtxID表示；分支事務標識，用BqualID表示；事務的格式標識，用FORMATID表示。由以上三個字段組成的事務標識可以惟一標識任何范圍內(nèi)分布式計算環(huán)境中的一個事務。

事務在其整個生命周期中存在以下的狀態(tài)：活動事務，正在準備的事務，準備好的事務，正在提交的事務，已完成提交的事務，正在回滾的事務，已完成回滾的事務，標記為回滾的事務，出現(xiàn)啟發(fā)式異常的事務。

根據(jù)OTS規(guī)范的事務失敗假定回滾策略，所有在事務失敗時沒有決定提交或回滾的事務，在恢復處理過程中都可以忽略。為了簡化事務失敗恢復的操作，提高交易中間件的事務處理能力，選取事務處理過程中的以下幾個關鍵點做為事務的保存點。在事務的生命周期中遇到事務的保存點，就必須在事務的日志文件中記錄下事務的相關信息程中使用。事務的保存點如下：PREPARED:二階段提交事務的準備階段正常完成后，事務管理器向各個資源發(fā)出提交命令之前；COMMIteD:事務提交正常完成之后；ROLLBACKED:事務回滾正常完成之后；UNKNOWN:事務出現(xiàn)HEURISTIC異常。在事務的保存點除了記錄事務的狀態(tài)信息以外，還需要記錄事務的標識信息?？梢杂萌齻€值分別記錄事務的全局事務標識、分支事務標識及格式標識。

（2）日志文件的設計

日志文件以行數(shù)據(jù)作為結構單元。一行數(shù)據(jù)包括以下幾列：第一列值表示全局事務標識；第二列值表示分支事務標識（BqualID）；第三列值表示格式標識；第四列值表示事務保存點的狀態(tài)；第五列值是行結束符。每個文件的行數(shù)可以配置為一個定值ROWMAX,寫滿了一個日志文件后，便可以開始寫下一個順序文件。

事務的處理進程在事務的保存點根據(jù)事務的信息添加一行記錄。每個日志文件長度達到ROWMAX行后，做一個標記，創(chuàng)建一個新的日志順序文件，并刷新事務進程的寫緩沖區(qū)，開始在新的日志文件中記錄。

后臺單獨有一個線程對已寫滿的日志文件做歸檔操作。歸檔文件和日志文件的結構是相同的，所有的日志文件歸檔后保存到一個歸檔文件中。日志文件歸檔完成后就刪除該日志文件或做歸檔完成標記。

事務寫日志的流程圖如圖1所示。

（3）其他優(yōu)化

為了提高寫日志的效率、減少系統(tǒng)資源的開銷，事務的狀態(tài)值可以用一個字節(jié)表示，事務的標識可以用定長個數(shù)的字節(jié)表示。

日志文件的同步寫操作在成千上萬的事務并發(fā)處理過程中，可能成為事務處理器的瓶頸。因此有必要同時開辟若干個寫緩沖區(qū)和若干個日志文件供不同的事務并發(fā)寫日志。

2.2 事務的恢復階段

（1）恢復方式

事務的恢復有二種可行的方式：

①事務管理器恢復并發(fā)送結果到資源。資源不用主動參與恢復過程，只是正常的提交或回滾命令被觸發(fā)。

②資源沒有發(fā)現(xiàn)事務結果傳遞過來，就發(fā)請求到事務管理器。事務管理器恢復RecoveryCoordinator對象，資源通過該對象的replay_completion（）方法請求獲得事務結果，如果不能獲得結果信息，則回滾事務，否則按獲得的結果完成事務。

為了事務的完整性，OTS在恢復時，既要恢復RecoveryCoordinator對象，又要根據(jù)日志中事務的狀態(tài)向注冊的資源發(fā)送commit（）或rollback（）命令。

（3）事務恢復

事務恢復根據(jù)以下規(guī)則進行：所有活動的事務都必須恢復，所有已經(jīng)準備提交的事務都提交，所有已經(jīng)準備回滾的事務都回滾，所有狀態(tài)未知的事務都回滾。

事務發(fā)生失敗后，在交易中間件重啟時要做恢復操作。首先讀取失敗時日志目錄下所有未來得及歸檔的日志文件，再讀取歸檔文件中的內(nèi)容?；謴瓦^程如圖2所示。

讀取日志文件和歸檔文件后，要根據(jù)以下算法篩選出失敗時沒有完成的事務。下面是篩選算法的Java原語：

　　if（Log.decision==COMMITED || Log.decision

　　==ROLLEDBACK）{

　　//忽略這些事務

　　}

　　if（Log.decision==UNKNOWN）

　　//日志文件中存在需要重新提交的事務，重啟Coordinator,

　　//發(fā)出提交命令

　　//重啟該事務

　　Restart（tx）

　　//回滾事務

　　tx.rollback（）；

　　}

　　if（Log.decision==DECISION_TO_ROLLBACK）

　　//日志文件中存在需要回滾的事務，重啟Coordinator,發(fā)出

　　//回滾命令

　　//重啟該事務

　　Restart（tx）

　　//回滾事務

　　tx.rollback（）；

　　if（Log.decision==DECISION_TO_COMMIT）

　　//日志文件中存在需要回滾的事務，重啟Coordinator,發(fā)出

　　//回滾命令

　　//重啟該事務

　　Restart（tx）

　　//提交事務

　　tx.commit（）；

2.3 系統(tǒng)的模型結構

（1）系統(tǒng)模型主要由四個對象組成：①日志文件操作對象。該對象保證事務管理器所有進程共享寫日志文件和寫緩沖區(qū)。通過該對象，格式化日志的行數(shù)據(jù)并寫入日志文件，讀出日志文件的數(shù)據(jù)并解析行數(shù)據(jù)，刪除滿足條件的行數(shù)據(jù)等。②日志管理對象。③日志歸檔對象。后臺線程定時歸檔日志文件。從日志文件和歸檔文件中篩選出未完成的事務記錄，更新到歸檔文件中。④日志恢復對象。事務管理器重啟時，讀取歸檔文件和未來得及歸檔的日志文件的內(nèi)容，恢復日志中未完成的事務。

（2）模型結構

系統(tǒng)的模型結構如圖3所示。

3 結 論

依據(jù)OMG組織的OTS規(guī)范，本文分析了分布式事務的恢復處理過程，并實現(xiàn)了該系統(tǒng)在交易中間件的應用。它不僅適合于一般的事務失敗恢復，而且保證了事務失敗情況下的事務完整性和一致性。在操作日志文件時利用格式化的行數(shù)據(jù)的優(yōu)越性，可以減少事務處理過程中持久化事務相關信息占用的系統(tǒng)資源，提高交易中間件事務處理的效率。由于事務失敗的絕對性存在，建立事務失敗的分布式組件模型，明確各組件在事務恢復過程的職責，協(xié)調(diào)好各組件參與事務的恢復處理。