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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

后臺(tái)單獨(dú)有一個(gè)線程對(duì)已寫(xiě)滿(mǎn)的日志文件做歸檔操作。歸檔文件和日志文件的結(jié)構(gòu)是相同的，所有的日志文件歸檔后保存到一個(gè)歸檔文件中。日志文件歸檔完成后就刪除該日志文件或做歸檔完成標(biāo)記。

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

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

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

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

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

（1）恢復(fù)方式

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

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

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

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

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

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

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

讀取日志文件和歸檔文件后，要根據(jù)以下算法篩選出失敗時(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 系統(tǒng)的模型結(jié)構(gòu)

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

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

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

3  結(jié)  論

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