經常在網路上看見有人介紹TCC時，都提一句，”TCC是兩階段提交的一種”。其理由是TCC將業務邏輯分成try、confirm/cancel在兩個不同的階段中執行。其實這個說法，是不正確的。可能是因為既不太瞭解兩階段提交機制、也不太瞭解TCC機制的緣故，於是將兩階段提交機制的prepare、commit兩個事務提交階段和TCC機制的try、confirm/cancel兩個業務執行階段互相混淆，才有了這種說法。
兩階段提交（Two Phase Commit，下文簡稱2PC），簡單的說，是將事務的提交操作分成了prepare、commit兩個階段。其事務處理方式為：
1、 在全域性事務決定提交時，a）逐個向RM傳送prepare請求；b）若所有RM都返回OK，則逐個傳送commit請求最終提交事務；否則，逐個傳送rollback請求來回滾事務；
2、 在全域性事務決定回滾時，直接逐個傳送rollback請求即可，不必分階段。
* 需要注意的是：2PC機制需要RM提供底層支援（一般是相容XA），而TCC機制則不需要。
TCC（Try-Confirm-Cancel），則是將業務邏輯分成try、confirm/cancel兩個階段執行，具體介紹見TCC事務機制簡介。其事務處理方式為：
1、 在全域性事務決定提交時，呼叫與try業務邏輯相對應的confirm業務邏輯；
2、 在全域性事務決定回滾時，呼叫與try業務邏輯相對應的cancel業務邏輯。
可見，TCC在事務處理方式上，是很簡單的：要麼呼叫confirm業務邏輯，要麼呼叫cancel邏輯。這裡為什麼沒有提到try業務邏輯呢？因為try邏輯與全域性事務處理無關。
當討論2PC時，我們只專注於事務處理階段，因而只討論prepare和commit，所以，可能很多人都忘了，使用2PC事務管理機制時也是有業務邏輯階段的。正是因為業務邏輯的執行，發起了全域性事務，這才有其後的事務處理階段。實際上，使用2PC機制時————以提交為例————一個完整的事務生命週期是：begin -> 業務邏輯 -> prepare -> commit。
再看TCC，也不外乎如此。我們要發起全域性事務，同樣也必須透過執行一段業務邏輯來實現。該業務邏輯一來透過執行觸發TCC全域性事務的建立；二來也需要執行部分資料寫操作；此外，還要透過執行來向TCC全域性事務註冊自己，以便後續TCC全域性事務commit/rollback時回撥其相應的confirm/cancel業務邏輯。所以，使用TCC機制時————以提交為例————一個完整的事務生命週期是：begin -> 業務邏輯(try業務) -> commit(comfirm業務)。
綜上，我們可以從執行的階段上將二者一一對應起來：
1、 2PC機制的業務階段 等價於 TCC機制的try業務階段；
2、 2PC機制的提交階段（prepare & commit） 等價於 TCC機制的提交階段（confirm）；
3、 2PC機制的回滾階段（rollback） 等價於 TCC機制的回滾階段（cancel）。
因此，可以看出，雖然TCC機制中有兩個階段都存在業務邏輯的執行，但其中try業務階段其實是與全域性事務處理無關的。認清了這一點，當我們再比較TCC和2PC時，就會很容易地發現，TCC不是兩階段提交，而只是它對事務的提交/回滾是透過執行一段confirm/cancel業務邏輯來實現，僅此而已。
經常在網路上看見有人介紹TCC時，都提一句，”TCC是兩階段提交的一種”。其理由是TCC將業務邏輯分成try、confirm/cancel在兩個不同的階段中執行。其實這個說法，是不正確的。可能是因為既不太瞭解兩階段提交機制、也不太瞭解TCC機制的緣故，於是將兩階段提交機制的prepare、commit兩個事務提交階段和TCC機制的try、confirm/cancel兩個業務執行階段互相混淆，才有了這種說法。
兩階段提交（Two Phase Commit，下文簡稱2PC），簡單的說，是將事務的提交操作分成了prepare、commit兩個階段。其事務處理方式為：
1、 在全域性事務決定提交時，a）逐個向RM傳送prepare請求；b）若所有RM都返回OK，則逐個傳送commit請求最終提交事務；否則，逐個傳送rollback請求來回滾事務；
2、 在全域性事務決定回滾時，直接逐個傳送rollback請求即可，不必分階段。
* 需要注意的是：2PC機制需要RM提供底層支援（一般是相容XA），而TCC機制則不需要。
TCC（Try-Confirm-Cancel），則是將業務邏輯分成try、confirm/cancel兩個階段執行，具體介紹見TCC事務機制簡介。其事務處理方式為：
1、 在全域性事務決定提交時，呼叫與try業務邏輯相對應的confirm業務邏輯；
2、 在全域性事務決定回滾時，呼叫與try業務邏輯相對應的cancel業務邏輯。
可見，TCC在事務處理方式上，是很簡單的：要麼呼叫confirm業務邏輯，要麼呼叫cancel邏輯。這裡為什麼沒有提到try業務邏輯呢？因為try邏輯與全域性事務處理無關。
當討論2PC時，我們只專注於事務處理階段，因而只討論prepare和commit，所以，可能很多人都忘了，使用2PC事務管理機制時也是有業務邏輯階段的。正是因為業務邏輯的執行，發起了全域性事務，這才有其後的事務處理階段。實際上，使用2PC機制時————以提交為例————一個完整的事務生命週期是：begin -> 業務邏輯 -> prepare -> commit。
再看TCC，也不外乎如此。我們要發起全域性事務，同樣也必須透過執行一段業務邏輯來實現。該業務邏輯一來透過執行觸發TCC全域性事務的建立；二來也需要執行部分資料寫操作；此外，還要透過執行來向TCC全域性事務註冊自己，以便後續TCC全域性事務commit/rollback時回撥其相應的confirm/cancel業務邏輯。所以，使用TCC機制時————以提交為例————一個完整的事務生命週期是：begin -> 業務邏輯(try業務) -> commit(comfirm業務)。
綜上，我們可以從執行的階段上將二者一一對應起來：
1、 2PC機制的業務階段 等價於 TCC機制的try業務階段；
2、 2PC機制的提交階段（prepare & commit） 等價於 TCC機制的提交階段（confirm）；
3、 2PC機制的回滾階段（rollback） 等價於 TCC機制的回滾階段（cancel）。
因此，可以看出，雖然TCC機制中有兩個階段都存在業務邏輯的執行，但其中try業務階段其實是與全域性事務處理無關的。認清了這一點，當我們再比較TCC和2PC時，就會很容易地發現，TCC不是兩階段提交，而只是它對事務的提交/回滾是透過執行一段confirm/cancel業務邏輯來實現，僅此而已。