原創轉載請注明出處：https://www.cnblogs.com/agilestyle/p/11623047.html
TCC的優缺點
優點
解決了跨服務的業務操作原子性問題，例如組合支付、下訂單減庫存等場景非常實用
TCC的本質原理是把數據庫的二階段提交上升到微服務來實現，從而避免數據庫二階段中鎖沖突的長事務引起的低性能風險
TCC異步高性能，它采用了try先檢查，然后異步實現confirm，真正提交是在confirm方法中
缺點
對微服務的侵入性強，微服務的每個事務都必須實現try、confirm、cancel等3個方法，開發成本高，今后維護改造的成本也高
為了達到事務的一致性要求，try、confirm、cancel接口必須實現冪等性操作
由於事務管理器要記錄事務日志，必定會損耗一定的性能，並使得整個TCC事務時間拉長，建議采用Redis的方式來記錄事務日志
TCC與XA 2PC區別
XA協議是由X/Open組織提出的一個分布式事務處理規范，目前MySQL中只有InnoDB存儲引擎支持XA協議。
在XA規范之前，存在着一個DTP模型，該模型規范了分布式事務的模型設計。
DTP規范中主要包含了AP、RM、TM三個部分，其中AP是應用程序，是事務發起和結束的地方；RM是資源管理器，主要負責管理每個數據庫的連接數據源；TM是事務管理器，負責事務的全局管理，包括事務的生命周期管理和資源的分配協調等。
XA則規范了TM與RM之間的通信接口，在TM與多個RM之間形成一個雙向通信橋梁，從而在多個數據庫資源下保證ACID四個特性。
- XA是數據庫的分布式事務，強一致性，在整個過程中，數據一張鎖住狀態，即從prepare到commit、rollback的整個過程中，TM一直把持折數據庫的鎖，如果有其他人要修改數據庫的該條數據，就必須等待鎖的釋放，存在長事務風險。
- TCC是業務的分布式事務，最終一致性，不會出現長事務的鎖風險，try是本地事務，鎖定資源后就提交事務，confirm／cancel也是本地事務，可以直接提交事務，所以多個短事務不會出現長事務的風險。
TCC與DTP區別
TCC模型的發起方類似於DTP模型的AP，TCC模型的接收方類似於DTP模型的RM
TCC模型中發起方（比如訂單服務）調用接收方（比如庫存服務，賬戶服務，積分服務），而DTP模型是由AP應用操作多個RM數據庫
兩者都實現了2PC
TCC模型：第一階段由發起方（訂單服務）發出try請求，第二階段由事務管理器發起confirm／cancel請求，而且采用了異步實現
DTP模型：RM（數據庫）提供了prepare／commit／rollback接口，兩階段都是由TM調用
Reference
https://time.geekbang.org/column/article/127527