分布式事务简介以及利用Seata的解决方式

昵称不能为空8

已于 2022-08-18 10:23:08 修改

阅读量304

点赞数

文章标签：分布式数据库 sql

于 2022-08-18 10:16:35 首次发布

本文链接：https://blog.csdn.net/qq_42477029/article/details/126399196

版权

一.分布式事务基本理论

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

分布式事务无法同时实现CAP模式即 Consistency（一致性）、Availability （可用性）、Partition（分区） 。

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，之间就会出现数据不一致。

BASE理论是对CAP的一种解决思路，包含三个思想：

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

优点：相较于其他分布式事务服务，更加的高性能和简单易用

官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。

Seata事务管理中有三个重要的角色：

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构如图：

Seata基于上述架构提供了四种不同的分布式事务解决方案：

AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。
TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。
XA模式是分布式强一致性的解决方案，但性能低而使用较少。

无论哪种方案，都离不开TC，也就是事务的协调者。