TCC补偿性事务（柔性事务）
在Try阶段要对资源做预留 【做过的操作】，如果是Confirm就可以删除预留信息，如果是Cancel 则需要拿预留信息进行回滚。
消息事务 【强一致性】
分布式事务的实现 ： TCC 补偿式事务
@Compensable 加上代表是分布式事务； confirmMethod 事务提交的方法，cancelMethod是事务回滚的方法。
TCC :保证不了幂等性。由项目自身保证，框架不保证。
TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。
一个案例解释 TCC ：
账务拆分的业务场景如下，分别位于三个不同分库的帐户ABC，A和B一起向C转帐共80元。
1、Try：尝试执行业务。
【完成所有业务检查（一致性），预留业务资源(准隔离性)】
完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。
预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。
2、Confirm：确认执行业务。
【确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源】
真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。
只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。
3、Cancel：取消执行业务
【 取消Try阶段预留的业务资源】
释放Try阶段预留的业务资源：如果Try阶段只有部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。
