分散式資料庫事務的兩階段提交介紹

在分散式系統中，各個節點之間在物理上相互獨立，通過網路進行溝通和協調。由於存在事務機制，可以保證每個獨立節點上的資料操作可以滿足ACID。但是，相互獨立的節點之間無法準確的知道其他節點中的事務執行情況。所以從理論上講，兩臺機器理論上無法達到一致的狀態。如果想讓分散式部署的多臺機器中的資料保持一致性，那麼就要保證在所有節點的資料寫操作，要不全部都執行，要麼全部的都不執行。但是，一臺機器在執行本地事務的時候無法知道其他機器中的本地事務的執行結果。所以他也就不知道本次事務到底應該commit還是 roolback。所以，常規的解決辦法就是引入一個“協調者”的元件來統一排程所有分散式節點的執行。


2PC

二階段提交(Two-phaseCommit)是指，在計算機網路以及資料庫領域內，為了使基於分散式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種演算法(Algorithm)。通常，二階段提交也被稱為是一種協議(Protocol))。在分散式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的元件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的資料寫入磁碟等等)。因此，二階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。


準備階段

事務協調者(事務管理器)給每個參與者(資源管理器)傳送Prepare訊息，每個參與者要麼直接返回失敗(如許可權驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種“萬事俱備，只欠東風”的狀態。


可以進一步將準備階段分為以下三個步驟：


1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。


2）參與者節點執行詢問發起為止的所有事務操作，並將Undo資訊和Redo資訊寫入日誌。（注意：若成功這裡其實每個參與者已經執行了事務操作）


3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”訊息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”訊息。
提交階段


如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(Rollback)訊息；否則，傳送提交(Commit)訊息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)


接下來分兩種情況分別討論提交階段的過程。


當協調者節點從所有參與者節點獲得的相應訊息都為”同意”時:

1）協調者節點向所有參與者節點發出”正式提交(commit)”的請求。


2）參與者節點正式完成操作，並釋放在整個事務期間內佔用的資源。


3）參與者節點向協調者節點傳送”完成”訊息。


4）協調者節點受到所有參與者節點反饋的”完成”訊息後，完成事務。


如果任一參與者節點在第一階段返回的響應訊息為”中止”，或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：




1）協調者節點向所有參與者節點發出”回滾操作(rollback)”的請求。


2）參與者節點利用之前寫入的Undo資訊執行回滾，並釋放在整個事務期間內佔用的資源。


3）參與者節點向協調者節點傳送”回滾完成”訊息。


4）協調者節點受到所有參與者節點反饋的”回滾完成”訊息後，取消事務。
不管最後結果如何，第二階段都會結束當前事務。


二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：


1、同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。


2、單點故障。由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者當機導致的參與者處於阻塞狀態的問題）


3、資料不一致。在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了區域性網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分散式系統便出現了資料部一致性的現象。


4、二階段無法解決的問題：協調者再發出commit訊息之後當機，而唯一接收到這條訊息的參與者同時也當機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15498/viewspace-2140089/，如需轉載，請註明出處，否則將追究法律責任。