分布式事务有这一篇就够了!不能再多了

1. 基础概念1.1 什么是事务事务可以看做是一次大的活动,它由不同的小活动组成,这些活动要么全部成功,要么全部失败。1.2 本地事务在计算机系统中,更多的是通过关系型数据库来控制事务,这是利用数据库本身的事务特性来实现的,因此叫数据库事务,由于应用主要靠关系数据库来控制事务,而数据库通常和应用在同一个服务器,所以基于关系型数据库的事务又被称为本地事务。数据库事务的四大特性:ACID**A(Atomic):**原子性,构成事务的所有操作,要么都执行完成,要么全部不执行,不可能出现部分成功部分失败
摘要由CSDN通过智能技术生成

1. 基础概念

1.1 什么是事务

事务可以看做是一次大的活动,它由不同的小活动组成,这些活动要么全部成功,要么全部失败。

1.2 本地事务
在计算机系统中,更多的是通过关系型数据库来控制事务,这是利用数据库本身的事务特性来实现的,因此叫数据库事务,由于应用主要靠关系数据库来控制事务,而数据库通常和应用在同一个服务器,所以基于关系型数据库的事务又被称为本地事务。

数据库事务的四大特性:ACID

**A(Atomic):**原子性,构成事务的所有操作,要么都执行完成,要么全部不执行,不可能出现部分成功部分失败的情况。

**C(Consistency):**一致性,在事务执行前后,数据库的一致性约束没有被破坏。比如:张三向李四转 100 元,转账前和转账后的数据是正确状态这叫一致性,如果出现张三转出 100 元,李四账户没有增加 100 元这就出现了数 据错误,就没有达到一致性。

**I(Isolation):**隔离性,数据库中的事务一般都是并发的,隔离性是指并发的两个事务的执行互不干扰,一个事务不能看到其他事务的运行过程的中间状态。通过配置事务隔离级别可以比避免脏读、重复读问题。

**D(Durability):**持久性,事务完成之后,该事务对数据的更改会持久到数据库,且不会被回滚。

数据库事务在实现时会将一次事务的所有操作全部纳入到一个不可分割的执行单元,该执行单元的所有操作要么都成功,要么都失败,只要其中任一操作执行失败,都将导致整个事务的回滚。

1.3 分布式事务
随着互联网的快速发展,软件系统由原来的单体应用转变为分布式应用,下图描述了单体应用向微服务的演变:

分布式系统会把一个应用系统拆分为可独立部署的多个服务,因此需要服务与服务之间远程协作才能完成事务操作,这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务,例如用户注册送积分事务、创建订单减库存事务,银行转账事务等都是分布式事务。

我们知道本地事务依赖数据库本身提供的事务特性来实现,因此以下逻辑可以控制本地事务:

begin transaction;
    //1.本地数据库操作:张三减少金额
    //2.本地数据库操作:李四增加金额
commit transation;

但是在分布式环境下,会变成下边这样:

begin transaction;
    //1.本地数据库操作:张三减少金额
    //2.远程调用:让李四增加金额
commit transation;

可以设想,当远程调用让李四增加金额成功了,由于网络问题远程调用并没有返回,此时本地事务提交失败就回滚了张三减少金额的操作,此时张三和李四的数据就不一致了。

因此在分布式架构的基础上,传统数据库事务就无法使用了,张三和李四的账户不在一个数据库中甚至不在一个应用系统里,实现转账事务需要通过远程调用,由于网络问题就会导致分布式事务问题。

1.4 分布式事务产生的情景

跨JVM进程产生分布式事务

典型的场景就是微服务架构:微服务之间通过远程调用完成事务操作。比如:订单微服务和库存微服务,下单的同时订单微服务请求库存微服务减少库存。

2.跨数据库实例产生分布式事务

