分布式事务框架-seata初识

最新推荐文章于 2024-01-04 16:34:18 发布

编程微思

最新推荐文章于 2024-01-04 16:34:18 发布

阅读量1.5k

点赞数

本文链接：https://blog.csdn.net/songfei_dream/article/details/103822745

版权

一、事务与分布式事务

事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。

那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。

二、介绍

Seata:Simple Extensible Autonomous Transaction Architecture，简易可扩展的自治式分布式事务管理框架，其前身是fescar。阿里巴巴GTS的开源版实现，是一种分布式事务的解决方案。

三、架构

Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。
Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。
Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。
Config：用来存储和查找服务端的配置。
Lock：锁模块，用于给 Seata 提供全局锁的功能。
Rpc：用于和其他端通信。
HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。

四、工作流程

1)参与角色

Transaction Coordinator(TC)：管理全局的分支事务的状态，用于全局性事务的提交和回滚。
Transaction Manager(TM)：事务管理器，用于开启全局事务、提交或者回滚全局事务，是全局事务的开启者。
Resource Manager(RM)：资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接受TC的命令来提交或者回滚分支事务。

2)流程

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 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，所以性能较差。

Seata 在数据源做了一层代理层，所以我们使用 Seata 时，我们使用的数据源实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，主要是解析 SQL，把业务数据在更新前后的数据镜像组织成回滚日志，并将 undo log 日志插入 undo_log 表中，保证每条更新数据的业务 sql 都有对应的回滚日志存在。这样做的好处就是，本地事务执行完可以立即释放本地事务锁定的资源，然后向 TC 上报分支状态。当 TM 决议全局提交时，就不需要同步协调处理了，TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可，这个步骤非常快速地可以完成；当 TM 决议全局回滚时，RM 收到 TC 发送的回滚请求，RM 通过 XID 找到对应的 undo log 回滚日志，然后执行回滚日志完成回滚操作。