一、典型的分散式事務例項
跨行轉賬問題是一個典型的分散式事務，使用者A向B的一個轉賬1000，要進行A的餘額-1000，B的餘額+1000，顯然必須保證這兩個操作的事務性。
類似的還有，電商系統中，當有使用者下單後，除了在訂單表插入記，還要在商品表更新庫存等，特別是隨著微服務架構的流行，分散式事務的場景更變得更普遍。
二、什麼是二階段提交協議？
二階段提交協議（2PC）通常用來保證資料的強一致性，二階段提交協議(2PC)中存在兩種型別的節點：協調節點和資料節點（或稱協調者與參與者），資料節點可以說是資料在多個節點的備份，協調節點使用者協調管理多個資料節點在事務操作中資料的一致性問題；
2PC（Two Phase Commit）協議通常分為兩個階段進行，提交請求階段（Commit Request Phase）或稱投票階段(Voting phase)、與提交階段（Commit Phase）；
1.提交請求階段（Commit Request Phase），協調者傳送請求給參與者，通知參與者提交或取消事務，參與者進入投票過程，每個參與者回覆給協調者自己的投票：同意（事務在本地執行成功）或取消（事務本地執行失敗）。
2.提交階段（Commit Phase），協調者對上一階段參與者的投票結果進行表決，當所有投票為“同意”時提交提交事務，否者中止事務，並通知參與者，參與者接到通知後執行相應的操作。
2PC（TWO Phase Commit）假定節點沒有崩潰、任意兩個節點的網路都是正常連通的、在寫日誌的過程中資料不會丟失的前提下。
三、兩階段提交協議互動構成描述
兩階段提交協議是協調所有分散式原子事務參與者，並決定提交或取消（回滾）的分散式演算法。
1.協議參與者
在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在資料儲存系統中可以理解為資料副本的個數。協議中假設每個節點都會記錄寫前日誌（write-ahead log）並永續性儲存，即使節點發生故障日誌也不會丟失。協議中同時假設節點不會發生永久性故障而且任意兩個節點都可以互相通訊。
2.兩個階段的執行
1.請求階段（commit-request phase，或稱表決階段，voting phase）
在請求階段，協調者將通知事務參與者準備提交或取消事務，然後進入表決過程。
在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
2.提交階段（commit phase）
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。
當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。
參與者在接收到協調者發來的訊息後將執行響應的操作。
（3）兩階段提交的缺點
1.同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。
當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
2.單點故障。由於協調者的重要性，一旦協調者發生故障。
參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者當機導致的參與者處於阻塞狀態的問題）
3.資料不一致。在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了區域性網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。
而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分散式系統便出現了資料部一致性的現象。
（4）兩階段提交無法解決的問題
當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。
考慮協調者再發出commit訊息之後當機，而唯一接收到這條訊息的參與者同時也當機了。
那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
