背景
分散式事務，後端開發中比較常見啦。因為在面試的時候，總是有interviewers讓我給他普及一下分散式事務，雖然我會的也不多呀但是還是淺淺說一說；
今天心血來潮，好好地總結一下分散式事務，希望每一位後端工程師都能徹底理解分散式事務。
什麼是分散式事務?
答：既然是分散式，首先必然是分散式系統中的一個概念啦。單體應用沒這個東西，也不需要這個東西。本地事務就夠啦，Spring給我們提供的註解@Transactional, InnoDB引擎會為我們保證事務的ACID特性。但是分散式系統中，目前大多數網際網路公司都在用分散式系統，微服務架構等。所以，學好分散式事務太有必要。廢話不多說，直接上原理。
總結來說，分散式事務涉及了多個獨立的資料來源（資料庫）或者參與者的事務操作，這些資料來源分佈在不同的計算機或網路中；分散式事務確保在不同節點之間的多個操作要麼全部成功，要麼全部失敗。
分散式事務解決方案
2PC
兩階段提交協議，也叫XA協議。主要包含兩個階段，第一個階段是預備階段，第二個階段是提交階段。
2PC協議首先有分事務協調者角色和事務參與者。協調者是事先指定好的一個節點。參與者是一些涉及到資料庫操作的表，暫時可以這樣理解。這些多個參與者一般是分佈在不同的節點上。
- 準備階段。協調者向所有參與者傳送事務準備請求，參與者執事務操作，並回復協調者準備就緒的訊息；如果多個參與者中有一個參與者未準備就緒或者發生錯誤，那麼協調者會傳送中止請求。只有所有參與者都回復準備就緒，才會進入第二階段。
- 提交階段。所有參與者都已經準備就緒，協調者分別傳送提交的訊息，參與者收到訊息以後，執行事務的提交操作，並向協調者回復提交完成。
協調者收到了所有事務參與者提交完成的訊息後，整個分散式事務才算提交完成。如果有一個參與者未能提交或者發生錯誤，那麼協調者會向所有參與者傳送中止請求，進行事務的回滾操作。
如何評價2PC？
1、2PC有單點故障的問題。一旦事務協調者故障（因為是使用到了某個節點嘛），那麼整個事務將無法繼續進行，陷入故障。
2、資料不一致。如果協調者在傳送提交資訊時，只有部分參與者收到了訊息，並執行了提交，此時網路異常，就導致只有部分參與者執行了事物的提交，另一部分則沒有提交，從而造成一個資料不一致性。
3、阻塞風險。如果準備階段，有一個參與者無法響應或者失敗，那麼整個系統都會陷入阻塞狀態，等待超時處理。
4、效能問題。整個鏈路是序列的，響應時間較長，不適合高併發的場景。
3PC
三階段提交又稱3PC，相對於2PC來說增加了CanCommit階段和超時機制。如果某段時間內沒有收到協調者的commit請求，那麼就會自動進行commit，解決了2PC單點故障的問題。
但是效能問題和資料不一致性問題還是沒解決。3PC的步驟是這樣的：
1、詢問節點。CanCommit, 首先詢問參與者，是否有能力完成此次事務？
- 如果都返回yes，則進入第二階段
- 有一個返回no或等待響應超時，則中斷事務，並向所有參與者傳送abort請求。
2、準備階段；同2PC。需要注意的是，參與者收到訊息後開始執行事務操作，會首先將Undo和Redo資訊記錄到事務日誌中。參與者執行完事務操作後，向協調者反饋ACK, 表示已經準備好提交了。
3、提交階段。同2PC。