1. 二階段提交協(xié)議的由來

X/Open 組織提出了分布式事務(wù)處理的規(guī)范 DTP 模型(Distributed Transaction Processing)，該模型中主要定義了三個基本組件，分別是

• 應(yīng)用程序(Application?Program?，簡稱AP)：用于定義事務(wù)邊界(即定義事務(wù)的開始和結(jié)束)，并且在事務(wù)邊界內(nèi)對資源進行操作。

• 資源管理器(Resource?Manager，簡稱RM)：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式。

• 事務(wù)管理器(Transaction?Manager?，簡稱TM)：負責(zé)分配事務(wù)唯一標識，監(jiān)控事務(wù)的執(zhí)行進度，并負責(zé)事務(wù)的提交、回滾等。

一般，我們稱TM為事務(wù)的協(xié)調(diào)者，而稱RM為事務(wù)的參與者。TM?與?RM?之間的通信接口，則由?XA?規(guī)范來約定。

在?DTP?模型的基礎(chǔ)上，才引出了二階段提交協(xié)議來處理分布式事務(wù)。

2. 二階段提交基本算法

2.1 前提

二階段提交協(xié)議能夠正確運轉(zhuǎn)，需要具備以下前提條件：

存在一個協(xié)調(diào)者，與多個參與者，且協(xié)調(diào)者與參與者之間可以進行網(wǎng)絡(luò)通信

參與者節(jié)點采用預(yù)寫式日志，日志保存在可靠的存儲設(shè)備上，即使參與者損壞，不會導(dǎo)致日志數(shù)據(jù)的消失

參與者節(jié)點不會永久性損壞，即使后仍然可以恢復(fù)

實際上，條件2和3所要求的，現(xiàn)今絕大多數(shù)關(guān)系型數(shù)據(jù)庫都能滿足。

2.2 基本算法

2.2.1 第一階段

協(xié)調(diào)者節(jié)點向所有參與者節(jié)點詢問是否可以執(zhí)行提交操作，并開始等待各參與者節(jié)點的響應(yīng)。

參與者節(jié)點執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志。

各參與者節(jié)點響應(yīng)協(xié)調(diào)者節(jié)點發(fā)起的詢問。如果參與者節(jié)點的事務(wù)操作實際執(zhí)行成功，則它返回一個"同意"消息；如果參與者節(jié)點的事務(wù)操作實際執(zhí)行失敗，則它返回一個"中止"消息。

2.2.2 第二階段

當(dāng)協(xié)調(diào)者節(jié)點從所有參與者節(jié)點獲得的相應(yīng)消息都為"同意"時：

協(xié)調(diào)者節(jié)點向所有參與者節(jié)點發(fā)出"正式提交"的請求。

參與者節(jié)點正式完成操作，并釋放在整個事務(wù)期間內(nèi)占用的資源。

參與者節(jié)點向協(xié)調(diào)者節(jié)點發(fā)送"完成"消息。

協(xié)調(diào)者節(jié)點收到所有參與者節(jié)點反饋的"完成"消息后，完成事務(wù)。

如下圖所示：

如果任一參與者節(jié)點在第一階段返回的響應(yīng)消息為"終止"，或者?協(xié)調(diào)者節(jié)點在第一階段的詢問超時之前無法獲取所有參與者節(jié)點的響應(yīng)消息時：

協(xié)調(diào)者節(jié)點向所有參與者節(jié)點發(fā)出"回滾操作"的請求。

參與者節(jié)點利用之前寫入的Undo信息執(zhí)行回滾，并釋放在整個事務(wù)期間內(nèi)占用的資源。

參與者節(jié)點向協(xié)調(diào)者節(jié)點發(fā)送"回滾完成"消息。

協(xié)調(diào)者節(jié)點收到所有參與者節(jié)點反饋的"回滾完成"消息后，取消事務(wù)。

如下圖所示：

3. 二階段提交缺陷分析

二階段提交協(xié)議除了協(xié)議本身具有的局限性之外，如果我們把以下情況也考慮在內(nèi)：

• 協(xié)調(diào)者宕機

• 參與者宕機

• 網(wǎng)絡(luò)閃斷(腦裂)

那么二階段提交協(xié)議實際上是存在很多問題的

3.1協(xié)議本身的缺陷

協(xié)議本身的缺陷是指，在協(xié)議正常運行的情況下，無論全局事務(wù)最終是被提交還是被回滾，依然存在的問題，而暫不考慮參與者或者協(xié)調(diào)者宕機，或者腦裂的情況。

