Seata分布式事务管理框架

目录

什么是分布式事务问题

CAP定理

BASE理论

解决分布式事务问题的思路

Seata框架 -- 介绍

Seata框架 -- TC事务协调者的部署

Seata框架 -- XA模式

Seata框架 -- AT模式

Seata框架 -- AT模式  -- 脏读解决方案

Seata框架 -- TCC模式

Seata框架 -- SAGA模式

四种模式的对比

---

什么是分布式事务问题

在分布式架构中,一般会有很多微服务与数据源,当程序对不同的微服务或数据源进行业务操作的时候,就需要所有的操作保证业务的原子性, 而不同的微服务有可能会出现问题而导致事务问题出现

CAP定理

CAP定理是1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

而这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

Consistency（一致性）:

        用户访问分布式系统中的任意节点，得到的数据必须一致。

Availability（可用性）:

        用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

Partition tolerance （分区容错性）:

        因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。在集群出现分区时，整个系统也要持续对外提供服务

为什么说CAP定理不能同时满足:

        分布式系统中,微服务一定会有概率出现单点故障, 此时就会出现 分区问题 ,而我们如果要保证 一致性 , 就要等待微服务修复,再让分布式系统对外提供服务,此时就导致 可用性 无法满足, 如果要保证 可用性 ,就会导致单点故障的那台微服务与其他微服务出现 一致性 问题. 

BASE理论

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

Basically Available （基本可用）：

        分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

Soft State（软状态）：

        在一定时间内，允许出现中间状态，比如临时的不一致状态。

Eventually Consistent（最终一致性）：

        虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

解决分布式事务问题的思路

根据CAP定理和BASE理论我们可以用两种模式解决问题

AP模式(高可用,低一致):

        各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致,可以保证服务的高可用

CP模式(高一致,低可用):

        各子事务执行后互相等待,同时提交,同时回滚,达到数据的高一致性,但会牺牲服务的可用性

两种模式都需要在子事务之间互相通信,才能实现事务的协调,所以需要一个事务协调器(TC),每个子事务被称为分支事务,它们在一起被称为全局事务;

Seata框架 -- 介绍

Seata框架是阿里巴巴开源出的一款分布式事务管理的组件 Seata官网

它的事务管理是由这三个角色配合工作实现的:

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局