分佈式事務 & 兩階段提交 & 三階段提交

能夠參考這篇文章：

http://blog.csdn.net/whycold/article/details/47702133

 

兩階段提交保證了分佈式事務的原子性，這些子事務要麼都作，要麼都不作。

而數據庫的一致性是由數據庫的完整性約束實現的，持久性則是經過commit日誌來實現的，不是由兩階段提交來保證的。

 

兩階段提交的過程涉及到協調者和參與者。協調者能夠看作成事務的發起者，同時也是事務的一個參與者。

第一階段：

prepare

第二階段：

若是有人不prepare，或者無響應，就取消；若是全都贊成，那麼協調者會將Commit T日誌寫入磁盤，並向全部參與者發送一個Commit T信息，提交該事務。

 

2、可能出現的問題 
　　通常狀況下，兩階段提交機制都能較好的運行，但可能出現下面三種問題： 
　　（1）協調者不宕機，參與者宕機； 
　　（2）協調者宕機，參與者不宕機； 
　　（3）協調者宕機，參與者（能夠是部分）也宕機； 

 

對於（1）當在事務進行過程當中，有參與者宕機時，他重啓之後，能夠經過詢問其餘參與者或者協調者，從而知道這個事務到底提交了沒有。固然，這一切的前提都是各個參與者在進行每一步操做時，都會事先寫入日誌。 （能解決）

對於（2）協調者宕機後，能夠起新的協調者，而後查詢全部參與者的狀態是否有commit的，若是有，則繼續commit，若是都沒有，則abort。 （能解決）

對於（3）包含了惟一一個兩階段提交不能解決的困境：當協調者在發出commit T消息後宕機了，而惟一收到這條命令的一個參與者也宕機了。（這個時候這個事務就處於一個未知的狀態，沒有人知道這個事務究竟是提交了仍是未提交，從而須要數據庫管理員的介入，防止數據庫進入一個不一致的狀態）

 

對於上面的困境，業界提出了三階段提交的方法來此問題。

將二階段提交的第二階段再分爲待定階段（或預提交階段）和肯定階段，從而變爲三階段；

在待定階段協調者log　prepare_commit消息後向全部參與者發送prepare_commit消息, 待收到全部參與者回包（這裏的回包結果只會成功）或超時時就進入第三段階，log commit消息並向全部參與者發送commit消息。

若是在待定階段和肯定階段出現協調者和部分參與者同時宕機（即上面的困境），只要存活的協調者或參與者裏有prepare_commit或commit消息，新的協調者能夠繼續進行commit消息，若是沒有，就不commit消息，從而保證數據的一致性。

 

3 日誌 
數據庫日誌保證了事務執行的原子性和持久性。

 

４ 總結 
二階段提交和三階段提交都是很好的分佈式事務算法，三階段提交是爲解決二階段提交未解決的問題（協調者宕機，參與者也宕機）而提出來的。

不過這兩種算法都只考慮一個協調者（主節點）的狀況，沒有考慮多個協調者和如何選出協調者的問題。而另外一種知名分佈式事務算法pasox能解決多個協調者的狀況，並提出了多數派的概念。

（我博客裏面有好幾篇Paxos相關的文章）

 

（完）