通俗定義：如果一個事務調用了不同服務器上的操作，那麽它就成為了一個分布式事務。

考慮下面一種場景：當你發了工資之後，把你的當月工資￥1024從支付寶轉到了余額寶。

如果在支付寶賬戶扣除￥1024之後，余額寶系統掛掉了，余額寶的賬戶並沒有增加￥1024，這時候就出現了數據不一致的情況。

在一個分布式事務結束的時候，事務的原子特性要求所有參與該事務的服務器必須全部提交或全部放棄該事務。為了實現這一點，其中一個服務器承擔了協調者(coordinater)的角色，由它來保證所有的服務器獲得相同的結果。

協調者的工作方式取決於它選用的協議，“兩階段提交”市分布式事務中最常用的協議。

1、兩階段提交協議

兩階段提交協議(two-phase commit protocol)的設計出發點是允許任何一個參與者自行放棄它自己的那部分事務。由於事務原子性的要求，如果部分事務被放棄，那麽整個分布式事務也必須被放棄。

在該協議的第一個階段，每個參與者投票表決該事務是放棄還是提交，一旦參與者要求提交事務，那麽就不允許放棄該事務。因此，在一個參與者要求提交事務之前，它必須保證最終能夠執行分布式事務中自己的那部分，即使該參與者出現故障而被中途替換掉。

一個事務的參與者如果最終能提交事務，那麽可以說參與者處於事務的準備好(prepared)狀態。為了保證能夠提交，每個參與者必須將事務中所有發生改變的對象以及自身的狀態(prepared)保存到持久性存儲中。

在該協議的第二個階段，事務的每個參與者執行最終統一的決定。如果任何一個參與者投票放棄事務，那麽最終的決定是放棄事務。如果所有的參與者都投票提交事務，那麽最終的決定是提交事務。

