【分布式事务】TCC方案

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接： https://blog.csdn.net/yyx3214/article/details/100584267

此图是在别人博客中盗的，感觉人家画的比我画的好看那么一丢丢，O(∩_∩)O哈哈~
现在把A服务和B服务看做是银行服务吧

这个其实用到了补偿的概念，分为了三个阶段：
1）Try阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留
2）Confirm阶段：这个阶段说的是在各个服务中执行实际的操作
3）Cancel阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑回滚操作，

举个例子，比如跨银行转账的时候，要涉及到两个银行的分布式事务，如果用TCC方案来实现，思路是这样的:
1)Try阶段：先把两个银行账户中的资金给它冻结住就是不让操作
2)Confirm阶段：执行实际的转账操作，A银行账户的资金扣减，B银行账户的资金增加、
3)Cancel阶段：如果任何一个银行的操作执行失败，那么就需要回滚进行补偿，就是比如A银行账户如果已经扣减了，但是B银行账户资金增加失败了，那么就得把A银行账户的自己给加回去

这种方案实话说几乎很少人用，但是也有使用场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。

比如说，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，在自己上出问题