分布式事务解决方案

1.分布式事务解决方案
例如我们编写的扣减库存与保存订单是在两个服务中存在的，如果扣减库存后订 单保存失败了是不会回滚的，这样就会造成数据不一致的情况，这其实就是我们所说的分布式事务的问题，接下来我们来学习分布式事务的解决方案。
1.1 本地事务与分布式事务
1.1.1 事务
数据库事务(简称：事务，Transaction)是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
事务拥有以下四个特性，习惯上被称为ACID特性：
原子性(Atomicity)： 事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性(Consistency)： 事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。
隔离性(Isolation)： 多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个操作在被数据库所执行一样。
持久性(Durability)： 已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。
1.1.2 本地事务
起初，事务仅限于对单一数据库资源的访问控制,架构服务化以后，事务的概念延伸到了服务中。倘若将一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源,这类基于单个服务单一数据库资源访问的事务，被称为本地事务(Local Transaction)。
1.1.3分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

1.2 分布式事务相关理论
1.2.1 CAP定理
CAP 定理是在 1998年加州大学的计算机科学家 Eric Brewer （埃里克.布鲁尔）提出，分布式系统有三个指标

• Consistency 一致性
• Availability 可用性
• Partition tolerance 分区容错性

它们的第一个字母分别是 C、A、P。Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做CAP 定理。
一致性（C） Consistency： 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

• 如何实现一致性：
  1 写入主数据库后要同步数据至从数据库
  2 写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步后在释放锁，以免写入成功后，向从数据库查到旧的数据
• 分布式系统一致性的特点：
  1 由于数据在同步的过程中，所以会出现一定的延迟
  2 为了保证数据的一致性，会对资源占时锁定，待数据同步后在释放资源
  3 如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据
  可用性（A）Availability ： 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 如何实现可用性
  1 写入主数据后的数据也要同步至从数据库
  2 在写入的过程中不可将数据库中的资源进行锁定
  3 即使数据没有同步过来，也要将结果进行返回，哪怕是旧的数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时
• 分布式系统中可用行的特点
  1 所有请求都有响应，且不会出现响应超时或响应错误的情况
  分区容忍性（P）Partition tolerance ： 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
• 如何实现分区容忍性
  1 尽量使用异步来取代同步操作，例如使用异步的方式将数据从主数据库同步到从数据库，这样结点之间能有效的实现松耦合
  2 添加数据库结点，其中一个挂掉后其他结点提供服务
• 分布式分区容忍性的特点
  1 分区容忍性是分布式系统具备的基本能力

分布式事务解决方案之2PC(两阶段提交)

• 什么是2PC
  2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commitphase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
  举例：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊中羞涩，都不愿意请客，这时只能AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成了尴尬的一幕：
• 准备阶段：老板要求张三付款，张三付款。老板要求李四付款，李四付款。
• 提交阶段：老板出票，两人拿票纷纷落座就餐。

例子中形成了一个事务，若张三或李四其中一人拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。
在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议，如下图：

1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事
   务，并写本地的Undo/Redo日志，此时事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

下图展示了2PC的两个阶段，分成功和失败两个情况说明：
成功情况：

失败情况：

2. 基于Seata实现分布式事务
2.1 Seata简介
Seata（原名Fescar） 是阿里18年开源的分布式事务的框架。Fescar的开源对分布式事务框架领域影响很大。作为开源大户，Fescar来自阿里的GTS，经历了好几次双十一的考验，一经开源便颇受关注。后来Fescar改名为Seata。
2.2 实现原理
Fescar将一个本地事务做为一个分布式事务分支，所以若干个分布在不同微服务中的本地事务共同组成了一个全局事务
Seata的设计思想如下：
Seata 的设计目标其一是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进，并解决
2PC方案面临的问题。Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下
图是全局事务与分支事务的关系图

与 传统2PC 的模型类似，Seata定义了3个组件来协议分布式事务的处理过程：

• Transaction Coordinator (TC) ： 事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。
• Transaction Manager ™ ： 事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终
  向TC发起全局提交或全局回滚的指令。
• Resource Manager (RM) ： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支（本地）事务的提交和回滚。

Seata实现2PC与传统2PC的差别：

• 架构层次方面，传统2PC方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现，而Seata的 RM 是以jar包的形式作为中间件层部署在应用程序这一侧的。
• 两阶段提交方面，传统2PC无论第二阶段的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1 就将本地事务提交，这样就可以省去Phase2持锁的时间，整体提高效率。

Seata执行流程
1、正常提交流程

2、回滚流程
回滚流程省略前的RM注册过程。

要点说明：
1 、每个RM使用DataSourceProxy连接数据库，其目的是使用ConnectionProxy，使用数据源和数据连接代理的目的就是在第一阶段将undo_log和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有
undo_log。
2、在第一阶段undo_log中存放了数据修改前和修改后的值，为事务回滚作好准备，所以第一阶段完成就已经将分支事务提交，也就释放了锁资源。
3、TM开启全局事务开始，将XID全局事务id放在事务上下文中，通过feign调用也将XID传入下游分支事务，每个分支事务将自己的Branch ID分支事务ID与XID关联。
4、第二阶段全局事务提交，TC会通知各各分支参与者提交分支事务，在第一阶段就已经提交了分支事务，这里各各参与者只需要删除undo_log即可，并且可以异步执行，第二阶段很快可以完成。
5、第二阶段全局事务回滚，TC会通知各各分支参与者回滚分支事务，通过 XID 和 Branch ID 找到相应的回滚日志，通过回滚日志生成反向的 SQL 并执行，以完成分支事务回滚到之前的状态，如果回滚失败则会重试回滚操作。
2.4 代码实现
资源里面有说明，简单易用
fascar相关资源
提取码：f675