問題在於，要保證每個參與者都投票，並且達成一個共同的決定。在無故障時，該協議相當簡單。但是，協議必須在出現各種故障(例如服務器崩潰，消息丟失或服務暫時無法通信）時能夠正常工作。

2、兩階段提交的實現

為了實現兩階段提交協議，分布式事務中的協調者和參與者通常按照下面的接口進行通信：

• canCommit(trans)

協調者詢問參與者是否可以提交事務，參與者回復自己的投票結果。

• doCommit(trans)

協調者告訴參與者提交它的那部分事務。

• doAbort(trans)

協調者告訴參與者放棄它的那部分事務。

• haveCommitted(trans, participant)

參與者用該操作向協調者確認它提交了事務。

• getDecision(trans) ?

當參與者在投Yes票後一段時間內未收到應答時，參與者用該操作向協調者詢問事務的投票表決結果。該操作用於從服務器崩潰或從消息延遲中恢復。

執行流程：

階段一（投票階段）：

1）協調者向分布式事務的所有參與者發送cancommit？請求

2）當參與者收到cancommit請求後，它向協調者回復自己的投票（Yes/No）

在投yes前，它在持久性存儲中保存所有對象，準備提交。如果投No，參與者立即放棄。

階段二（提交階段）：

1）協調者收集所有的投票（包括它自己的投票）。

　　a）如果不存在故障並且所有的投票都是yes時，那麽協調者將決定提交事務並向所有的參與者發送docommit

　　b）否則，協調者將決定放棄該事務，並向所有投Yes票的參與者發送doAbort請求

2）投Yes票的等待者等待協調者發送的docommit請求或則doAbort請求。參與者收到消息則根據消息作出相應反應，如果是提交事務，則還要向協調者發送一個haveCommited來確認事務已經提交。

3、分布式事務的故障模型

在分布式事務中執行的過程中，可能出現磁盤故障，進程崩潰以及消息的丟失，超時等。

兩階段提交是一種達成共識的協議，在該系統中，如果進程崩潰，那麽是不可能達成共識的。但是，兩階段提交卻是在這些條件下達成了共識，這是由於進程的崩潰被屏蔽，崩潰的進程被一個新的進程取代，新進程的狀態根據持久性存儲中保存的信息和其他進程擁有的信息來設定。

3.1、故障模型

Lampson提出過一個分布式事務的故障模型，包括了硬盤故障、服務器故障以及通信故障。該故障模型聲稱：可以保證算法在出現故障時正確工作，但是對於不可預見的災難性故障則不能正確處理。盡管會出現錯誤，但是可以在發生不正確行為之前發現並處理這些錯誤。Lampson的故障模型包括以下故障：

• 對持久性存儲的寫操作可能發生故障（或因為寫操作無效或因為寫入錯誤的值）。例如，將數據寫到錯誤的磁盤塊被認為是災難性故障。文件存儲可能損壞。在持久性存儲中讀數據時可根據校驗和來判斷數據塊是否損壞。

• 服務器可能偶爾崩潰。當一個崩潰的服務器由一個新進程取代後，它的可變內存被重置，崩潰之前的數據均丟失。此後新進程執行一個可恢復過程，根據持久存儲中的信息以及從其他進程獲得的信息設置對象的值，包括兩階段提交協議有關對象的值。當一個處理器出現故障時，服務器也會崩潰，這樣它就不會發送錯誤的信息或將錯誤的值寫入持久存儲，即它不會產生隨機故障。服務器崩潰可能出現在任何時候，特別是在恢復時也可能出現。

• 消息傳遞可能有任意長的延遲。消息可能丟失、重復或者損壞。接收方（通過校驗和）能夠檢測到受損消息。未發現的受損消息和偽造的消息可能會導致災難性故障。

利用這個關於持久性存儲、處理器和通信的故障模型能夠設計出一個可靠系統，該系統的組件可對付任何單一故障，並提供一個簡單的故障模型。特別是，可靠存儲(stable storage)可以在出現一個write操作故障或者進程崩潰的情況下提供原子寫操作。它是通過將每一個數據塊復制到兩個磁盤上實現的。此時一個write操作用於兩個磁盤塊，在一個磁盤出現故障的前提下，另一個好的磁盤也可以提供正確數據。可靠處理器(stable processor)使用可靠存儲，用於在崩潰之後恢復對象。可通過可靠的遠程過程調用機制來屏蔽通信錯誤。

3.2、兩階段提交協議的超時

在兩階段協議的不同階段，協調者或參與者都會遇到這種場景：不能處理它的那部分協議，直到接收到下一個請求或應答為止。

首先考慮這樣的情形：某個投票者投Yes票並等待協調者發回最終決定，即告訴它是提交事務還是放棄事務。這樣參與者的結果是不確定(uncertain)的，它在協調者處得到投票結果之前不能進行進一步處理。參與者不能單方面決定下一步做什麽，同時該事務使用的對象也不能釋放以用於其他事物。參與者向協調者發出getDecision請求來獲取事務的結果，直到收到應答時，才能進入兩階段協議的第二階段。

同理，如果協調者發生故障，那麽參與者將不能獲得協定，直到協調者被替代為止，這可能導致不確定狀態的參與者長時間的延遲。

不依賴協調者獲取最終決定的方法是通過參與者協作來獲得決定。這種策略的優點是可以在協調者出故障時使用。

4、兩階段提交的缺點

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

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

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

5、兩階段提交的性能

假設一切運轉正常，即協調者參與者不出現故障，通信也正常時，有N個參與者的兩階段提交協議需要N個canCommit消息和應答，然後再有N個doCommit消息。這樣消息開銷和3N成正比，時間開銷是3次消息往返。由於協議在沒有haveCommitted消息時仍可以正常運作（它們的作用只是通知服務器刪除過時的協調者消息），因此在估計協議開銷上，不將haveCommitted消息計算在內。

在最壞的情況下，兩階段提交協議在執行過程中可能出現任意多次服務器和通信故障。盡管協議不能指定協議完成的時間限制，但它能正確處理連續故障（服務崩潰或者消息丟失），並保證最終完成。

6、使用消息隊列來避免分布式事務

6.1、消息隊列

由於分布式事務存在嚴重的性能問題，在設計高並發服務的時候，往往通過其他途徑來解決數據一致性問題。

舉例來講，你在北京很有名的姚記炒肝點了炒肝並付了錢後，他們並不會直接把你點的炒肝給你，而是給你一張小票，然後讓你拿著小票到出貨區排隊去取。為什麽他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強（並發量更高）。

還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉賬服務也是如此，當支付寶賬戶扣除1萬後，我們只要生成一個憑證（消息）即可，這個憑證（消息）上寫著“讓余額寶賬戶增加 1萬”，只要這個憑證（消息）能可靠保存，我們最終是可以拿著這個憑證（消息）讓余額寶賬戶增加1萬的，即我們能依靠這個憑證（消息）完成最終一致性。

這樣我們上述的轉賬就變成了如下過程：

• 支付寶在扣款事務提交之前，向消息隊列發送消息。此時的消息隊列只記錄消息，而並沒有將消息發往余額寶。

• 當支付寶扣款事務提交成功，向消息隊列發送確認。在得到確認的指令後，消息隊列向該消息發往余額寶。

• 當支付寶扣款事務提交失敗，向消息隊列發送取消。在得到取消的指令後，消息隊列取消該消息，該消息將不會被發送。

• 對於那麽未確認的消息，需要消息隊列去支付寶系統查詢這個消息的狀態，並進行更新。（因為支付寶可能在扣款事務提交成功後掛掉，此時消息的狀態未被更新為：“確認發送“。從而導致消息不能被發送。

深入理解分布式事務