什么是事务？简单来说，即几个事要么都做，要么都不做。如产生订单和减库存。
事务的四个特性：ACID（原子性，一致性，隔离性，持久性），本质是通过锁实现一致性和隔离性。
分布式事务是指会涉及到操作多个数据库（服务）的事务。其实就是将对同一数据库（服务）事务的概念扩大到了对多个数据库（服务）的事务。目的是为了保证分布式系统中的数据一致性。
分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
Begin Transaction：表示事务的开启标志。
采用@Transaction注解可实现：要么都执行，要么都不执行。
分布式事务解决方案：增加协调者（吃饭与看电影的情况都反馈给协调者，决定要么全部执行，要么全部回退）。
AP： 应用程序
TM：事务协调者，binlog可充当协调者。协调者根据返回结果决定commit或rollback。
RM：DB（资源管理器）
两阶段提交协议（2PC）保证了事务原子性。
2PC第一阶段：准备(投票)阶段:预备提交，将结果反馈给事务协调者。
第二阶段：执行Commit提交，保证了要么全执行，要么都不执行
回滚：返回no/协调者再规定时间内，没有收到所有参与者反馈,利用本地日志回滚。
2PC两阶段缺点：
1.如果事务协调者出错，事务会失败，
2.阻塞资源：占用数据库连接，性能低
3.数据不一致：两阶段出错，数据不一致。（比如某个系统挂了）
打个比方：我们从A地到B地，谁也无法保证一定能成功到达B地，可能在某一段程序执行时，系统挂了。
鸵鸟算法是一种忽略潜在问题的一种算法策略，类似鸵鸟遇到变化时，仍然埋头而置之不理。
三阶段提交协议（3PC）：对两阶段协议进行了增强。
- can commit：事务协调者对服务进行“检查SQL”判断，再返回服务结果
abort commit：1.有参与者返回no，2，协调者等待超时，3，参与者没收到协调者指令
- pre commit：服务执行结果，反馈事务协调者
超时机制：协调者发出回滚指令
超时机制：参与者发出回滚指令（没有等到协调者发来的指令）
- do commit： 事务协调者返回可以执行或不允许执行，服务再执行commit提交。
超时机制：协调者发生回滚指令
超时机制：参与者发生commit指令提交，（最后一步没收到协调者指令，自作主张提交了），万一自己猜对了呢？三阶段一定程度提高了两阶段的准确性。
超时机制类似微服务的熔断降级，防止了系统雪崩，虽然三阶段应用较少，但这个理论值得注意。
以订单和库存为例：订单未生成，库存也对应不能减（@Trasactional）
分布式事务原理：引入第三方服务seata作为协调者。
Seata server（协调者）服务注册到eureka注册中心，并建立三张表。
在每个服务中引入一个seata依赖，再在代码中增加@GlobalTransactional注解（只需此两步，仅需在第一个服务（比如Order服务）上加@GlobalTransactional注解即可）：
订单服务中增加@GlobalTransactional注解：
Eureka注册中心：
Seata server配置文件如下：
Register.conf内容:
File.conf指向seata数据库：
配置一个Seata 本地数据库：
最终实现：如果订单未生成，则库存也不减。
