所有文章
https://www.cnblogs.com/lay2017/p/12078232.html
正文
前面的文章中，我們先了解了2pc，知道了2pc強一致性導致的資源被長時間鎖住的問題。而后，我們又了解了3pc，3pc在2pc的基礎上增加了超時機制，企圖解決強一致性帶來的問題，但是超時機制明顯會造成真正的數據不一致的可能，而且3pc也沒有真的解決2pc的數據一致性問題。
tcc兩階段補償事務提交協議
本文將了解一個跟2pc很像的事務提交協議，tcc事務提交協議，全稱是：try-confirm-cancel，也是一個分為兩個階段的事務提交協議，如圖所示
tcc事務提交協議分為兩個階段：
1）階段一，主業務嘗試（try）調用從業務，從業務並不直接執行，而是進行一個預留操作。比如，扣減庫存問題，並不直接扣減庫存，而是預留一個扣減字段，表示要扣減多少庫存。
2）階段二，在從業務都返回yes的情況下，主業務將會確認（confirm）之前的預留操作，也就是會根據之前的扣減字段直接扣減庫存了。那如果不是全部yes的情況下，就會調用取消（cancel）請求，取消之前的扣減字段。
tcc與2pc有什么區別
我們發現，tcc和2pc在過程上面非常的像，有哪些相同和不同呢？
相同點
tcc和2pc都是兩個階段，一階段並不真正的執行業務，二階段根據一階段的結果進行確認或者取消。所以，你會覺得在外觀上兩者似乎非常相似。
不同點
開發者感知
tcc和2pc的本質區別就是tcc面向的是業務層面，2pc面向的是資源層面，什么意思？
我們在學習2pc的時候，我們總說一階段是prepare事務，也就是不真正的提交事務。也就是說對資源的更新操作實際上並沒有執行，記錄在事務日志中准備二階段的commit或者rollback。但是這些對於開發者來說其實是無感知的，開發者仍舊對資源進行單一的更新操作。
而tcc，它的一階段進行try預留操作，也就是說開發者需要從業務層面來考慮這個問題，提供try-confirm-cancel這樣的一個業務邏輯來為維護事務提交，開發者對此是感知得很明顯的。我們也可以理解為對業務的入侵。
強一致性和最終一致性
2pc在一定程度上我們稱之為強一致性，所以2pc的執行過程會獨占資源，持有資源的互斥鎖，這也是2pc效率比較低的原因。而tcc雖然增加了業務代碼的復雜性，但是在業務層面上避免長時間占用資源，通過一種confirm或cancel的補償機制來完成整個業務操作，也就是保持最終一致性。最終一致性並不需要長時間持有資源的鎖，每一個事務其實都是相互獨立的，所以tcc的效率會更高。
總結
我們看到，tcc和2pc非常的相似，都是兩階段的性質。但是，2pc從事務資源的角度利用強一致性來解決問題，顯得有些效率低下。而tcc從業務角度來解決問題，把強一致性改成了最終一致性，大大提高了效率。但是tcc明顯對代碼造成了入侵，你原本只需要一個接口，就不得不拆分成三個接口來處理，對開發者的要求也會更高。
另外，2pc在二階段如果出現網絡故障的情況，即使利用持久化的事務日志補償處理也會從強一致性變成最終一致性。而tcc從一開始就決定不維護強一致性，而是遵循最終一致性。這樣看來，tcc雖然增加了開發的復雜度問題，但是在使用上會更加地高效，穩定，即使極端情況下確實需要人工干預，最終一致性也能夠保持。