TCC介绍
TCC模式即将每个服务业务操作分成两个阶段，第一个阶段检查并预留相关资源，第二个阶段根据所有服务业务的try状态来操作，如果都成功，则进行Confirm操作，如果任意一个Try发送错误，则全部Cancel。
- Try：准备操作，完成所有的业务检查，预留业务资源。
- Confirm：真正执行的业务逻辑，不做任意的业务检查，只使用Try阶段预留的业务资源。因此Try操作成功，Confirm必须能成功。同时，Confirm操作必须保证冥等性，保证一笔分布式事务能切只能成功一次。
- Cancel：释放Try阶段预留的业务资源，同样Cancel操作也必须满足冥等性。
TCC模型实际是通过业务分解来实现分布式事务，对业务有较强的侵入性。
TCC模型需要注意的地方:
- 允许空回滚，即try没有完成资源预留，允许短路操作。
- 防悬挂控制，即需要保证，cancel必须在try之后才执行。
- 冥等性设计，即需要保证confirm和cancel需要保证冥等性，防止网络因素导致数据混乱。
AT
AT模式就是两阶段提交，自动生成反向SQL，当发生异常的时候，通过反向SQL回滚数据。
Seata框架对AT的支持如下:
- 第一阶段，业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
- 第二阶段，提交异步化，非常快速的完成，回滚的话通过一阶段的回滚日志进行反向补偿。
柔性事务下的事务特性
- 原子性：正常情况下保证
- 一致性：某个时间点，数据存在不一致，但是最终是一致的。
- 隔离性：某个时间点，A能读到B事务未提交的结果，即会脏读现象。
- 持久性：和本地事务一样，只要commit则数据就会被持久化。
总结
分布式事务主要目的是解决数据一致性问题，XA强一致，但是吞吐量太低，不利于高并发场景。柔性事务不保证强一致性，但是通过补偿实现最终一致性，常见的补偿有重试补偿、调度补偿、人工补偿等。
