事務和兩階段提交

事務是保證資料庫從乙個一致性的狀態永久地變成另外乙個一致性狀態的根本，其中，acid是事務的基本特性。

a是atomicity，原子性。乙個事務往往涉及到許多的子操作，原子性則保證這些子操作要麼都做，要麼都不做，而不至於出現事務的部分操作成功，而另外一部分操作沒有成功。如果事務在執行的過程中發生錯誤，那麼資料庫將回滾到事務發生之前的狀態。比如銀行的轉賬服務，這個事務的最終結果一定是：某個賬戶的餘額增加了x，而另外乙個賬戶的餘額減少了x，或者兩個賬戶的餘額未發生變化。而不會出現其他情況。

c是consistency，一致性。一致性是指事務發生前和發生以後，都不會破壞資料庫的約束關係，保證了資料庫元素的正確性、有效性和完整性。這種約束關係可以是資料庫內部的約束，比如資料庫元素的值必須在一定的範圍內，也可以是應用帶來的約束，比如轉賬以後銀行賬戶的餘額不能為負數。

i是isolation，隔離性。乙個事務的操作在未提交以前，是不會被並行發生的其他事務訪問到的。也就是說，資料庫操作不會看到某個事務的中間操作結果，比如轉賬過程中，使用者是不能查詢到乙個賬戶餘額減少了，而另外乙個賬戶餘額未發生變化的情況。

d是durability，永續性。事務完成以後，它對資料庫的影響是永久性的，即使在資料庫系統發生宕機或者其他故障的情況下，這種影響也會得到保持。

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

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

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

第一階段：

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

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

參與者能夠推遲傳送響應的時間，但最終還是需要傳送的。

第二階段：

協調者會收集所有參與者的意見，如果收到參與者發來的not commit t資訊，則標識著該事務不能提交，協調者會將abort t 記錄到日誌中，並向所有參與者傳送乙個abort t 資訊，讓所有參與者撤銷在自身上所有的預操作；

如果協調者收到所有參與者發來prepare t資訊，那麼協調者會將commit t日誌寫入磁碟，並向所有參與者傳送乙個commit t資訊，提交該事務。若協調者遲遲未收到某個參與者發來的資訊，則認為該參與者傳送了乙個vote_abort資訊，從而取消該事務的執行。

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

一般情況下，兩階段提交機制都能較好的執行，當在事務進行過程中，有參與者宕機時，他重啟以後，可以通過詢問其他參與者或者協調者，從而知道這個事務到底提交了沒有。當然，這一切的前提都是各個參與者在進行每一步操作時，都會事先寫入日誌。

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

資料庫日誌保證了事務執行的原子性和永續性，日誌型別可以分為redo log，undo log，undo/redo log。關於這幾種日誌形式的具體介紹，

事務和兩階段提交

事務和兩階段提交

兩階段提交事務

兩階段提交

相關推薦