说明：
演示模块：base-info/jyw-learn模块 base-info连接本地数据库 jyw-learn模块连接虚拟机上安装的数据库
seata下载
演示版本：1.4.2
下载地址：https://github.com/seata/seata/releases/download/v1.4.2/seata-server-1.4.2.tar.gz
seata模块释义：TC(事务调节，指seata服务端)、TM(事务管理器，启动事务的服务，seata客户端)、RM（资源管理器，seata客户端）
下载后解压：
本人演示的seata存储模式用的是file所以没有配置服务端的数据库，如果选择db模式，请创建服务端数据库并执行代码包中的数据库脚本
启动eureka服务后，启动seata服务（TC）
公共模块pom中引入seata依赖：
base-info服务上配置seata：
修改base-info服务application.yml文件
修改公共模块下数据源配置信息：
伪代码如下：（AT模式下需要用到数据源代理）
jyw-learn模块下配置seata(类似base-info配置)
启动base-info，jyw-learn两个服务，控制台打印数据：
seata服务器控制台打印：
注册成功
在两个服务中分别创建undo_log表：
seata执行流程请参阅：Seata入门系列(12)-Seata1.4.2之AT模式执行流程解析_云烟成雨TD的博客-CSDN博客_seata 流程
数据源不配置成代理，会导致不会插入undo_log表，即使事务rollback了，数据也不能被反向补偿
AX模式实例演示：
在远程调用断点，查看undo_log日志：
此字段可以理解为记录一阶段本地事务的的具体动作，一遍远程调用异常时，反向补偿(数据回滚)
远程调用还未执行，TM的本地事务已经提交数据已经入库：
查看base-info控制台，数据回滚后，undo_log数据已被清除，释放全局锁：
AT模式的优缺点：
优点:通过代码我们可以发现，AT模式的启用仅仅是在方法上加@GlobalTransactional, 一种无任何侵入的分布式事务解决方案,一阶段、二阶段提交及回滚均由seata框架自动完成。使用简单
缺点：消耗性能，因为需要开启全局锁
AT模式问题延深：
如何防止AT模式下数据脏读问题？
产生脏读原因：前面的分析我们知道AT模式2阶段提交，一阶段执行在执行完本地事务后，会将数据A持久化到数据库中并生成A数据的undo_log记录，假设现在调用远程事务的同事时，有新的一个本地事务对A数据进修修改，导致A目前的数据跟undo_log记录不一致，在调用远程事务时异常，进而导致全局事务不能回滚。。。A数据不能被回滚，产生了脏数据
2种处理脏读方案：
a.在新的本地事务方法上增加注解@GlobalTransactional，
b.在新事务上增加@GlobalLock
此两种方案本质上都是查看全局锁是否被释放
TCC模式实例演示：
简单而言：TCC也是在2阶段理论下的实现
表提价状态字段：
TCC释义：T->try C->confirm C->cancel
TCC模式下 每个实现方法必须有三个方法即：事务未提交数据持久化方法，事务提交方法，事务回滚方法
在try阶段对插入的数据标识为事务未提交
断点查看异常，远程分支事务异常，查看本地事务种数据，远程异常，调用TM的Rollback
执行rollback 反向补偿数据，数据被清除。
远程分支事务未异常走commit 将数据变为可用数据
TCC模式优缺点：
优点：不需要占用全局锁，性能高；能够保证数据的准确性
缺点：每个需要分布式事务的方法必须要写try，commit，rollback三个方法，相比于AT代码耦合度，代码开发量都要高