分布式事务介绍
名义上的分布式事务的常见实现
名词解释： 基本组件：
-
事务协调器（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
-
Transaction Manager（TM）： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
-
资源管理器（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
-
还有一个，全局事务发起，例子： 购买服务A， 需要调用订单服务 B，和库存服务C，配合完成购买行为，那么服务A 是这个全局事务的发起者
-
分布式事务概览， 分布式事务本质来说，就是利用 TM 或TC 来协调 多个 数据库的本地事务机制，使他们做出一致的反应，就像是在一个数据库一样，那这样的话，就需要考虑数据库事务的四个大原则（其实 能完整实现四个原则的 数据库引擎都不能算有的), TM协调多个数据库，起码要符合 A (原子性)，C(一致性)， I(isolution,隔离性的话，尽量做到全局事务的 未全局提交读，或者全局提交读) 相当于 TC 和 TM 对多个数据库的本地事务的控制，控制力度越大，短时间内的一致性越好，并发性能越差。 最终一致性，相当于就是部分控制本地事务， XA 就是全局控制多个本地事务
2PC 及其引申
-
2PC 最简单容易理解的，二阶段，全局事务 它的思想源自于 数据库的XA 协议， 基本流程就是 query prepare -> confirm (or rollback)
-
由2PC 思想 引申出 3PC 阶段的流程，本质上为了缓解， XA 占用某个数据库事务资源过久的问题，降低占用某个数据库事务资源的时间
-
Seata 这个成熟的分布式事务解决方案的，TA 方案是由 XA出发的，但做了相应改善和提高 改善点 主要在于： 3.1 XA 是询问资源准备并锁资源，等待提交（占用资源时间长）。 TA是直接执行本地事务了，但记录 回撤的undolog日志，当TC 要求多个本地事务回滚的时候，这时候本地事务能够根据undolog 来进行回滚操作。
TCC 的业务实现 4. 上面这几个都是在服务调用方直接连多个数据库操作，这在微服务体系下，调用rpc接口进行服务调用可能不太合适，由此延伸出TCC方案 所谓TCC( try, confirm ,cancel )的缩写
抽象成接口就是:
interface TCC {
try();
confirm();
cancel();
}
这个意思是指，例子： 订单服务A, 库存服务B, 购买服务C
C-> A 的创单接口 C-> B 的扣库存接口 服务A 的 创单接口 需要实现 TCC 接口， 服务B 的扣库存接口也要实现 TCC接口功能，从业务角度来说，A & B接口还要保证幂等（防止多次调用） 当 C 服务发起者 调用 A &B 相应接口进行购买，先调用各自 try()接口锁资源（锁定资源后，需保证 confirm 或者cancel 需要能成功），然后再进行confirm 操作，失败再进行cancel操作， 当然上面的统一流程管理是简化版，需要用TC & TM 组件 进行管理
互联网公司为了高并发，而采用的最终一致性方案，及其可用和可行性
这里直接说结论吧
[最终一致性，分布式方案]，见图1
引申文章
图1：
