首页 > 软件开发 > 架构

软件开发什么?你到现在都不知道什么是“分布式事务”?【内含Nacos+Spring cloud+Seata整合项目的开源代码】

admin 架构 2021-05-25 09:26:24 分布式 数据库 Java alibaba 
后台-系统设置-扩展变量-手机广告位-内容正文底部

在这里插入图片描述

目录——理论准备篇

      • 1.什么是事务
      • 2.本地事务
        • 2.1事务的4个特性“ACID”
      • 3.undo和redo
      • 4.分布式事务
        • 4.1跨数据源的分布式事务
        • 4.2跨服务的分布式事务
        • 4.3分布式系统存在的数据一致性的问题
      • 5.解决分布式事务的思路
        • 5.1CAP定理
        • 5.2Base理论
      • 6.分阶段提交
      • 7.TCC
      • 8. AT模式
      • 9. Nacos+Spring cloud+Seata整合项目

1.什么是事务

指的就是一个操作单元,在这个操作单元中的所有操作最终要保持一致的行为,要么所有操作都成功,要么所有的操作都被撤销。

举个栗子:去烧烤摊儿撸串,

第一个情景:你给老板30块钱,想要30个羊肉串;这时候城管来了,老板推着三轮跑了,你肯定要撵他把串要回来;

第二个情景:老板给你烤了30串要肉串,你拿着串撒腿就跑,老板肯定撵你;

所以古话说得好:“一手交钱,一手交货”,这就是一个事务(交钱给串);若是像上述两种情景事务就会回滚。

2.本地事务

你可以把事务想象成一件很“麻烦”的事情,它由很多琐事组成。再比如下面的情景 :

网购:包含 小名APP上下单、网上商城扣减库存、小名支付操作

2.1事务的4个特性“ACID”

在这里插入图片描述

1.原子性(Atomicity): 操作这些指令时,要么全部执行成功,要么全部不执行。只要其中一个指令执行失败,所有的指令都执行失败,数据进行回滚,回到执行指令前的数据状态。要么执行,要么不执行

2.一致性(Consistency): 事务的执行使数据从一个状态转换为另一个状态,数据库的完整性约束没有被破坏。能量守恒,总量不变

eg: A有50元,B有50元,如果在一个事务里A成功转给B50元,那么不管发生什么,那么最后A账户和B账户的数据之和必须是100元。

3.隔离性(Isolation): 隔离性是当多个用户并发访问数据库时,比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。信息彼此独立,互不干扰

eg: 对于任意两个并发的事务T1和T2,在事务T1看来,T2要么在T1开始之前就已经结束,要么在T1结束之后才开始,这样每个事务都感觉不到有其他事务在并发地执行。

4.持久性(Durability): 一旦事务提交了,那么事务对数据所做的变更就完全保存在了数据库中,即使发生停电,系统宕机也是如此。不会轻易丢失

3.undo和redo

其中原子性和持久性就要靠undo和redo 日志来实现。

回忆一下:

原子性:要么执行,要么不执行;

持久性:不会轻易丢失

Undo Log: 为了满足事务的原子性,在操作任何数据之前,首先将数据备份到Undo Log。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句,系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

Redo Log: 用于新数据的备份。记录更新后数据,用于保证事务的持久性,写到redo log中,即事务可提交。

假设有A、B两个数据,值分别为1,2
A. 事务开始.
B. 记录A=1到undo log buffer.
C. 修改A=3.
D. 记录A=3到redo log buffer.
E. 记录B=2到undo log buffer.
F. 修改B=4.
G. 记录B=4到redo log buffer.
H. 将undo log写入磁盘
I. 将redo log写入磁盘
J. 事务提交

4.分布式事务

随着互联网的快速发展,软件系统由原来的单体应用转变为分布式应用,下图描述了单体应用向微服务的演变:分布式系统会把一个应用系统拆分为可独立部署的多个服务,因此需要服务与服务之间远程协作才能完成事务操 作,这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务,例如订单微服务和库存微服务,下单的 同时订单微服务请求库存微服务减库存。

在这里插入图片描述

分布式事务,就是指不是在单个服务或单个数据库架构下,产生的事务:

  • 跨数据源的分布式事务
  • 跨服务的分布式事务

4.1跨数据源的分布式事务

随着业务数据规模的快速发展,数据量越来越大,单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分,将原单库单表拆分成数据库分片,于是就产生了跨数据库事务问题。

在这里插入图片描述

4.2跨服务的分布式事务

微服务之间通过远程调用完成事务操作。 比如:订单微服务和库存微服务,下单的 同时订单微服务请求库存微服务减库存。

在这里插入图片描述

4.3分布式系统存在的数据一致性的问题

提供服务的各个节点分布在不同机器上,相互之间通过网络交互,我们无法保障所有服务、数据库都百分百可用,有可能会出现部分服务、数据库执行成功,另一部分执行失败的问题。比如上面提过的网购情景:订单生成了,库存也扣减了,但是 用户账户的余额不足,这就造成数据不一致。

5.解决分布式事务的思路

接下来咱们来了解一下为什么分布式系统下,事务的ACID原则难以满足?

5.1CAP定理

在这里插入图片描述

CAP原则又叫CAP定理,同时又被称作布鲁尔定理(Brewer’s theorem),指的是在一个分布式系统中,不可能同时满足以下三点。

  • Consistency(一致性)
  • Availability(可用性)
  • Partition tolerance (分区容错性)

