我们在说到事务的时候，总会以转账作为经典案例：用户下单买东西，一次买卖过程会扣件库存，生成订单，扣减账户余额；在这样的情况下，如果要保证数据业务的成功，必须引入事务。不再赘述。
在事务案例里面，我们的项目结构是这样的，Storage、Order、Account是一个服务里的三个功能模块，他们共同面对一个DB，这时候，启用本地事务，就可以实现三个操作的共同成功和共同失败。
然而，我们知道，如果库存、订单、账户分别在不同的服务当中，每个服务对应自己的DB，那么本地事务就没有办法去限制和判断其他操作是否一致性完成。这就需要引入分布式事务。
分布式系统的三大原则：CAP
我们介绍解决方案之前，我们先介绍分布式系统的三大原则，也就是总会被提到的CAP定理：一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)，分别解释一下：
一致性：我们希望分布式系统中各个节点的数据能保证一致，这里的“一致”，对于主从数据库来说是指主库和从库要保证数据一致。还是还有一层意思，就是分布式系统任何时刻数据都是最新状态。比如我买了东西，接下来order和account返回的就是最新的状态，我能从数据库中直接查到；再比如我们刚对数据库insert了一条数据，立马select，我们希望从数据库中返回的就是刚刚insert的数据。
如果我们要做到以上所说的，我们需要master向slave同步数据后，slave同步数据并锁表（假设因为网络原因同步需要一些时间），不对外开放读的状态，直到slave数据修改成功后，解锁。
可用性：与一致性不同，所谓可用，就是每次访问数据时都能够得到数据，不能返回错误和超时，这一点看起来就和保证一致性的时候同步有些冲突，因为我们为了一致性得锁表，可能就会导致延时。
分区容错：分区容错是我们使用分布式，特别是主从复制时候的意义所在，它指的是其中一个结点挂了，不能使整个数据库集群收到影响，其他服务还是可以正常运行。
看了以上三个原则的特点，我们可以了解到，CAP不能够共存，如果需要每次返回都是最新数据，那么就可能存在系统延时，但是这又违反了可用性。但无论如何，分区容错是必须保证的，集群不能因为某一个结点的宕机而整个垮掉。那么所有的分布式解决方案，也就是基于满足AP或者CP来展开设计的。
还是基于上面的案例，我们来设计一个分布式事务解决方案：
拿Storage和Order举例，既然业务上分成了两个服务，如果他们在各自的服务里面执行数据操作后，告诉某一个中心操作结果，如果各自的事务提交都成功，则整体成功，如果其中有一个事务失败，则一起回滚，这样一来不就可以控制分布式事务了吗。
从上图我们可以看到，全局的事务可以通过一个专门的服务——Transaction Manager（TM）进行管理，它会去统计所有相关子事务的执行情况，如果全部提交成功，对应的全局事务正常结束就可以了（因为各个子事务已经完成了提交任务），如果其中有一个事务出现了问题，我们可以根据每个子事务上的undo log进行回滚，数据状态修复。
这其实就是Seata的实现原理：
在一次分布式事务中，发起全局事务的服务会向Seata服务注册一个全局事务，这个全局事务会给各个子事务进行关联：
与我们之前自己臆想的分布式事务有点出入的是，Seata还定义了一个事务调度服务：Transaction Coordinator(TC)它用来执行TM的指令。
- 发起全局事务的微服务会启动一个全局事务的实例（TM），TM会告诉TC进程“我要开启全局事务了”，这时候，TC会返回一个XID给该微服务。
- 得到XID后，该微服务上的资源管理器（Resource Manager）将子事务注册到TC上，TC将该事务纳入全局事务管理。
- 微服务开始执行自己的本地事务，比如新建一个order表数据。
- 随着代码逻辑的执行，现在需要远程调用库存微服务，去扣减库存，这时候这个全局的XID会一并传给库存服务上的TM，库存上的MC就会在本地事务开启之前向TC进行子事务的注册，这样库存事务也被纳入全局事务管理。
- 库存事务执行完毕后，返回到订单微服务，这个时候，如果订单事务也执行完成，则由TM（TM存在于发起全局事务的服务中）告诉TC各个子事务的执行情况，将提交或回滚的决议给到TC。
- TC根据全局事务-分支事务的映射关系执行TM传过来的决议。
