摘自：https://www.cnblogs.com/iceggboom/p/12144570.html
分布式事务框架-seata初识
一、事务与分布式事务
事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。
那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。
二、介绍Seata:Simple Extensible Autonomous Transaction Architecture，简易可扩展的自治式分布式事务管理框架，其前身是fescar。阿里巴巴GTS的开源版实现，是一种分布式事务的解决方案。
三、架构
Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。
Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。
Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。
Config：用来存储和查找服务端的配置。
Lock：锁模块，用于给 Seata 提供全局锁的功能。
Rpc：用于和其他端通信。
HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。
四、工作流程
Transaction Coordinator(TC)：管理全局的分支事务的状态，用于全局性事务的提交和回滚。
Transaction Manager(TM)：事务管理器，用于开启全局事务、提交或者回滚全局事务，是全局事务的开启者。
Resource Manager(RM)：资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接受TC的命令来提交或者回滚分支事务。
TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。
XID在rpc中传播给每一个调用链中的服务。
每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。
RM完成本地分支的业务，提交本地分支，并且报告给TC。
全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。
假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。
TM检测到了某个分支事务失败，向TC发起全局事务回滚。
TC给每一个RM发送消息，通知它们全部回滚。
TC将全局事务回滚的结果发送给TM，全局事务结束。
五、设计思想(重点)Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的，但XA 协议它依赖的是数据库层面来保障事务的一致性，也即是说 XA 的各个分支事务是在数据库层面上驱动的，由于 XA 的各个分支事务需要有 XA 的驱动程序，一方面会导致数据库与 XA 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，所以性能较差。