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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）日志文件的設計

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

事務(wù)的處理進(jìn)程在事務(wù)的保存點(diǎn)根據事務(wù)的信息添加一行記錄。每個(gè)日志文件長(cháng)度達到ROWMAX行后，做一個(gè)標記，創(chuàng )建一個(gè)新的日志順序文件，并刷新事務(wù)進(jìn)程的寫(xiě)緩沖區，開(kāi)始在新的日志文件中記錄。

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

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

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

為了提高寫(xiě)日志的效率、減少系統資源的開(kāi)銷(xiāo)，事務(wù)的狀態(tài)值可以用一個(gè)字節表示，事務(wù)的標識可以用定長(cháng)個(gè)數的字節表示。

日志文件的同步寫(xiě)操作在成千上萬(wàn)的事務(wù)并發(fā)處理過(guò)程中，可能成為事務(wù)處理器的瓶頸。因此有必要同時(shí)開(kāi)辟若干個(gè)寫(xiě)緩沖區和若干個(gè)日志文件供不同的事務(wù)并發(fā)寫(xiě)日志。

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

（1）恢復方式

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

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

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

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

（3）事務(wù)恢復

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

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

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

　　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 系統的模型結構

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

（2）模型結構

系統的模型結構如圖3所示。

3 結 論

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