从分布式事务解决到Seata使用，一梭子给你整明白了，web开发框架

• E（Eventually Consistent）：最终一致性

这个理论的核心思想便是：如果我们如法做到强一致性，那么每个应用都应该根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

出现场景

====

让我们回到分布式事务中来，什么时候会出现分布式事务呢？

场景1： 虽然时单体的架构服务，但由于在分库的情况下，依然会导致分布式事务的情况，因此单体服务不会出现分布式事务的这种说法，破~

场景2： 分布式架构下，两个服务之间相互调用，虽然使用的是同一个数据库，但是还是会出现分布式事务。谁让你使用的是分布式架构呢~

场景3： 分布式架构下，两个服务之间相互调用，使用的是不用的数据库，这种情况下肯定会出现分布式事务的问题，想都不用想！

解决方法

====

有问题的地方便会有方法，当然也不一定，但是在这里，分布式事务问题确实有解决的方法， 如果没有，小菜也不会写这篇文章来自讨苦吃了！

方法一：全局事务

========

不知道这里该说 全局事务 会让你比较熟悉，还是 两阶段提交（2PC） 会让你比较熟悉，还是说都不熟悉~，不熟悉也没关系，小菜带你熟悉熟悉！

全局事务是基于DTP模型实现的，它规定了要实现分布式事务需要三种角色：

• AP（Application）：应用系统（微服务）

• TM（Transaction Manager）：事务管理器（全局事务管理）

• RM（Resource Manager）：资源管理器（数据库）

除了 AP 这个角色，我们多认识了其他两个同学分别是事务管理器和资源管理器，那么他们起到什么作用呢，那我们就得看，这个两阶段提交是哪两阶段了！

阶段1 ：表决阶段

=========

所有参与者都将自己的事务进行预提交，并将能否成功的信息反馈给协调者

1. 事务管理器发一个 prepare 指令给 A 和 B 两个服务器

2. A 和 B 两个服务器收到消息后，根据自身情况，判断自己是否可以提交事务

3. 将处理结果记录到资源管理器中

4. 将处理结果返回给事务管理器

阶段2 ：执行阶段

=========

协调者根据所有参与者的反馈，通知所有参与者，步调一致地执行提交或者回滚

1. 事务管理器向 A 和 B 两个服务器发送提交指令

2. A 和 B 两个服务器收到指令后，将自己本身事务提交

3. 将处理结果记录到资源管理器

4. 将处理结果返回给事务管理器

这就是两阶段提交的大致过程，它提高了数据一致性的概率，实现成本较低。但是这种实现方式带来的缺点也是很明显的！

• 单点故障：如果事务管理器出现了故障，整个系统将不可