本文面對對tcc有一定了解的朋友。
tcc，是分布式系統(tǒng)場景下的一種事務(wù)解決方案。他和傳統(tǒng)的分布式事務(wù)的最大區(qū)別是，分布式事務(wù)會鎖資源，而tcc屬于柔性事務(wù)，不會鎖資源。
也就是說，根據(jù)cap理論，選擇一致性還是可用性。
一般鎖資源會導致體統(tǒng)性能低下而不可用，所以還是要用柔性事務(wù)，實現(xiàn)最終一致性
實現(xiàn)柔性事務(wù)三種方式，tcc，消息機制，補償型。
tcc為try confirm cancle。大家應該都聽過不少次。但是，try做的什么，confirm做什么，cancle做什么？
舉一個轉(zhuǎn)賬的例子，a給b轉(zhuǎn)賬100。那么try做什么？
回過頭來，我們看看，tcc和補償型事務(wù)的一個最大的區(qū)別是，補償型的事務(wù)不隔離，也就是說補償型事務(wù)每執(zhí)行一步，對其他事務(wù)都是可見的。
而tcc是事務(wù)隔離的，因此，tcc的try所造成的修改，其他事務(wù)應該看不到修改。因為，try不對數(shù)據(jù)庫做修改，至少不commit。
回到例子，a給b轉(zhuǎn)賬，a的try就是檢查a的余額是否有100，b的try就是b是否能收款。
如果兩邊的try都通過，那么就執(zhí)行confirm，a，b在數(shù)據(jù)庫執(zhí)行變更。
至于cancle？我認為不用做什么，或者做rollback。
這里還有問題，confirm和cancle的多個動作，不能保證都可以成功完成，因此，需要有重做機制，而重做，意味著需要把confirm做成冪等操作。
既然要保證confirm的完成，也就等于需要一套消息機制做保障。因此，3個柔性事務(wù)實現(xiàn)對比，tcc不如消息通知機制。
另外，冪等操作需要保證順序，需要有額外的時間戳保證順利。
對賬是最后的手段。
