tcc柔性事务细节

本文面对对tcc有一定了解的朋友。

tcc，是分布式系统场景下的一种事务解决方案。他和传统的分布式事务的最大区别是，分布式事务会锁资源，而tcc属于柔性事务，不会锁资源。

也就是说，根据cap理论，选择一致性还是可用性。

一般锁资源会导致体统性能低下而不可用，所以还是要用柔性事务，实现最终一致性

实现柔性事务三种方式，tcc，消息机制，补偿型。

tcc为try confirm cancle。大家应该都听过不少次。但是，try做的什么，confirm做什么，cancle做什么？

举一个转账的例子，a给b转账100。那么try做什么？

回过头来，我们看看，tcc和补偿型事务的一个最大的区别是，补偿型的事务不隔离，也就是说补偿型事务每执行一步，对其他事务都是可见的。

而tcc是事务隔离的，因此，tcc的try所造成的修改，其他事务应该看不到修改。因为，try不对数据库做修改，至少不commit。

回到例子，a给b转账，a的try就是检查a的余额是否有100，b的try就是b是否能收款。

如果两边的try都通过，那么就执行confirm，a，b在数据库执行变更。

至于cancle？我认为不用做什么，或者做rollback。

这里还有问题，confirm和cancle的多个动作，不能保证都可以成功完成，因此，需要有重做机制，而重做，意味着需要把confirm做成幂等操作。

既然要保证confirm的完成，也就等于需要一套消息机制做保障。因此，3个柔性事务实现对比，tcc不如消息通知机制。

另外，幂等操作需要保证顺序，需要有额外的时间戳保证顺利。

对账是最后的手段。