Seata基本实现原理

seata四种模式：

At模式 无侵入，自动补偿
Tcc模式：TCC中，如果在第一阶段所有业务资源都预留成功，那么confirm各个从业务服务，否则取消(cancel)所有从业务服务的资源预留请求
SAGA模式：为长事务提供有效的解决方案
XA模式：开发中。。。。

一阶段加载

在一阶段，Seata会拦截“业务SQL”
解析SQL语义，找到“业务SQL" 要更新的业务数据，在业务数据被更新前，将其保存成"before image”
执行“业务SQL" 更新业务数据，在业务数据更新之后,
其保存成"after image”，最后生成行锁。
以上操作全部在一个数据库事务内完成, 这样保证了一阶段操作的原子性。

二阶段提交

二阶段如果顺利提交的话，因为"业务SQL"在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的 “业务SQL"，还原业务数据。
回滚方式便是用"before image"还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和"after image"。
如果两份数据完全一致就说明没有脏写， 可以还原业务数据，如果不一致就说明有脏写, 出现脏写就需要转人工处理。

个人总结：

seata分成三个模块：首先创建全局的事务管理TC  然后加上@GlobalTransactional注解的方法，确定事务方法（整个事务范围）TM ，每个参与的数据库为RM(事务参与者)
seata数据库设计：总的TC 全局数据库，用来保存生成的log文件，其他的数据库也应该有一个seata的表，用来记录回滚日志
seata分为两个阶段
一阶段：
调用方法，事务开始的时候，seata会先将表/行锁住，首先seata会拦截执行的sql，然后生成查询前快照（记录执行前数据），然后执行sql，在生成查询后快照（记录执行后数据），生成数据并保存在自己的数据库中，这个时候SeaTa会释放锁（别的线程可以更改）
二阶段：
① 成功：当全部执行成功之后就在seata的数据表中删除当前分支的数据，业务正常执行
② 失败：Seata会对比查询后快照和当前数据是否一致，如果一致则回滚到查询前快照，如果不一致需要人工干预，不一致的情况下一般是高并发下，在这个过程中别的线程更改了数据库
失败的人工干预，反正官网没给出解决方案，所谓的解决方案只是关闭校验。不可行。
解决的话：可以使用Seata的TCC模式，会一直锁定资源，当然这会带来性能的损害。而且有一定的侵入性。