什么是TCC事务
ICC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。 Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即口滚操作。TM首先发起所有的分支事务的Try操作，任何一个分支事务的Try操作执行失败，TM将会发起所有分支事务的Cancel操作，若Try操作全部成功，TM将会发起所有分支事务的Confirm操作，其Confirm/Cancel操作若执行失败，TM会进行重试。
成功情况：
失败情况：
TCC分为三个阶段：
Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。
confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm 阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。
Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为 Cancel 阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。
TM事务管理器
TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。
TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于 Confirm 和 Cancel 失败需进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求多少次，其结果都相同。
TCC解决方案
目前市面上的TCC框架众多比如下面这几种：
- tcc-transaction
- hmily
- ByteTCC
- EasyTransaction
- Seata
TCC模式原理
举例一个扣减用户余额的业务。假设账户A原来金额是100，需要扣减30元。
- 阶段一（Try）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
- 阶段二：加入要提交（Confirm），则冻结金额扣减30
- 阶段二：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30
阶段二只操作冻结金额（预留资源），一阶段每个事务只操作自己的冻结金额（预留资源），事务相互之间没有关联（隔离）
空回滚、幂等、悬挂
空回滚
在没有调用TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。
出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行 Try 阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚：如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表 ，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。
幂等
通过前面介绍已经了解到 ，为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段Try、Confirm 和 Cancel接口保证幕等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。
解决思路在上述”分支事务记录’中增加执行状态，每次执行前都直询该状态。
悬挂
Cancel 比 Try 先执行，需要阻止 Try 执行
悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。
出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时RPC 调用的网络发生拥堵，通常 RPC调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。
解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。