2PC、3PC
二階段提交協議（2PC）、三階段提交協議（3PC）都是為了解決分布式一致性問題。
??在分布式系統中為了保證事務處理的ACID特性，引入了協調者組件來同一調度所有分布式節點的執行邏輯，被調度的分布式節點稱為參與者，協調者負責調度參與者的行為，并決定這些參與者是否提交事務。
??
2PC
二階段提交協議將事務的提交過程分成兩個階段來處理：
第一個階段是提交事務請求：
- 首先協調者向所有參與者發送事務內容，詢問是否可以執行事務提交操作，并等待參與者的響應。
- 參與者執行事務操作，并將 undo 和 redo 信息記入事務日志中。
- 如果參與者成功執行了事務操作，就反饋給協調者 yes 響應，表示事務可以執行，否則反饋 no 響應，表示事務不可以執行。
第二個階段是執行事務提交：
-
協調者根據參與者的反饋情況來決定是否進行事務提交操作， 如果所有參與者反饋的都是 yes 響應，就會執行事務提交：
- 首先協調者向所有參與者發出 commit 請求。
- 參與者收到 commit 請求后，執行事務提交操作。
- 參與者完成事務提交后，釋放事務執行期間占用的資源，并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后，完成事務提交。
-
如果有一個參與者反饋的是 no 響應，或者等待超時后，協調者依然沒有接收到所有參與者的響應，就會中斷事務：
- 協調者向所有參與者發出回滾請求。
- 參與者收到回滾請求后，利用第一階段中記錄的 undo 信息來執行事務回滾操作。
- 參與者完成事務回滾后，釋放事務執行期間占用的資源，并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后，完成事務中斷。
優點：原理簡單，實現方便。
缺點：
3PC
3PC 是 2PC 的改進版，它將 2PC 的提交事務請求過程分為
第一個階段是 CanCommit：
- 協調者向所有參與者發送包含事務內容的 canCommit 請求，詢問是否可以執行事務提交操作，并等待參與者的響應。
- 參與者收到請求后，如果認為自己可以執行事務，就反饋 yes 響應，進入預備狀態，否則反饋 no 響應。
第二個階段是 PreCommit：
-
協調者根據參與者的反饋情況來決定是否進行事務的 PreCommit 操作，如果所有參與者反饋的都是 yes 響應，就會執行事務預提交：
- 協調者向所有參與者發出 PreCommit 請求，并進入準備階段。
- 參與者收到 PreCommit 請求后，會執行事務操作，并將 undo 和 redo 信息記錄到事務日志中。
- 參與者完成事務操作后，向協調者發送 ack 消息，并等待最終的指令：提交或中斷。
-
如果有一個參與者反饋的是 no 響應，或者等待超時后，協調者依然沒有接收到所有參與者的響應，就會中斷事務：
- 協調者向所有參與者發出中斷請求。
- 參與者收到中止請求或者超時后，都會中斷事務。
第三個階段是 doCommit：
-
該階段進行真正的事務提交，存在兩種情況，第一種情況是執行提交：
- 也就是協調者收到了所有參與者的 ack 響應，它從預提交狀態轉換為提交狀態，并向所有參與者發送 doCommit 請求。
- 參與者收到 doCommit 請求后，正式執行事務提交操作。
- 參與者完成事務提交后，釋放事務執行期間占用的資源，并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后，完成事務。
-
第二種情況是中斷事務，也就是如果有一個參與者反饋的是 no 響應，或者等待超時后協調者依然沒有接收到所有參與者的響應，就會中斷事務：
- 協調者向所有參與者發送中斷請求。
- 參與者收到中斷請求后，利用第二階段中記錄的 undo 信息來執行事務回滾操作。
- 參與者完成事務回滾后，釋放事務執行期間占用的資源，并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后，完成事務中斷。
優點：和 2PC 相比，3PC 最大的優點是降低了參與者的阻塞范圍，并且能夠在出現單點故障后繼續達成一致。
缺點：在參與者收到 PreCommit 消息后，如果網絡出現分區，協調者和參與者無法正常通信，而參與者依然會進行事務的提交，這會導致數據不一致。
總結
- 上一篇： 如何为BLE 设备实现OTA DFU 空
- 下一篇： HadoopYarn设置Fair Sch