分布式事務 二階段提交與三階段提交

2021-08-20 06:20:28 字數 2169 閱讀 3276

一、二階段提交演算法描述

在分布式系統中,事務往往包含有多個參與者的活動,單個參與者上的活動是能夠保證原子性的,而多個參與者之間原子性的保證則需要通過兩階段提交來實現,兩階段提交是分布式事務實現的關鍵。

很明顯,兩階段提交保證了分布式事務的原子性,這些子事務要麼都做,要麼都不做。而資料庫的一致性是由資料庫的完整性約束實現的,永續性則是通過commit日誌來實現的,不是由兩階段提交來保證的。至於兩階段提交如何保證隔離性,可以參考large-scale incremental processing using distributed transactions and notifications中兩階段提交的具體實現。

兩階段提交的過程涉及到協調者和參與者。協調者可以看做成事務的發起者,同時也是事務的乙個參與者。對於乙個分布式事務來說,乙個事務是涉及到多個參與者的。具體的兩階段提交的過程如下: 

第一階段: 

首先,協調者在自身節點的日誌中寫入一條的日誌記錄,然後所有參與者傳送訊息prepare t,詢問這些參與者(包括自身),是否能夠提交這個事務; 

參與者在接受到這個prepare t 訊息以後,會根據自身的情況,進行事務的預處理,如果參與者能夠提交該事務,則會將日誌寫入磁碟,並返回給協調者乙個ready t資訊,同時自身進入可提交狀態;如果不能提交該事務,則記錄日誌,並返回乙個not commit t資訊給協調者,同時撤銷在自身上所做的資料庫改; 

第二階段: 

協調者會收集所有參與者的意見。(1)如果收到參與者發來的not commit t資訊,則標識著該事務不能提交,協調者會將abort t 記錄到日誌中,並向所有參與者傳送乙個abort t 資訊,讓所有參與者撤銷在自身上所有的預操作;(2)如果協調者收到所有參與者發來prepare t資訊,那麼協調者會將commit t日誌寫入磁碟,並向所有參與者傳送乙個commit t資訊,提交該事務。(3)若協調者遲遲未收到某個參與者發來的資訊,則認為該參與者傳送了乙個vote_abort資訊,從而取消該事務的執行。 

參與者接收到協調者發來的abort t資訊以後,參與者會終止提交,並將abort t 記錄到日誌中;如果參與者收到的是commit t資訊,則會將事務進行提交,並寫入記錄。

二、可能出現的問題

一般情況下,兩階段提交機制都能較好的執行,但可能出現下面三種問題: 

(1)協調者不宕機,參與者宕機; 

(2)協調者宕機,參與者不宕機; 

(3)協調者宕機,參與者也宕機; 

對於(1),當在事務進行過程中,有參與者宕機時,他重啟以後,可以通過詢問其他參與者或者協調者,從而知道這個事務到底提交了沒有。當然,這一切的前提都是各個參與者在進行每一步操作時,都會事先寫入日誌。 

對於(2),協調者宕機後,可以起新的協調者,然後查詢所有參與者的狀態是否有commit的,如果有,則繼續commit,如果都沒有,則abort。 

對於(3),是唯一乙個兩階段提交不能解決的困境是:當協調者在發出commit t訊息後宕機了,而唯一收到這條命令的乙個參與者也宕機了,這個時候這個事務就處於乙個未知的狀態,沒有人知道這個事務到底是提交了還是未提交,從而需要資料庫管理員的介入,防止資料庫進入乙個不一致的狀態。當然,如果有乙個前提是:所有節點或者網路的異常最終都會恢復,那麼這個問題就不存在了,協調者和參與者最終會重啟,其他節點也最終也會收到commit t的資訊。 

對於上面的困境,業界提出了三階段提交的方法來此問題,即將二階段提交的第二階段再分為待定階段(或預提交階段)和確定階段,從而變為三階段;在待定階段協調者log prepare_commit訊息後向所有參與者傳送prepare_commit訊息, 待收到所有參與者回包(這裡的回包結果只會成功)或超時時就進入第三段階,log commit訊息並向所有參與者傳送commit訊息。如果在待定階段和確定階段出現協調者和部分參與者同時宕機(即上面的困境),只要存活的協調者或參與者裡有prepare_commit或commit訊息,新的協調者可以繼續進行commit訊息,如果沒有,就不commit訊息,從而保證資料的一致性。

3 日誌 

資料庫日誌保證了事務執行的原子性和永續性,日誌型別可以分為redo log,undo log,undo/redo log。

4 總結 

二階段提交和三階段提交都是很好的分布式事務演算法,三階段提交是為解決二階段提交未解決的問題(協調者宕機,參與者也宕機)而提出來的。不過這兩種演算法都只考慮乙個協調者(主節點)的情況,沒有考慮多個協調者和如何選出協調者的問題。而另一種知名分布式事務演算法pasox能解決多個協調者的情況,並提出了多數派的概念。

分布式事務 二階段提交與三階段提交

一 二階段提交演算法描述 在分布式系統中,事務往往包含有多個參與者的活動,單個參與者上的活動是能夠保證原子性的,而多個參與者之間原子性的保證則需要通過兩階段提交來實現,兩階段提交是分布式事務實現的關鍵。很明顯,兩階段提交保證了分布式事務的原子性,這些子事務要麼都做,要麼都不做。而資料庫的一致性是由資...

分布式事務 二階段提交與三階段提交

一 二階段提交演算法描述 在分布式系統中,事務往往包含有多個參與者的活動,單個參與者上的活動是能夠保證原子性的,而多個參與者之間原子性的保證則需要通過兩階段提交來實現,兩階段提交是分布式事務實現的關鍵。很明顯,兩階段提交保證了分布式事務的原子性,這些子事務要麼都做,要麼都不做。而資料庫的一致性是由資...

分布式事務之二階段提交 三階段提交

分布式系統中的每個節點都能知道自己的事物是成功還是失敗,但是不知道其他節點的操作結果。要保證多個節點的事務性,就需要乙個中間者來協調這些機器,由中間者來決定事物的提交。2pc和3pc應運而生。過程如下 中間者向每個節點傳送事物請求 每個節點執行事物操作,將undo和redo記錄下來,並將自己的執行結...