3.1.1 性能問題

當(dāng)網(wǎng)絡(luò)閃斷發(fā)生在第一階段時，可能會有部分參與者進入阻塞狀態(tài)，全局事務(wù)無法結(jié)束。
當(dāng)發(fā)生在第二階段時，可能發(fā)生部分參與者執(zhí)行了?commit?而部分參與者未執(zhí)行?commit，從而導(dǎo)致全局數(shù)據(jù)不一致的問題。

參與者的本地事務(wù)開啟后，直到它接收到協(xié)調(diào)者的?commit?或?rollback? 命令后，它才會提交或回滾本地事務(wù)，并且釋放由于事務(wù)的存在而鎖定的資源。不幸的是，一個參與者收到協(xié)調(diào)者的?commit?或者?rollback? 的前提是：協(xié)調(diào)者收到了所有參與者在一階段的回復(fù)。
如果說，協(xié)調(diào)者一階段詢問多個參與者采用的是順序詢問的方式，那么一個參與者最快也要等到協(xié)調(diào)者詢問完所有其它的參與者后才會被通知提交或回滾，在協(xié)調(diào)者未詢問完成之前，這個參與者將保持占用相關(guān)的事務(wù)資源。
即使，協(xié)調(diào)者一階段詢問多個參與者采用的是并發(fā)詢問的方式，那么一個參與者等待收到協(xié)調(diào)者的提交或者回滾通知的時間，將取決于在一階段過程中，響應(yīng)協(xié)調(diào)者最慢的那個參與者的響應(yīng)時間。
無論是哪一種情況，參與者都將在整個一階段持續(xù)的時間里，占用住相關(guān)的資源，參與者事務(wù)的處理時間增加。若此時在參與者身上有其它事務(wù)正在進行，那么其它事務(wù)有可能因為與這個延遲的事務(wù)有沖突，而被阻塞，這些被阻塞的事務(wù)，進而會引起其它事務(wù)的阻塞。
總而言之，整體事務(wù)的平均耗時增加了，整體事務(wù)的吞吐量也降低了。這會使得整個應(yīng)用系統(tǒng)的延遲變高，吞吐量降低，可擴展性降低(當(dāng)參與者變多的時候，延遲可能更嚴重)。
總的來說，二階段提交協(xié)議，不是一個高效的協(xié)議，會帶來性能上的損失。

3.1.2 全局事務(wù)隔離性的問題

全局事務(wù)的隔離性與單機事務(wù)的隔離性是不同的。
當(dāng)我們在單機事務(wù)中提到不允許臟讀時，那么意味著在事務(wù)未提交之前，它對數(shù)據(jù)造成的影響不應(yīng)該對其它事務(wù)可見。
當(dāng)我們在全局事務(wù)中提到不允許臟讀時，意味著，在全局事務(wù)未提交之前，它對數(shù)據(jù)造成的影響不應(yīng)該對其它事務(wù)可見。
在二階段提交協(xié)議中，當(dāng)在第二階段所有的參與者都成功執(zhí)行 ?commit?或者?rollback?之后，全局事務(wù)才算結(jié)束。但第二階段存在這樣的中間狀態(tài)：即部分參與者已執(zhí)行?commit?或者? rollback，而其它參與者還未執(zhí)行?commit?或者?rollback。此刻，已經(jīng)執(zhí)行?commit?或者?rollback? 的參與者，它對它本地數(shù)據(jù)的影響，對其它全局事務(wù)是可見的，即存在臟讀的風(fēng)險。對于這種情況，二階段協(xié)議并沒有任何機制來保證全局事務(wù)的隔離性，無法做到“讀已提交”這樣的隔離級別。

3.2 協(xié)調(diào)者宕機

如果在第一階段，協(xié)調(diào)者發(fā)生了宕機，那么因為所有參與者無法再接收到協(xié)調(diào)者第二階段的 commit 或者 rollback 命令，所以他們會阻塞下去，本地事務(wù)無法結(jié)束，
如果協(xié)調(diào)者在第二階段發(fā)生了宕機，那么可能存在部分參與者接收到了?commit/rollback?命令，而部分沒有，因此這部分沒有接收到命令的參與者也會一直阻塞下去。
協(xié)調(diào)者宕機屬于單點問題，可以通過另選一個協(xié)調(diào)者的方式來解決，但這只能保證后續(xù)的全局事務(wù)正常運行。而因為之前協(xié)調(diào)者宕機而造成的參與者阻塞則無法避免。如果這個新選擇的協(xié)調(diào)者也宕機了，那么一樣會帶來阻塞的問題。

