普通的单系统事务，本地事务可用 ACID 解决； 但是现在都是分布式系统，此时本第十五已经不够看了，需要 考虑到分布式事务。
一致性(consitency)：用户访问分布式系统中的任意节点，得到的数据必须一致
可用性(availability)：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
分区容错性(partition tolerance)：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
BASE理论：
Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性。属于弱一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
解决分布式事务的思路：
分布式事务最大的问题是 各 子节点事务一致性的问题，借鉴CAP 和BASE理论，可有两种解决思路：
- AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
- CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者
seata 事务管理中有三个重要角色：
- TC(事务协调者)：维护全局和分支事务的状态，协调全局事务提交或回滚
- TM(事务管理器)：定义全局事务的范围，开始全局事务，提交或回滚事务
- RM(资源管理器)：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
========================
由 "主服务"调用发起者 开启 全局 事务。
例如： order服务 需要调用 account 和 storage 服务，为保证分布式事务， 需要在 order 服务的 具体方法上(订单创建方法。订单创建方法调用到 账户和库存的方法)，加全局事务注解 @GlobalTransactional。
当然在此之前，需要 启动 seata-server(本质也是一个服务)，参与全局事务的各微服务都要引 seata依赖，配置文件 seata相关
AT与XA的区别 ：
简述AT模式与XA模式最大的区别是什么？
XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致
在多线程并发访问AT模式的分布式事务时，有可能会出现脏写问题。 解决思路是 引入 全局锁。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据