tcc是支付寶提出的分布式事務解決方案，是 try、confirm、cancel 的縮寫。
與2pc二階段提交機制類似，區別在於層面不同，2pc是在資料庫層面解決資料庫之間的分布式事務，tcc是在應用層面解決分布式系統中的分布式事務。
每個分布式事務的參與者都需要實現3個介面：try、confirm、cancel(confirm 對應2pc的事務提交，cancel 對應2pc的事務回滾)。例如乙個轉賬業務，服務a負責扣錢、服務b負責加錢，a、b都要實現這3個介面。
tcc 分為2個階段：
準備階段
呼叫方呼叫各個服務的 try 介面，各個服務執行資源檢查和鎖定，看自己是否有能力完成，如果允許，則鎖定資源。
提交階段
如果各個服務的 try 介面都返回了 yes，則進入提交階段，呼叫方呼叫各個服務的 confirm 介面，各個服務對 try 階段鎖定的資源進行處理。
如果 try 階段有一方返回了 no，或者超時，呼叫方呼叫各個服務的 cancel 介面，釋放鎖定的資源。
對於異常情況，處理方法是不斷重試，不管 confirm 失敗了，還是 cancel 失敗了，都不斷重試。
以轉賬為例，有2個服務，扣錢服務、加錢服務，都各自實現 try、confirm、cancel 介面。
現在賬號 a 要給賬號 b 轉 30 元。
呼叫者呼叫2個服務的 try 介面。
扣錢服務的try介面中對 a 的餘額進行驗證，如果可用餘額不少於30元，則凍結30元，返回 yes，否則返回 no。
加錢服務的try介面對 b 賬號進行驗證，例如是否合法可用，是則返回 yes，否則返回 no。
這個階段保證了扣錢可扣、加錢可加。
try 介面如果都返回了 yes，呼叫者呼叫2個服務的 confirm 介面。
扣錢服務實際扣減a的30元，加錢服務實際給b加30元。
try 介面如果有返回 no 或者超時的，呼叫者呼叫2個服務的 cancel 介面。
扣錢服務解凍a的30元，加錢服務什麼也不用做。
下面幾個是典型的異常情況：
現象是 try 沒被執行，就呼叫了 cancel。
例如在某些異常情況下，呼叫 try 時出現異常，try 介面實際沒有被呼叫，自然沒有返回 yes，那麼會按照正常流程進入第2階段，呼叫 cancel 介面，這就形成了空回滾。
解決方法：讓 cancel 能夠識別出這是乙個空回滾，可以記錄事務執行狀態，cancel 中判斷 try 是否執行了。
提交階段異常時可能會重複呼叫 confirm 和 cancel，所以要實現冪等，保證多次執行效果一致。
解決方法：記錄事務執行狀態，如果執行過了，就不再執行。
現象是先執行了 cancel，後執行的 try，造成資源沒人釋放。
例如呼叫 try 時網路擁堵超時，被認為失敗，然後呼叫 cancel，這時事務相當於結束了，但後來網路好點之後 try 開始執行了，鎖定了相關資源，因為事務已經結束，confirm、cancel 都不會再呼叫了，就造成資源懸掛，無法釋放。
解決方法：還是記錄事務執行狀態，try 執行時判斷 cancel 是否執行了。
tcc是應用層面的分布式事務解決方案，類似2pc，也是2階段提交，分為準備階段、提交階段。
實現時需要注意空回滾、冪等、懸掛問題，可以通過記錄事務狀態來解決。
優點：可靠性高
實時性高
缺點：開發複雜度高
因為事務狀態管理，需要多次db操作，效能有一定損耗
tcc框架：
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
事務 分布式事務
事務 邏輯上的一組操作，要麼都成功要麼都失敗 事務的四個特性 acid 原子性，一致性，隔離性，永續性 事務的隔離級別 讀未提交 產生髒讀 讀已提交 不可重複讀 可重複讀 幻讀 mysql預設 序列化讀 效能最低 傳播行為 7個 七種傳播行為 required 支援當前事務，如果不存在，就新建乙個 ...
分布式事務（二）分布式事務方案
首先這是普通事務 下面是分布式事務 在微服務系統中，每個微服務應用都可能會有自己的資料庫，它們首先需要控制自己的本地事務。一項業務操作可能會呼叫執行多個微服務。如何保證多個服務執行的多個資料庫的操作整體成功或整體失敗？這就是分布式事務要解決的問題。cap 和 base 是對大規模網際網路系統分布式實...