单体系统访问多个数据库实例当单体系统需要访问多个数据库(实例)时就会产生分布式事务。比如:用户信息和订单信息分别在两个MySQL实例存储,用户管理系统删除用户信息,需要分别删除用户信息及用户的订单信息,由于数据分布在不同的数据实例,需要通过不同的数据库链接去操作数据,此时产生分布式事务。

3.多服务访问同一个数据库实例

订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务,原因就是跨JVM进程,两个微服务持有了不同的数据库链接进行数据库操作,此时产生分布式事务。

2. 分布式事务基础理论

通过前面的学习,我们了解到了分布式事务的基础概念。与本地事务不同的是,分布式系统之所以叫分布式,是因为提供服务的各个节点分布在不同机器上,相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务,网络因素成为了分布式事务的考量标准之一。因此,分布式事务需要更进一步的理论支持,接下来,我们先来学习一下分布式事务的CAP理论。

2.1 CAP理论

2.1.1 理解CAP

CAP 是 Consistency、Availability、Partition tolerance 三个单词的缩写,分别表示一致性、可用性、分区容忍性。

下面为了方便对CAP理论的理解,我们结合电商系统中的一些业务场景来理解CAP。

如下图,是商品信息管理的执行流程:

整体执行流程如下
1.商品服务请求主数据库写入商品信息(添加商品、修改商品、删除商品)
2.主数据库向商品服务响应写入成功
3.商品服务请求从数据库读取商品信息

C - Consistency

一致性是指写操作后的读操作可以读取到最新的数据状态,当数据分布在多个节点上,从任意结点读取到的数据都是最新的状态。

上图中,商品信息的读写要满足一致性就是要实现如下目标:

商品服务写入主数据库成功,则向从数据库查询新数据也成功。
商品服务写入主数据库失败,则向从数据库查询新数据也失败。

如何实现一致性?

1.写入主数据库后要将数据同步到从数据库。
2.写入主数据库后,在向从数据库同步期间要将从数据库锁定,待同步完成后再释放锁,以免在新数据写入成功后,向从数据库查询到旧的数据。

分布式系统一致性的特点:

由于存在数据同步的过程,写操作的响应会有一定的延迟。
为了保证数据一致性会对资源暂时锁定,待数据同步完成释放锁定资源。
如果请求数据同步失败的结点则会返回错误信息,一定不会返回旧数据。

A - Availability

可用性是指任何事务操作都可以得到响应结果,且不会出现响应超时或响应错误。

上图中,商品信息读取满足可用性就是要实现如下目标:

1.从数据库接收到数据查询的请求则立即能够响应数据查询结果。
2.从数据库不允许出现响应超时或响应错误。

如何实现可用性

1.写入主数据库后要将数据同步到从数据库。
2.由于要保证从数据库的可用性,不可将从数据库中的资源进行锁定。
3.即时数据还没有同步过来,从数据库也要返回要查询的数据,哪怕是旧数据,如果连旧数据也没有则可以按照约定返回一个默认信息,但不能返回错误或响应超时。

分布式系统可用性的特点:所有请求都有响应,且不会出现响应超时或响应错误

P - Partition tolerance

通常分布式系统的各各结点部署在不同的子网,这就是网络分区,不可避免的会出现由于网络问题而导致结点之间通信失败,此时仍可对外提供服务,这叫分区容忍性。

上图中,商品信息读写满足分区容忍性就是要实现如下目标:
1.主数据库向从数据库同步数据失败不影响读写操作。
2.其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性?

1.尽量使用异步取代同步操作,例如使用异步方式将数据从主数据库同步到从数据,这样结点之间能有效的实现松耦合。
2.添加从数据库结点,其中一个从结点挂掉其它从结点提供服务。

分布式分区容忍性的特点:分区容忍性分是布式系统具备的基本能力

2.1.2 CAP组合方式

上边商品管理的例子是否同时具备 CAP 呢?

在所有分布式事务场景中不会同时具备 CAP 三个特性,因为

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值