微服务_4.分布式事务

珍珠是蚌的眼泪

已于 2024-10-05 11:38:29 修改

阅读量436

点赞数 8

分类专栏：微服务文章标签：微服务分布式事务 CAP BASE Seata

于 2024-10-05 10:30:39 首次发布

本文链接：https://blog.csdn.net/qq_43563660/article/details/142711697

版权

微服务专栏收录该内容

6 篇文章 0 订阅

订阅专栏

文章目录

一、分布式事务问题
- 1.1、本地事务
- 1.2、分布式事务
二、分布式事务理论基础
三、Seata
- 3.1、Seata的架构

一、分布式事务问题

1.1、本地事务

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

在这里插入图片描述

1.2、分布式事务

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

创建新订单
扣减商品库存
从用户账户余额扣除金额

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

在这里插入图片描述
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。如果出现如下情况：假设此时库存不足但是余额足，就会导致库存服务失败，但是创建订单和扣减余额服务仍然成功，此时分布式事务就出现了问题。当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

二、分布式事务理论基础

2.1、CAP定理

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

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

在这里插入图片描述
它们的第一个字母分别是 C、A、P。Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

2.1.1、一致性

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

比如现在包含两个节点，其中的初始数据是一致的：

在这里插入图片描述
当我们修改其中一个节点的数据时，两者的数据产生了差异：

在这里插入图片描述
要想保住一致性，就必须实现node01到node02的数据同步：

在这里插入图片描述

2.1.2、可用性

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

如图，有三个节点的集群，访问任何一个都可以及时得到响应：

在这里插入图片描述

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：

在这里插入图片描述

2.1.3、分区容错

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

在这里插入图片描述

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2.1.4、矛盾点

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务又必须对外保证服务。因此Partition Tolerance不可避免。当左边节点接收到新的数据变更时，由于无法完成数据同步，就会出现问题了：

在这里插入图片描述

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用，满足不了高可用性。
如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。

也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

2.2、BASE理论

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

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

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

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

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

在这里插入图片描述
这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

三、Seata

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

3.1、Seata的架构

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

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

整体的架构如图：

在这里插入图片描述
Seata基于上述架构提供了四种不同的分布式事务解决方案：