淺談事務(wù)管理器的事務(wù)恢復(fù)處理方案

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

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

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

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

1  OTS中的事務(wù)失敗模型和恢復(fù)機制

1.1 事務(wù)的失敗模型

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

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

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

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

（2）事務(wù)服務(wù)器

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

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

（3）恢復(fù)服務(wù)器

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

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

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

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

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

2  事務(wù)的恢復(fù)處理

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

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

2.1 事務(wù)的正常階段

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

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

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

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

（2）日志文件的設(shè)計

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

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

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

事務(wù)寫日志的流程圖如圖1所示。

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

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

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

2.2 事務(wù)的恢復(fù)階段

（1）恢復(fù)方式

事務(wù)的恢復(fù)有二種可行的方式：

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

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

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

（3）事務(wù)恢復(fù)

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

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

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

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

　　==ROLLEDBACK）{

　　//忽略這些事務(wù)

　　}

　　if（Log.decision==UNKNOWN）

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

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

　　//重啟該事務(wù)

　　Restart（tx）

　　//回滾事務(wù)

　　tx.rollback（）；

　　}

　　if（Log.decision==DECISION_TO_ROLLBACK）

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

　　//回滾命令

　　//重啟該事務(wù)

　　Restart（tx）

　　//回滾事務(wù)

　　tx.rollback（）；

　　if（Log.decision==DECISION_TO_COMMIT）

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

　　//回滾命令

　　//重啟該事務(wù)

　　Restart（tx）

　　//提交事務(wù)

　　tx.commit（）；

2.3 系統(tǒng)的模型結(jié)構(gòu)

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

（2）模型結(jié)構(gòu)

系統(tǒng)的模型結(jié)構(gòu)如圖3所示。

3  結(jié)  論

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