2pc也叫2段式事務
3pc也叫3 段式事務
網上資料一大堆，基本都沒說清楚區別在哪里。
先說 2 段式 ：
第一階段: 就是 執行 sql ，但是 沒有提交，並且 各自執行到 可以提交（事務沒提交）的 時候，會告訴 協調者 ，自己已經可以提交了。
第二階段：如果全部的本地事務都 告訴寫條者 以后，如果全都 都可以提交，那么就執行提交，如果有一個不 能提交，那就全部回滾。
問題：
同步阻塞：第一階段第二階段 是同一個事務，提交之前都鎖定資源，而且還要等待別人 一起提交， 鎖定的比較久，但是這個 問題 3階段也會有。不依賴 3pc 也會有事務的超時回滾時間。
單點故障：指的是 單協調節點故障，所有分布式事務都沒辦法提交了。（ 我覺得也不存在， 大不了吧 協調者上做個高可用（ 比如 LCN 事務的 TM ） ）
2pc：只有一次投票，就是在提交之前，這次投票結果如果 是 全通過，那么久通知每一個事務 提交，通知 事務提交的這個過程，可能有的事務節點沒收到。然后他就阻塞，等到超時，然后回滾，數據就不一致了。
3pc：
3pc 使用超時機制( 值得一提的是 數據庫事務貝萊就有超時機制 )，並且 吧2pc 的 第一個階段分成了2 個（也可以理解成 commit 分成了2 次確認）。
3pc: 有2 次投票
第一次：can 階段，如果 投票權通過，會 通知 所有節點進入 pre 階段，同理通知的過程可能會失敗，部分通知成功，部分失敗， 然后 pre 階段不會提交的 。沒收到通知的 超時以后回滾（這個超不是數據庫的超時，是3pc 的超時機制）。
協調者沒有收到所有的相應（沒收到消息的那個肯定沒有相應了） ，那么 協調者 再次通知所有的 取消。一起回滾，數據一致。如果都不出問題。都正常相應 pre完成。
第二次：上面 都都相應以后，如果都是 yes ，那么久進入 commit 階段。如果部分失敗，那么 依舊 通知所有節點事務回滾。
commit階段：能有協調者收到 都是 yes，注意，這時候只有協調至知道應該commit，別的節點都處於告訴 協調者 pre階段 自己同意了（ 類似2pc 的 commit的通知 分成2 次確認，理解為已經收到一次了， ），如果在收到 第二次，那立即提交。
重點來了，如果 第二次確認收不到，但是收到過一次 pre 的確認，第二次因為網絡或者協調者 通知了部分節點，自己掛了，那么超時 以后也會提交。
在說活 preCommit 階段敢了啥 ？
其實它啥都沒干，有些文章說這個謝了 undo 和 redo 日志。這個 其實 寫哪里無所無，如果寫在 canCommit 我覺得更好，pre 階段應該盡快完成，盡量少做事情，只做簡單的2 次確認。2 次確認 我們認為是這正常的 提交， 一次確認 ，后 立即commit 給了回滾的余地 ，一次確認后如果超時然就自己提交而不是回滾，是從大概率上來說 保證數據的一致性。
分析：2pc 第一階段以后---> 協調者收集 結果 ————》通知提交 ，在 通知提交的時候 可能 部分 沒有通知到，部分提交了，導致數據不一致
3pc 第階段----》協調者收集結果--->通知進入 pre------> 協調者收集結果------ > 通知提交 多了一次pre 在pre階段可以回滾機會，並且在如果 通知 commit 階段 部分 沒有收到，也會 在超時也厚自己提交。 但是 超時自己提交也有問題，這時候 可能 協調者想發出的 是 取消事務的 通知。（ pre 階段 殺都沒做，只是一個 預確認的過程，一般不會所以可以認為 基本不會 取消 ）。 能出問題 只有一種情況 pre 取消，並且 commit 的時候 節點有超時。 這樣算下來 概率 就比 commit 超時的概率小很多了。 這就是 3pc 解決的問題。
不管是 2pc 還是 3pc 都不能保證 100% 的 數據一致性。 2pc 要求協調者通知 commit 階段 不會出問題。 3cp 要求 pre 取消的時候，協調者通知 commit 不會出問題。 2pc 和 3pc 都是一個事務鎖定指定等提交。 鎖定時間都長。 性能比較低。要求效率比較高的時候，都有一定限制。
和 TCC 事務相比，TCC 也是2 段式提交，但是 2 段 都2 個事務，3 個方法，效率比 2pc 和 3pc 高，TCC 也有自己的缺點，一個操作要寫3 個方法。 2pc ，3pc 寫起來就容易很多。
TX-lcn 的lcn 模式 其實就是 2pc 的 一個變種 ， TX-lcn 的 TM 就是 協調者，並且 TM 支持 高可用，然后 如果 吧 協調信息寫到 一個 TM共享的地方。 就能應對 協調者的單點故障了。
TCC 也不能100% 保證 數據一致性，TCC 要求 才 try 的階段 凍結，預留資源然后提交事務，cancel 階段 冪等的處理 預留凍結資源的回滾，comform 階段 也要冪等，並且因為 前面 已經預留了資源，所以不做資源檢查 （ 檢查了也沒用，如果檢查了資源 不夠，說明 try 寫的有問題，是邏輯問題拋出異常 也沒用 ），並且 理想的 認為 comform 只會執行成功。不會失敗。 雖然有補償機制（ 如果 comform 保存，通過 切面日志 參數 重做一次 comform ），但是如果是 try 寫錯了，資源沒留夠重試 100 次都沒用，如果是 網絡，搶鎖啥 的， 可以重試的時候完成。
所以TCC 一致性的 保證是 ，comform 不拋出異常，並且正常執行（ 理論上 留了 資源 就應該正常執行 邏輯錯誤帶了 的數據不一致，任何一致性框架都解決不了， 比如 傳統事務 張三 減100 ，李四你加了 200，邏輯寫錯了不是框架能決定的 ）。