微服务实战 05 分布式事务入门

1999

已于 2022-08-19 21:49:37 修改

阅读量229

点赞数 1

分类专栏： springCloud Alibaba 文章标签：微服务分布式 java

于 2022-08-18 21:20:33 首次发布

本文链接：https://blog.csdn.net/qq_44808472/article/details/126412446

版权

springCloud Alibaba 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

微服务实战 05 分布式事务

分布式事务
- 分布式事务模型

在这里插入图片描述

参考《Spring Cloud Alibaba 微服务原理与实战》

分布式事务

数据库事务的特性
- 原子性
- 一致性
- 隔离性
- 持久性
  但是在微服务架构下，随着业务和数据库的差分，原本的但数据库操作就变成了多个数据库的操作，由于每个数据库的事务执行情况只有自己知道，就无法保证事务的基本特性。
  准确的说，分布式事务是指参与者、支持事务的服务器、资源服务器及事务管理器分别位于分布式系统的不同节点上

分布式事务模型

分布式事务也叫分布式数据一致性问题，就是如何在分布式场景中保证多个节点数据一致性。分布式事务产生的核心原因在于存储资源的分不行。

X/Open 分布式事务模型

(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由这个厂商进行具体的实现。
X/Open DTP 定义了三种角色

AP ： application 应用程序
RM：Resource Manager 表示资源管理器，比如数据库
TM： Transaction Managet 表示事务管理器，一般指事务协调者，负责协调和管理事务。

在这里插入图片描述
大致流程

配置TM，把多个RM注册到TM，相当于TM注册RM作为数据源
AP从TM管理的RM中获取连接，如果RM是数据库的话则获取JDBC连接
AP向TM发起一个全局事务，生成全局事务ID( XID), XID 会通知各个RM
AP 通过第二部获取的连接直接操作RM完成数据操作，这是，AP在每次操作时会把XID传递给RM
根据各个RM的事务执行结果，执行提交或者回滚操作

XA协议

由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器（RM）与事务管理器™之间进行通信的标准接口。
XA主要就是TM和RM之间的通讯桥梁。

Mysql的XA事务分为外部XA和内部XA

外部XA用于跨多MySQL实例的分布式事务，需要应用层作为协调者，MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：网易的DDB，淘宝的TDDL等等。
内部XA事务用于同一实例下跨多引擎事务，由Binlog作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部XA事务，只不过二进制日志的参与者是MySQL本身。Binlog作为内部XA的协调者，在binlog中出现的内部xid，在crash recover时，由binlog负责提交。(这是因为，binlog不进行prepare，只进行commit，因此在binlog中出现的内部xid，一定能够保证其在底层各存储引擎中已经完成prepare)。

两阶段提交

两阶段提交将一个事务的处理过程分为投票和执行两个阶段

准备阶段：TM 通知 RM 准备分支事务、记录事务日志，并告诉事务管理器准备结果
提交/回滚阶段：如果所有的 RM 在准备阶段都明确返回成功，则事务管理器（TM）向所有的资源管理器（RM）发起事务提交指令完成数据的变更。反之，如果任何一个 RM 明确返回失败，则 TM 会向所有 RM 发送事务回滚指令

两阶段提交的缺点

同步阻塞，所有的事务操作都是同步阻塞型的，对于任何一个指令都必须要有明确的相应才能继续进行下一步要，否则处于阻塞状态，占用的资源一直会锁定
过于保守：任何一个节点失败都会导致数据回滚
事务协调者单点故障：如果协调者在第二阶段出现了故障，嘛呢其他的参与者（RM）会一直处于锁定状态
“脑裂”导致数据不一致：在第二阶段中，TM 向所有 RM 发送 commit 请求后，发生局部网络异常导致只有一部分 RM 接收到了 commit操作，但是未收到 commit 请求的节点由于事务无法提交，导致出现不一致问题

三阶段提交协议

三阶段提交协议式两阶段提交协议的改进保本，他利用超时机制解决了同步阻塞的问题

CanCommit ： TM 向参与者发送事务执行请求，询问是否可以完成指令，参与者只需要回答是或者不是即可，不需要做真正的事务操作，这个阶段会有超时终止机制
PreCommit：TM 会根据参与者的反馈结果决定是否继续执行，如果在询问阶段所有参与者都返回可以执行操作，则事务协调者会向所有参与者发送PreCommit请求，参与者收到请求后写 redo 和 undo 日志，执行事务操作但是不提交事务，然后返回ACK相应等待事务协调者的下一步通知，如果在询问阶段任意参与者返回不能执行操作的结果，那么事务协调者会向所有参与者发送事务中断请求。
DoCommit：根据 PreCommit 决定 DoCommit 的执行方式，如果每个参与者在 PreCommit 阶段都会返回成功，那么事务协调者会所有参与者发送事务提交指令，反之，如果任何一个参与者明确返回失败，则事务协调者会向所有参与者发送事务回滚指令。

三阶段提交协议与两阶段提交协议的不同点
增加一个 CanCommit 阶段：用于询问所有参与者是否可以执行事务操作并响应，它可以尽早发现无法执行操作而终止后续的行为
在准备阶段，事务协调者和参与者都引入了超时机制，如果超时则回滚
在提交阶段： 参与者在等待超时之后执行了commit操作，并且任务处于成功状态，这种情况下事务默认为成功的可能性很大。