分区容忍性(Partition tolerance):分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,也就是说A和B可能因为各种意外情况,导致无法成功进行同步,分布式系统要能容忍这种情况。除非整个网络环境都发生了故障。

什么是分区?
在分布式系统中,不同的节点分布在不同的子网络中,由于一些特殊的原因,这些子节点之间出现了网络不通的状态,但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域。这就是分区。

CAP三者不可兼得,该如何取舍:

(1) CA: 优先保证一致性和可用性,放弃分区容错。 这也意味着放弃系统的扩展性,系统不再是分布式的,有违设计的初衷。

(2) CP: 优先保证一致性和分区容错性,放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法,一旦发生网络故障或者消息丢失,就会牺牲用户体验,等恢复之后用户才逐渐能访问。

(3) AP: 优先保证可用性和分区容错性,放弃一致性。跟CP一样,放弃一致性不是说一致性就不保证了,而是逐渐的变得一致。

5.2Base理论

BASE是三个单词的缩写:

  • Basically Available(基本可用)
  • Soft state(软状态)
  • Eventually consistent(最终一致性)

其核心思想是:

即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

还以上面的网购情景为例:

订单服务、库存服务、用户服务及他们对应的数据库就是分布式应用中的三个部分。

  • CP方式:现在如果要满足事务的强一致性,就必须在订单服务数据库锁定的同时,对库存服务、用户服务数据资源同时锁定。等待三个服务业务全部处理完成,才可以释放资源。此时如果有其他请求想要操作被锁定的资源就会被阻塞,这样就是满足了CP。

    这就是强一致,弱可用

  • AP方式:三个服务的对应数据库各自独立执行自己的业务,执行本地事务,不要求互相锁定资源。但是这个中间状态下,我们去访问数据库,可能遇到数据不一致的情况,不过我们需要做一些后补措施,保证在经过一段时间后,数据最终满足一致性。

    这就是高可用,但弱一致(最终一致)。

6.分阶段提交

1994 年,X/Open 组织(即现在的 Open Group )定义了分布式事务处理的DTP 模型。该模型包括这样几个角色:

  • 应用程序( AP ):我们的微服务
  • 事务管理器( TM ):全局事务管理者
  • 资源管理器( RM ):一般是数据库
  • 通信资源管理器( CRM ):是TM和RM间的通信中间件

在该模型中,一个分布式事务(全局事务)可以被拆分成许多个本地事务,运行在不同的AP和RM上。每个本地事务的ACID很好实现,但是全局事务必须保证其中包含的每一个本地事务都能同时成功,若有一个本地事务失败,则所有其它事务都必须回滚。但问题是,本地事务处理过程中,并不知道其它事务的运行状态。因此,就需要通过CRM来通知各个本地事务,同步事务执行的状态。

7.TCC

它本质是一种补偿的思路。事务运行过程包括三个方法,

  • Try:资源的检测和预留;
  • Confirm:执行的业务操作提交;要求 Try 成功 Confirm 一定要能成功;
  • Cancel:预留资源释放。

实例

执行分两个阶段:

  • 准备阶段(try):资源的检测和预留;
  • 执行阶段(confirm/cancel):根据上一步结果,判断下面的执行方法。如果上一步中所有事务参与者都成功,则这里执行confirm。反之,执行cancel

假设账户A原来余额是100,需要余额扣减30元。如图:
在这里插入图片描述

1)一阶段(Try):

1. 余额检查,并冻结用户部分金额,此阶段执行完毕,事务已经提交
2. 检查用户余额是否充足,如果充足,冻结部分余额
3. 在账户表中添加冻结金额字段,值为30,余额不变
2)二阶段
1. 提交(Confirm):真正的扣款,把冻结金额从余额中扣除,冻结金额清空
- 修改冻结金额为0,修改余额为100-30 = 70元
2. 补偿(Cancel):释放之前冻结的金额,并非回滚
- 余额不变,修改账户冻结金额为0

8. AT模式

2019年 1 月份,Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。可以看做是对TCC或者二阶段提交模型的一种优化,解决了TCC模式中的代码侵入、编码复杂等问题。

在 AT 模式下,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。

9. Nacos+Spring cloud+Seata整合项目

点击查看:整合实例篇

参考文章:

  1. https://www.cnblogs.com/dyzcs/p/13780668.html
  2. https://www.cnblogs.com/xinysu/p/6555082.html
  3. https://www.cnblogs.com/mingorun/p/11025538.html
  4. https://cloud.tencent.com/developer/article/1784386

如果觉得小名的这篇文章能够对您有一些帮助,希望您可以给小名,点赞👍、收藏、一键三连,您的支持是小名莫大的动力~ 感谢您的阅读,我们下篇再见👋~

文章来源:https://blog.csdn.net/Tianc666/article/details/117162345

后台-系统设置-扩展变量-手机广告位-内容正文底部
版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。
本文地址:https://www.jcdi.cn/jiagou/30797.html

留言与评论(共有 0 条评论)
   
验证码:
后台-系统设置-扩展变量-手机广告位-评论底部广告位

教程弟

https://www.jcdi.cn/

统计代码 | 京ICP1234567-2号

Powered By 教程弟 教程弟

使用手机软件扫描微信二维码