3PC是在2PC的基礎上進行改進的，爲了解決協2PC的同步阻塞，協調者單點，等容錯機制缺失問題而提出的。
一、概念
將原本2PC的第二個階段，即提交階段拆分爲兩個部分，形成了由CanCommit、PerCommit和DoCommit三個階段形成的事務處理協議。其協議涉及如下圖所示（圖上展示正常成功流程）：
階段一：CanCommit
1）事務詢問：事務協調者向各參與者發送包含事務內容的CanCommit請求，詢問是否可以提交事務。並開始等待各參與者響應。
2）參與者反饋事務詢問響應給協調者：各參與者收到協調者的CanCommit請求後，如果自身能夠執行事務則返回yes，否則返回no。
階段二：PerCommit
會有兩種情況：執行事務預提交和中斷事務
執行事務預提交：
1）發送預提交請求：協調者向各參與者發送預提交請求，並進入Prepared階段。
2）事務預提交：參與者接收到perCommit請求後，會執行實務操作，並記錄Undo log和Redo log。
3）各參與者向協調者反應事務執行的響應ack：如果參與者成功執行了事務操作，就會反饋給協調者ack，等待commit（提交）或者abort（中止）。
中斷事務：
如果任何一個事務參與者向協調者返回No，或者等待超時後，協調者無法接收到所有參與者的反饋響應，那麼就會事務中斷。
1）發送中斷請求：協調者向各參與者發送中斷請求。
2）中斷事務：無論參與者是否收到協調者的中止請求，在超時後仍然後會中斷事務。
階段三：DoCommit
存在兩種情況：提交事務和中斷事務
執行提交：
1）發送提交請求：協調者接收到所有參與者的ack響應，將會從預提交轉換爲提交狀態，並向所有參與者發送doCommit請求。
2）事務提交：參與者接收到doCommit請求後，會正式執行事務操作，最終提交事務釋放資源佔用。
3）反饋事務提交結果：參與者完成事務提交後向協調者發送ack響應。
4）完成事務：協調者收到所有參與者反饋的ack後，完成事務。
中斷事務：
如果任何一個事務參與者向協調者返回No，或者等待超時後，協調者無法接收到所有參與者的反饋響應，那麼就會事務中斷。
1）發送中斷請求：協調者向所有參與者發送abort請求。
2）事務回滾：參與者接收到abort請求後，使用Undo log進行回滾操作，回滾後釋放佔用資源。
3）反饋事務回滾結果：所有參與者在完成回滾後，向協調者發送ack。
4）中斷事務：協調者接收到所有參與者反饋的ack，中斷事務。
注意：一旦所有參與者完成二階段準備提交，當進入第三階段後，協調者出現故障，或參與者與協調者出現網絡問題，在超時後，參與者都會進行事務提交。
二、優缺點
優點：相比於二階段提交，增加了perCommit的緩衝，三階段提交降低了參與者的阻塞範圍，能夠在出現單點故障後繼續達成一致。
缺點：如果進入PreCommit後，協調者發出的是abort請求，假設只有一個參與者收到並進行了abort操作，而其他對於系統狀態未知的參與者會根據3PC選擇繼續Commit，此時系統狀態發生不一致性。