高并发场景下的分布式事务，是行业内至今没有很好解决的难题。
作为中国技术最顶尖的互联网公司，阿里巴巴和蚂蚁金服开源了分布式事务框架Seata。
分布式事务有强一致事务、柔性事务。
Seata框架则集成了TCC、Saga、XA、AT四种模式。
TCC模式，需要开发同学自己实现Try、Confirm、Cancel。
（1）Try: 资源的检测和预留，比如转账，先保证A账户余额足够并冻结；
（2）Confirm：执行业务操作提交，如果 Try 成功 Confirm 一定要能成功。即执行A账号预留资源的扣款；
（3）Cancel: 对Try资源预留的释放。即执行第一阶段资源的释放，解冻A账号预留的余额；
Saga模式，通常是事件驱动，每个参与者异步执行事务。在某个参与者执行失败后，根据具体业务场景正向补充和逆向回滚，使分布式事务的回到正常状态。
画外音：每个库的事务操作，逆向补偿怎么做是核心，RD思考。
XA模式，是业务无侵入的分布式事务解决方案。XA协议需要事务参与者数据库主动支持，目前主流数据库都有支持。AT 和 XA都是业务无侵入，XA是数据库来完成，实现更轻量。
画外音：实现更轻量，但是XA是强一致，性能比AT弱。
AT模式，一种对业务无侵入的解决方案。开发同学只需要关注自己的“业务SQL”，Seata会自动生成事务的二阶段提交和回滚。他实现的是最终一致的分布式事务。
第一阶段准备
，Seata拦截“业务SQL”，解析SQL，并找到对应表的对应业务数据。
（1）在操作业务数据前生成“before image”；
（3）对更新后的数据，生成“after image”，进行快照；
将上述操作在一个数据库的事务中完成。分布式事务会有多个数据库执行相同操作。
若第二阶段提交
，Seata框架只需将第一阶段的快照数据和行锁删掉，清理完即可。
若第二阶段回滚
，将第一阶段的“before image” 快照数据还原即可。但是在还原前，需要对比“数据库当前业务数据”和 “after image”。如果不一致说明出现脏数据，得人工介入。
DAY1（7.14）
（1）分布式场景下数据一致性问题分析；
（2）分布式事务解决方案深入对比分析；
（3）Seata架构以及实现原理剖析；
DAY2（7.15）
（1）Seata AT模式架构设计与实现原理剖析；
（2）Seata Saga模式架构设计与实现原理剖析；
（3）Seata框架TCC、XA模式架构设计与实现原理剖析；
（4）Seata框架AT、Saga模式企业级应用与实践；
DAY3（7.16）
（1）Seata框架与Spring集成企业级应用实践（高并发社交、电商、金融案例）；
（2）Seata框架与Dubbo集成企业级应用实践（高并发社交、电商、金融案例）；
