在微服务架构中Try-Confirm-Cancel都对应一个微服务调用，你就可以猜测到，TCC的任何一个步骤都可以是本地事务。
在TCC里面，Try可以是一个完整的本地事务，Confirm 也可以是一个完整的本地事务，Cancel 同样可以是一个完整的本地事务。
比如在我的某个业务里面，Try 本身就是插入数据，但是处于初始化状态，还不能使用。后续 Confirm 的时候就是把状态更新为可用，而 Cancel 则是更新为不可用，当然直接删除也是可以的。
不过TCC怎样都是是出错的，比如说在Confirm阶段出错或出现超时，所以你搞不清楚究竟有没有提交的。这里可以补一句，引出下面的亮点。
TCC用起来还是比较简单的，但是要想做好容错还是很不容易的。
：
容错很多时候就是重试，重试失败之后人工介入或者引入自动故障处理机制，后续尝试修复数据。
面试的时候需要一步步分析，首先要分析出错的场景。
正常来说，TCC里面T阶段出错是没有关系的。比如说前面的那个例子里，数据处于初始化状态的时候，其实后续业务是用不了的，也不会有问题。但是如果在Confirm的时候出错了，问题就比较严重了。比如说一部分业务已经将数据更新为可用了，另外一部分业务更新数据为可用失败，那么就会出现不一致的情况。基本上这里只能考虑不断地重试，确保在
Confirm阶段都能提交成功。毫无疑问，不管怎么重试，最终都是要失败的，所以要做好监控和告警的机制。
这里我们提到了重试最终都可能失败，所以紧接着你要进一步补充重试失败了以后怎么办。
