2pc和3pc區別
3pc背景：
2pc協議在協調者和執行者同時宕機時(協調者和執行者不同時宕機時，都能確定事務狀態)，選出協調者之后 無法確定事務狀態，會等待宕機者恢復才會繼續執行(無法利用定時器來做超時處理，超時后也不知道事務狀態，無法處理，強制處理會導致數據不一致)，這段時間這個事務是阻塞的，其占用的資源不會被釋放。為了解決這個問題，產生了3PC協議。
原理：
3PC增加了一個中間狀態，方便判斷事務狀態，新的協調者不用等宕機者恢復 就能決定事務狀態，准確的提交事務或者終止事務。
1.CanCommit(能否提交)
2.PreCommit（預提交）
進入這個狀態，說明各執行節點的狀態都是canCommit
3.doCommit（預提交）
進入這個狀態，說明個執行節點的狀態都是precommit
新協調者如果發現有的存活節點的狀態是preCommit或doCommit，說明各執行節點的狀態肯定都是"可以提交"，協調者直接提交事務，能保證數據一致性 。
如果發現有的存活節點狀態是abort狀態,說明事務被中斷了，協調者繼續中斷事務就行。
如果發現所有節點都是canCommit，說明各執行節點不會有處於doCommit狀態(因為如果有節點是canCommit，不會有節點是canCommit狀態)，協調者中斷事務，能保證數據一致性。
結論：
3pc解決了事務狀態不可知的問題。不過其對執行者引入超時機制(超時后根據執行器當前狀態canCommit or preCommit回滾或者提交事務，釋放事務占用的資源)，如果發生網絡分區，會導致事務數據不一致，雖然提升了系統可用性，不過犧牲了系統一致性，執行者超時這個設計不好。
2pc 3pc歸根到底是選擇系統可用性還是選擇系統一致性（CAP理論中的抉擇問題）
2pc 一致性好、可用性較低，3pc 一致性較低、可用性高