分布式事务

一：概念（什么是分布式事务）

在分布式环境上同样需要事务来保证数据的一致性。而因为跨数据源或跨服务环境所导致的传统事务不可用，形成的新的事务需求，这样的事务叫分布式事务。

 传统事务中，要想让多个操作属于同一事务，就需要使用同一个数据库连接Connection对象。但是在分布式环境下，通常是做不到这一点的，必须使用分布式事务

• 跨数据源的分布式事务：程序要操作不同服务器上的数据库

• 跨服务的分布式事务：程序要调用多个服务，每个服务都要操作数据库

• 以上两种情况的综合

 比如：

电商行业中比较常见的下单付款案例，包括下面几个行为：

• 创建新订单

• 扣减商品库存

• 从用户账户余额扣除金额

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

 

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

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

 小结：（什么是分布式事务）

在分布式项目架构的环境下，有些情况不能使用传统的本地事务来保证要成功都成功，要失败都失败

比如：

• 多个SQL操作跨数据源了：不属于同一个数据库连接，不属于同一个本地事务

• 多个SQL在不同服务上操作：不属于同一个数据库连接，不属于同一个本地事务

• 多个SQL操作既跨数据源，又跨服务了

二：CAP定理和BASE理论【重要】

1.CAP定理

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

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

Eric Brewer说：这三个指标不可能同时做到，这个结论就叫做 CAP 定理。

 

  一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项.

 1.1CAP三指标介绍

C 一致性：

一致性Consitency，即 用户访问分布式系统中的任意节点，得到的数据必须一致(业务上的一致）。这就要求节点之间必须要及时同步数据。

 比如：集群中有两个节点，初始数据是一致的；当修改了其中一个节点的数据时，要把数据变更立即同步到另外一个节点，保证所有节点的数据是一致的。

 A 可用性

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

 

P 分区容错性

分区Partition：因为网络故障或者其它原因，导致分布式系统中的部分节点与其它节点失联，形成独立分区

分区容错性Partition Tolerance，即 集群出现分区时，整个系统也要持续对外提供服务

 

 1.2CAP之间的矛盾

在分布式系统中，分区容错性(P)是必须要保证的。但C和A两个指标就互相矛盾

以上图为例：

• 因为网络原因形成了两个分区：node01和node02一个分区；node03一个分区

• 假如我们要修改node02上的数据：

  • 如果要追求一致性：必须等到node02把数据同步到node01、node03，才返回响应。但因为分区了，等待时间不确定，可能要长时间等待

  • 如果要追求可用性：修改了node02的数据就立即返回响应；但是不能保证数据同步到了node01和node03

所以CAP定理中，P必须保证，而C和A相互矛盾，只能保证一个。即：

• CP模式：舍弃可用性，追求一致性

• AP模式：舍弃一致性，追求可用性

 但是，难道AC的矛盾就不可调和吗？并不是，BASE理论就提出了完善和弥补的方案

 2.BASE理论

BASE理论，是对CAP定理中的CA矛盾进行权衡之后，提供的一种解决思路，其中是一种折中方案。这是指：

• 采用CP模式，追求一致性，舍弃一定的可用性：

  • BA (Basically Available)，基本可用：分布式系统在出现故障时，允许损失部分可用性，要保证核心可用

    响应时间的损失：比如原本要求0.5秒内响应，现在允许5秒内响应

    系统功能的损失：出现某些故障时，核心功能保证可用，部分非核心功能允许不可用

• 采用AP模式，追求可用性，对一致性采用一些补偿措施

  • S (Soft State)，软状态：在一定时间内，允许出现中间状态，比如 数据临时不一致

  • E (Eventually Consistent)，最终一致性：虽然无法保证强一致性，但是在软状态之后，最终达到数据一致

 三：Seata简介

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

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

 1.Seata架构

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

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

  是Seata本身

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开启全局事务、提交或回滚全局事务。

  负责事务的边界。指@GlobalTransactional注解

• RM (Resource Manager) - 资源管理器：处理分支事务的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

  指分支事务，指@Transactional注解

 

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

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入

• AT模式【必须会用】：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

• TCC模式：最终一致的分阶段事务模式，有业务侵入

• SAGA模式：长事务模式，有业务侵入

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