分散式當中常常面臨一個問題，就是如何保證事物。 在單體服務當中，如果服務執行失敗自動回滾。而在分散式當中，因為兩個模組是不同的程序，相互是不影響的。那麼在這種情況下如何保證資料的一致性那。
2PC提交協議恰恰可以解決這個問題，
在分散式系統中，為了讓每個節點都能夠感知到其他節點的事務執行狀況，需要引入一箇中心節點來統一處理所有節點的執行邏輯，這個中心節點叫做協調者（coordinator），被中心節點排程的其他業務節點叫做參與者（participant）。
簡單的來說相當於過去需要人工轉接的打電話，中間需要一個人來協調呼叫者和被呼叫者之間的聯絡。
兩階段提交的缺點：
1。同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。
當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
2。單點故障。由於協調者的重要性，一旦協調者發生故障。
參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處於阻塞狀態的問題）
3。資料不一致。在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了局部網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。
而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分散式系統便出現了資料不一致性的現象。
兩階段提交無法解決的問題：
當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。
考慮協調者在發出commit訊息之後宕機，而唯一接收到這條訊息的參與者同時也宕機了。
那麼即使協調者透過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
