TCC, 是基于补偿型事务的AP系统的一种实现, 具有最终一致性  下面以客户购买商品时的付款操作为例进行讲解: * Try: 完成所有的业务检查(一致性),预留必须业务资源(准隔离性); 体现在本例中, 就是确认客户账户余额足够支付(一致性), 锁住客户账户, 商户账户(准隔离性). * Confirm: 使用Try阶段预留的业务资源执行业务(业务操作必须是幂等的), 如果执行出现异常, 要进行重试. 在这里就是执行客户账户扣款, 商户账户入账操作. * Cancle: 释放Try阶段预留的业务资源, 在这里就是释放客户账户和商户账户的锁; 如果任一子业务在Confirm阶段有操作无法执行成功, 会造成对业务活动管理器的响应超时, 此时要对其他业务执行补偿性事务. 如果补偿操作执行也出现异常, 必须进行重试, 若实在无法执行成功, 则事务管理器必须能够感知到失败的操作, 进行log(用于事后人工进行补偿性事务操作或者交由中间件接管在之后进行补偿性事务操作). # 优点 对比与前面提到的两阶段提交法, 有两大优势: * TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放, 例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-confirm-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题, 追加执行补偿性事务即可. * TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行. # 注意事项 * 事务管理器(协调器)这个节点必须以带同步复制语义的高可用集群(HAC)方式部署. * 事务管理器(协调器)还需要使用多数派算法来避免集群发生脑裂问题. # 适用场景 * 严格一致性 * 执行时间短 * 实时性要求高 举例: 红包, 收付款业务.