概述
在分佈式系統中，由於一個事務操作需要跨越多個分佈式節點，爲了保持事務處理的ACID特性，所以引入了協調者和參與者的概念。由協調者進行決策，參與者執行決策。並基於這種思想，衍生出2PC和3PC兩種提交協議。
2PC
2PC，是Two-Phase Commit的縮寫，即二階段提交，是分佈式一致性協議中的一種，用於保證分佈式系統中的數據一致性。顧名思義，2PC將整個事務的提交過程分爲了兩個階段進行操作。它們分別是：提交事務請求階段和執行事務提交階段
(階段一)提交事務請求階段
- 在上圖中，協調者先向各個參與者發出一個詢問請求，詢問各個參與者能否執行事務提交操作，並等待參與者的迴應
- 各個參與者收到詢問後，執行事務操作，並將Undo和Redo的信息記入事務日誌中
- 然後各個參與者根據自身情況向協調者反饋YES或者NO。YES表示事務可以執行；NO表示事務不能執行。
至此，2PC的階段一執行完畢，階段二會有兩種情況，我將分別敘述。
(階段二情況一)執行事務提交
進入該階段的前提是所有的參與者皆返回YES響應。否則進入中斷事務階段
- 所有參與者在做完事務操作之後，向協調者反饋YES。協調者收到所有參與者的YES響應之後，向所有的參與者發出去commit請求，即表示各個參與者可以提交事務了，請求發送之後，會繼續等待參與者的ACK反饋。
- 參與者收到 commit 請求後，開始提交事務，並在提交事務之後釋放自己在這整個過程中所佔有的資源。同時向協調者發送ACK反饋。
- 協調者收到所有參與者的ACK反饋後，整個事務完成。
(階段二情況二)中斷事務
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-JvtFNImp-1585147625908)(https://donkeyx.top/upload/2020/3/2pc-p2-2-83e2e53e4c404bfc8c59cd7fee411e4a.png)]
進入該階段的條件是有任意的參與者向協調者返回NO或者在等待過程中等待超時
- 如果有任意的參與者向協調者返回NO或者協調者等待超時(等待參與者響應)，那麼協調者會向所有的參與者發送Rollback請求。
- 參與者在收到Rollback請求後則會按照之前記錄在事務日誌中的Undo信息，執行事務回滾操作，然後釋放自己在這整個過程中所佔有的資源，同時向協調者發送ACK反饋。
- 協調者收到所有參與者的ACK反饋之後，整個中斷事務完成。
2PC總結
2PC就是簡單的把事務的處理過程分爲了投票和執行兩個階段，它的優點就是原理簡單，實現方便。但是它的缺點也很明顯。比如同步阻塞，單點問題，數據不一致，太過保守等問題。
同步阻塞 是因爲在整個分佈式事務的投票和執行階段，各個參與者會等待其他參與者的響應，而在這個過程中無法做其他事情。
單點問題是因爲整個分佈式事務的處理過程都是由協調者進行調控，如果協調者出現問題，那麼整個系統便會不可用。
數據不一致是因爲分佈式系統是通過網絡進行通信，如果在階段二，協調者發出了commit請求後，發生了局部網絡異常，或者協調者未發送完commit請求後就宕機了，就會出現部分節點執行了提交事務操作，部分節點未執行提交事務操作的情況，從而導致整個分佈式系統中的數據不一致的情況
太過保守是因爲在協調者和參與者 的通信過程中，如果參與者down機，協調者只會依靠超時機制來判斷是否需要中斷事務，而沒有其他方式。
3PC
3PC，即3階段提交。3PC在2PC的基礎上，將提交事務請求也就是第二階段分爲了2步，同時也爲參與者增加了超時機制，所以3PC也解決了一部分2PC的問題
（階段一）CanCommit階段
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-HWGRPsCT-1585147625910)(https://donkeyx.top/upload/2020/3/3PC-canCommit-ff8d14d847584efd9622273cd20f68ee.png)]
- 協調者向所有參與者發送一個包含事務內容的canCommit請求，詢問是否可以執行事務提交操作
- 參與者收到canCommit請求後，根據自身情況反饋YES或者NO
一階段也是一個簡單的投票過程，主要內容是後面兩個階段，都會分情況進行討論
（階段二情況一）preCommit階段
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-o9lLo5n2-1585147625912)(https://donkeyx.top/upload/2020/3/3PC-preCommit-1-9c1cc2b5e51c4265acee24c09ca9dd5c.png)]
如果所有的反饋都是YES，那麼將進入事務預提交階段。
- 協調者收到所有參與者的YES反饋後，向所有參與者發出preCommit請求，此時進入Prepared階段
- 參與者收到preCommit請求後，將Undo和Redo信息記錄到事務日誌中，然後向協調者反饋一個ACK請求，等待最終的指令
事務預提交階段，完成了事務操作，並等待提交事務或者中斷事務的指令
（階段二情況二）中斷事務
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-SAukeNN1-1585147625914)(https://donkeyx.top/upload/2020/3/3PC-preCommit-abort-1b4b44915590492abb9f02501f470807.png)]
如果有任意一個參與者反饋了NO或者協調者等待超時。那麼將進入中斷事務階段
- 協調者收到NO或者等待超時，向所有參與者發送abort請求
- 中斷事務，協調者不等待ACK響應
在該階段，協調者發送了abort請求後即意味着事務中斷，參與者即使沒有收到這個請求，也會在等待超時之後自行中斷事務。
（階段三情況一）doCommit階段
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-T9ZzDiVR-1585147625916)(https://donkeyx.top/upload/2020/3/3PC-doCommit-cf469e9bbead4b01bfb776877fb9f579.png)]
協調者在正常工作的前提下，並且收到了所有參與者的ACK響應，那麼將會狀態會從預提交轉換到提交狀態
- 協調者向所有參與者發送doCommit請求
- 參與者收到請求後，執行事務提交，完成後釋放自己所佔有的資源然後向協調者發送ACK消息
- 協調者收到所有參與者的ACK消息後，完成事務
這是 第三階段的正常完成情況
（階段三情況二）中斷事務
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ZtpAKZa9-1585147625918)(https://donkeyx.top/upload/2020/3/3PC-doCommit-abort-c532b021e5ba42df83af8d2f315261db.png)]
進入該階段的條件同preCommit的中斷事務一樣，只有協調者收到任何一個參與者的NO反饋或者等待超時後仍無法收到所有參與者的響應
這裏的NO反饋，指的是doCommit階段的NO反饋，意味着有參與者沒有完成事務提交。
- 協調者向所有參與者發送abort請求
- 參與者收到abort請求後，按照事務記錄日誌中的Undo信息執行事務回滾操作，回滾完成後釋放自己所佔有的資源，然後向協調者發送ACK消息
- 協調者收到了所有參與者的ACK消息後，中斷事務
進入了階段三，無論是協調者出現問題還是協調者與參與者之間出現網絡故障，參與者都會在等待超時之後自動進行事務提交
3PC 總結
3PC優點是降低了2PC的阻塞範圍，且避免了單點問題。