3.3 參與者宕機

如果在第一階段，某個參與者發(fā)生了宕機，那么會導(dǎo)致協(xié)調(diào)者一直等待這個參與者的響應(yīng)，進而導(dǎo)致其它參與者也進入阻塞狀態(tài)，全局事務(wù)無法結(jié)束。
如果在第二階段，協(xié)調(diào)者發(fā)起?commit?操作時，某個參與者發(fā)生了宕機，那么全局事務(wù)已經(jīng)執(zhí)行了?commit?的參與者的數(shù)據(jù)已經(jīng)落盤，而宕機的參與者可能還沒落盤，當(dāng)參與者恢復(fù)過來的時候，就會產(chǎn)生全局數(shù)據(jù)不一致的問題。

3.4 網(wǎng)絡(luò)問題-腦裂

當(dāng)網(wǎng)絡(luò)閃斷發(fā)生在第一階段時，可能會有部分參與者進入阻塞狀態(tài)，全局事務(wù)無法結(jié)束。
當(dāng)發(fā)生在第二階段時，可能發(fā)生部分參與者執(zhí)行了?commit?而部分參與者未執(zhí)行?commit，從而導(dǎo)致全局數(shù)據(jù)不一致的問題。

4. 三階段提交

在二階段提交中，當(dāng)協(xié)調(diào)者宕機的時候，無論是在第一階段還是在第二階段發(fā)生宕機，參與者都會因為等待協(xié)調(diào)者的命令而進入阻塞狀態(tài)，從而導(dǎo)致全局事務(wù)無法繼續(xù)進行。因此，如果在參與者中引入超時機制，即，當(dāng)指定時間過去之后，參與者自行提交或者回滾。但是，參與者應(yīng)該進行提交還是回滾呢？悲觀的做法是，統(tǒng)一都回滾。但事情往往沒那么簡單。
當(dāng)?shù)谝浑A段，協(xié)調(diào)者宕機時，那么所有被阻塞的參與者選擇超時后回滾事務(wù)是最明智的做法，因為還未進入第二階段，所以參與者都不會接收到提交或者回滾的請求，當(dāng)前這個事務(wù)是無法繼續(xù)進行提交的，因為參與者不知道其它參與者的執(zhí)行情況，所以統(tǒng)一回滾，結(jié)束分布式事務(wù)。
在二階段提交協(xié)議中的第二階段，當(dāng)協(xié)調(diào)者宕機后，由于參與者無法知道協(xié)調(diào)者在宕機前給其他參與者發(fā)了什么命令，進入了第二階段，全局事務(wù)要么提交要么回滾，參與者如果引入超時機制，那么它應(yīng)該在超時之后提交還是回滾呢，似乎怎么樣都不是正確的做法。執(zhí)行回滾，太保守，執(zhí)行提交，太激進。
如果在二階段提交協(xié)議中，在第一階段和第二階段中間再引入一個階段，如果全局事務(wù)度過了中間這個階段，那么在第三階段，參與者就可以認為此刻進行提交的成功率會更大。但這難道不是治標不治本嗎，當(dāng)進入第三階段，全局事務(wù)需要進行回滾時候，如果協(xié)調(diào)者宕機，那么參與者超時之后自行進行提交事務(wù)，就會造成全局事務(wù)的數(shù)據(jù)不一致。
再考慮參與者宕機的情況下，協(xié)調(diào)者應(yīng)該在超時之后，對全局事務(wù)進行回滾。
總結(jié)起來，三階段提交主要在二階段提交的基礎(chǔ)上，為了解決參與者和協(xié)調(diào)者宕機的問題，而引入了超時機制，并因為超時機制，附帶引入中間這一層。
并且，三階段提交并沒有解決二階段提交的存在的腦裂的問題。
總而言之，二階段和三階段提交都無法完美地解決分布式事務(wù)的問題。關(guān)于三階段提交更詳細的算法和步驟，可以參考我的另外一篇文章《分布式事務(wù)概覽》

5. fescar/seata 二階段提交

總結(jié)

以上是生活随笔為你收集整理的事务超时时间无效_阿里分布式事务组件 fescar/seata 对 XA 2PC 的改进及其设计思想...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。