分布式事务理论模型

分布式事务

  • 事务的概念,我们第一想到的应该是数据库的事务。所谓数据库事务就是只作为单个逻辑工作单元执行多个数据库操作的时候,数据库需要保证要么都成功,要么都失败,它必须满足ACID特性,即:

    • 原子性(Atomicity):事务必须是原子工作单元,不可继续分割,要么全部成功,要么全部是吧
    • 一致性(Consistency):事务完成时候,所有数据都必须保持一致
    • 隔离性(Isolation):由并发事务所做的修改必须与任何其他并发事务所做的修改隔离
    • 持久性(Durability):事务执行完成后,他对于系统的影响必须是永久代
  • 上面几点是针对单个数据库需要满足的特性。在微服务架构下,随着业务服务的拆分以及数据库的拆分,会存在以下这种场景,订单表与库存是在两个微服务下独立的数据库,当客户端发起一个订单的时候,需要在的那个的服务对数据库进行创建订单,同时库存也需要修改,这两个修改都是通过RPC通信调用。如下图:在这里插入图片描述

  • 在以上场景中,原本单库的操作变成多个数据库结合的事务操作,由于每个数据库事务执行情况只有本数据库知道,这样会导致订单库存数据与订单数据不一致的问题,比如创建订单成功但是扣减库存失败,会导致超卖商品的问题,这就是所谓的分布式事务问题 。

分布式事务理论模型

  • 分布式事务问题也就是保证分布式数据库数据一致性问题,简单说我们应该如何在分布式的场景下保证多个节点的数据一致性。分布式事务产生的核心原因在于存储资源的分布性,比如我们微服务情况下的分库分表,或者多存储媒介mySql,Redis等数据库的数据一致性,实际应用中,但是应该尽可能从设计层面避免分布式事务问题,因为任何一种解决方案都会增加系统复杂性
X/Open分布式事务模型
  • X/Open DTP(X/Open Distributed Transaction Processing Reference Model)是X/Open这个组织定义的一套分布式事务的标准。这个标准提出了使用两阶段提交(2PC,Two-Phase-Commit)来保证分布式事务的完整性。如下图X/Open包含如下几个角色:
    • AP:application 表应用程序
    • RM:Resource Manager 资源管理器,比如数据库
    • TM:Transaction Manager 表示事务管理器,一般指事务协调者,负责协调和管理事务,提供AP编程接口或管理RM,可以理解为Spring中提供的Transaction Manager。

在这里插入图片描述

  • 如上的角色与关系与本地事务的原理基本一样,唯一的不同在于,如果RM代表数据库,那么TM需要能够管理多个数据库的事务,如下:

    • 配置TM,将多个RM注册到TM上,相当于TM注册RM作为数据源。
    • AP从TM管理的RM中获取连接,如果RM是数据库则获取JDBC连接
    • AP向TM发起一个全局事务,生成全局事务ID(XID),XID会通知各个RM
    • AP通过第二步获得的连接直接操作RM完成数据库操作。这时候,AP的每次操作会吧XID传递给RM
    • AP结束全局事务,TM会通知各个RM全局事务结束
    • 根据各个RM的事务执行结果,执行提交或者回滚操作。
  • 我们用如下流程图来解释,实际上这里涉及全局事务概念。也就是说在原本单机事务下,会存在跨数据库事务的可见性问题,导致无法实现多借点事务的全局可控。而TM就是一个全局事务管理器,他可以管理多个资源管理器的事务。TM最终会根据各个分支事务的执行结果进行提交或者回滚。

在这里插入图片描述

  • 如上图所示,我们需要注意的是,TM和多个RM之间的事务控制,是基于XA协议(XA Speification)来完成的,XA协议是X/Open踢出的分布式事务处理规范,也是分布式事务处理的工业标准,定义了xa_ 和 ax_系列的函数原型以及功能描述,约束等。现在的主流数据库Oracle,MySql,DB2都实现了XA接口,所以他们都可以作为RM。
两阶段提交协议
  • 我们上面实现中RM实现了多个RM的事务管理,实际上会涉及到两个阶段的提交,第一节点,事务的准备阶段,第二阶段是事务的提交或者回滚阶段。这两个阶段都是由事务管理器发起的。两个阶段提交协议的流程如下。
    • 准备阶段:事务管理器(TM)通知资源管理器(RM)准备分支事务,记录事务日志,并告知事务管理器的准备结果。
    • 提交/回滚阶段:如果所有资源管理器(RM)在准备阶段都明确返回成功,则事务管理器(TM)向所有资源管理器(RM)发起事务提交指令完成数据变更。反之,如果任何一个资源管理器(RM)明确返回失败,则事务管理器(TM)会向所有资源管理器(RM)发送事务回滚指令。完整的执行流程如下图。

在这里插入图片描述

  • 两阶段提交将一个事务的处理过程分离两个过程,优点在于充分考虑到分布式系统的不可靠因素,并且采用非常简单的方式(两阶段提交)就把由于系统不可靠而导致的事务提交失败的概率降低到最小。当然也并不是完美,有如下缺陷:
    • 同步阻塞:从上图流程,所有参与者RM都必须是事务阻断类型的,对应任何一次指令都必须有明确的响应才可以进行下一步,期间其他的请求都会被阻塞,占用的资源会被锁定。
    • 过于保守:任何节点失败都会导致数据回滚。
    • 事务协调者的单点故障:如果协调者在第二阶段出现故障,那么其他的参与者RM,会一直处于锁定状态。
    • 脑裂,导致数据不一致问题:在第二阶段中,事务协调者向所有参与者RM发送commit请求后,发送局部网络异常导致只有一部分参与者RM接受到了commit请求,这部分参与者会发起commit,但是没有收到commit请求的节点由于事务无法提交,导致数据出现不一致问题。
三阶段提交
  • 三阶段提交协议是两阶段提交协议的改进版本,他利用超时机制解决了同步阻塞问题。三阶段提交协议的具体描述如下。
    • CanCommit(询问阶段):事务协调者向参与者发送事务执行请求,询问是否可以完成指令,参与者只需要回答是或者否,不需要真正做事务的操作,这个阶段会有超时终止机制。
    • PreCommit(准备阶段):事务协调者根据参与者的反馈结果决定是否继续执行,如果在询问阶段所有参与者都放回可以执行操作,则事务协调者会向所有参与者发送PreCommit请求,参与者收到请求后写redo和undo日志,执行事务操作,但是不提交事务,然后返回ACK响应等待事务协调者下一步通知,如果在询问阶段任意参与者返回不能执行操作的结果,那么事务协调者会向所有参与者发送事务中断请求。
    • DoCommit(提交或回滚阶段):这个阶段也会存在两种结果,任然根据上一步的执行结果来决定DoCommit执行方式。如果每个参与者在PreCommit都返回成功,那么事务协调者会向所有参与者发起事务提交指令,反正,如果参与者中任意参与者返回失败,那么事务协调者会发起终止指令来回滚事务。
  • 用如下图说明:

在这里插入图片描述

  • 三阶段提交与两阶段提交不同点:
    • 增加了一个CanCommit阶段,用于询问所有参与者是否可以执行事务操作并响应,他的好处是,可以尽早发现无法执行操作而中止后续的行为。
    • 在准备阶段后,事务协调者和参与者都引入超时机制,一旦超时,事务协调者和参与者都会继续提交事务,并且认为处于成功状态,因为这种情况下事务默认为成功的可能性较大。
  • 实际上一旦超时,在三阶段提交协议下仍然可能出现数据不一致的情况,当然概率比较小的。另外,比两阶段提交好的地方是基于超时机制来避免资源永久锁定。
CAP理论和BASE理论
  • 前面提到的两阶段提交和三阶段提交是XA协议解决分布式数据一致性问题的基本原理,但是这这两种方案为了保证数据的强一致性,降低了可用性,因为需要多数据库进行加锁,期间其他事务需要等待,也就是其他请求会被阻塞。实际上这里涉及分布式事务的两个理论模型。
CAP定理
  • CAP理论,又叫布尔理论,简单说他是指在分布式系统中不可能同时满足一致性(C:Consistency),可用性(A:Availability),分区容错性(P:Parition Tolerance)这三个基本需求,做多满足两个。

    • C:数据在多个副本中要保持强一致性,比如签名说的分布式数据一致性问题
    • A:系统对外提供的服务必须一致处于可用状态,在任何故障下,客户端都可能在合理的时间内获得服务端的非错误响应。
    • P:在分布式系统中遇到任何网络分区故障,系统仍然能够对外提供服务。
  • 网络分区概念:不同节点分布在不同子网络中时候,在内部网络正常的情况下,由于某些原因导致这些子节点之间出现网络不同的情况,导致整个系统切分成若干独立的区域,这就是网络分区。

  • CAP定理证明,在分布式系统中,要么满足CP,要么满足AP,不可能CAP,或者CA。

    • 原因在于网络通信不是绝对可靠,比如网络延迟,网络异常都会导致系统故障。而分布式系统技术出现网络故障也需要保证系统仍然能够正常多外服务,所以在分布式系统中,Parition Tolerance(分区容错)是必然的,也就是需要满足分区容错性,就没有强一致性了。
    • 如果是CA或者CAP这种情况,相当于网络100%可靠,否则出现网络分区情况时候,为保证数据一致性,必须拒绝客户请求,但是如果拒绝客户请求,就不满足A,所以,分布式系统更不可能选择CA,因此,只有AP或者CP两种。
    • AP:放弃强一致性,实现最终一致性,很多互联网公司解决分布式数据一致性问题的主要选择
    • CP,放弃高可用,实现强一致性,签名提到的两阶段提交,三阶段提交,可能导致的问题是用户完成一个操作会等待较长时间。
Base理论
  • Base理论是有CAp中一致性和可用性不可兼得衍生出来的一种新思想。

  • Base理论核心思想是通过牺牲数据强一致性获得高可用。他有如下三个特性

    • Basically Availiable(基本可用):分布式系统出现故障,允许损失一部分可用性保证核心功能
    • Soft State(软状态):允许系统中数据存在中间状态。这个状态不影响系统可用性,也就是允许系统中不同阶段数据副本之间同步存在延迟
    • Eventually Consistent(最终一致性):中介状态的数据进过一段时间后,会达到一个最终的数据一致性。
  • Base理论并没有要求数据强一致性,而是允许数据在一段时间内不一致,但是数据最终会在某个点实现一致,互联网产品中可用性相对来说重要一点,数据都是可以补充的,不会错就行。

  • 案例:在支付流程中,用户发起一个订单支付,不需要同步等待执行结果,系统会返回一个支付处理中的中间状态,对于用户来说,可以从订单列表中看到支付的处理结果。而对系统来说,第三方支付处理成功,在回调我们系统修改订单状态即可。这个场景中,虽然订单的支付状态与第三方支付状态不一致,当体验更好。

上一篇:SpringCloud Alibaba 框架下公司架构图
下一篇:分布式事务解决方案

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/310444.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

[MySQL基础]数据库的相关概念

DB: 数据库(database):存储数据的“仓库”,它保存了一系列有组织的数据。 DBMS: 数据库管理系统(Database Management System):数据库是通过DBMS创建和操作的容器。 SQL: 结构化查询语言(Structure Query Language):专门用来与数据库通信的语言。 SQL的优点: 1.几…

Linq下有一个非常实用的SelectMany方法,很多人却不会用

在平时开发中经常会看到有些朋友或者同事在写代码时会充斥着各种for,foreach,这种程式代码太多的话阅读性特别差,而且还显得特别累赘,其实在FCL中有很多帮助我们提高阅读感的方法,而现实中很多人不会用或者说不知道&am…

.NET Core前后端分离快速开发框架(Core.3.1+AntdVue)

引言时间真快,转眼今年又要过去了。回想今年,依次开源发布了Colder.Fx.Net.AdminLTE(254Star)、Colder.Fx.Core.AdminLTE(335Star)、DotNettySocket(82Star)、IdHelper(47Star),这些框架及组件都是本着以实际出发,实事求是的态度&…

数据结构与算法--查找与排序另类用法-旋转数组中的最小数字

查找与排序 查找 查找与排序都在程序设计中常被用到的算法。查找相对而言简单,一般都是顺序查找,二分查找,哈希表查找,和二叉排序树查找。其中二分查找是我必须熟悉的一种。哈希表和二叉排序树主要点在于他的数据结构而不是算法…

[MySQL基础]MySQL常见命令介绍

show databases; use 库名; show tables; show tables from 库名 select database(); create table 名字( id int, name varchar(20)); desc 表名; select * from 表名; insert into 表名 (a,b,…,f) values(1,2,3,…,7); update 库名 set name‘lilei’ where id1; delete f…

如何选择好公司

点击蓝字关注,回复“职场进阶”获取职场进阶精品资料一份前几天写了一篇文章:怎么判断自己在不在一家好公司。附带了一个投票调查,结果如下图:调研结果有点点扎心,有点点出乎我的意料。61%的小伙伴,都认为自…

数据结构与算法--再谈递归与循环(斐波那契数列)

再谈递归与循环 在某些算法中,可能需要重复计算相同的问题,通常我们可以选择用递归或者循环两种方法。递归是一个函数内部的调用这个函数自身。循环则是通过设置计算的初始值以及终止条件,在一个范围内重复运算。比如,我们求累加…

同步异步多线程这三者关系,你能给面试官一个满意的回答吗?

前几天一位朋友去面试,面试官问了他同步,异步,多线程之间是什么关系,异步比同步高效在哪?多线程比单线程高效在哪?由于回答的不好,让我帮他捋一下,其实回答这个问题不难,…

分布式事务框架seata

seata 前两篇文中总结了一下分布式事务已经现阶段常用的解决方案,现在来讨论一下现有的分布式事务框架seata,点击此处是seata的官网seata致力于微服务框架下提供高性能和简单易用的分布式事务服务。它提供了AT,TCC,Saga &#xf…

[一起读源码]走进C#并发队列ConcurrentQueue的内部世界 — .NET Core篇

在上一篇《走进C#并发队列ConcurrentQueue的内部世界》中解析了Framework下的ConcurrentQueue实现原理,经过抛砖引玉,得到了一众大佬的指点,找到了.NET Core版本下的ConcurrentQueue源码,位于以下地址:https://github.…

Java语法基础50题训练(上)

题目1: 有两只老虎,一只体重为180kg,一只体重为200kg,请用程序实现判断两只老虎的体重是否相同。 代码如下: public class OperatorTest {public static void main (String[] args) {int w1 180;int w2 200;boolean ans w1 w2?true:f…

EFCore.Sharding(EFCore开源分表框架)

简介本框架旨在为EF Core提供Sharding(即读写分离分库分表)支持,不仅提供了一套强大的普通数据操作接口,并且降低了分表难度,支持按时间自动分表扩容,提供的操作接口简洁统一.源码地址:EFCore.SHarding引言读写分离分库分表一直是数据库领域中的重难点,当数据规模达到单库极限的…

分布式事务 -- seata框架AT模式实现原理

Seata AT 模式 上一节中我们提到AT模式是基于XA事务模型演变过来的,所以他的整体机制也是一个改进版本的两阶段提交协议。 第一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和链接资源第二阶段:提交异步化&…

[Java基础]数据输入

Scanner使用的基本步骤: 1.导包: import java.util.Scanner;2.创建对象: Scanner sc new Scanner(System.in);3.接收数据: int i sc.nextInt();代码如下: import java.util.Scanner;public class OperatorTest {public static void main (String[] args) {//创建对象Scan…

k8s中流量分离以及资源隔离实战

源宝导读:明源云客的终端用户越来越多,也涌现出线上流量活动的场景,大量的访问和接口请求导致服务器出现较高负载。本文将介绍云客团队为了缓解服务器压力,通过K8S进行分流与资源隔离的实践过程。一、背景PaaS和B2C的主要客户云客…

怎样实现WPF Prism Module的国际化和本地化?

English | 简体中文上一篇有简单介绍主工程的国际化,使用的资源字典(XAML)实现的。这几天我添加了几个Prism模块(Module),发现子模块使用资源字典的方式实现国际化和本地化不好做,没有找到比较好的参考文章,所以换了一种方式&…

dotNET Core 3.X 使用 Jwt 实现接口认证

在前后端分离的架构中,前端需要通过 API 接口的方式获取数据,但 API 是无状态的,没有办法知道每次请求的身份,也就没有办法做权限的控制。如果不做控制,API 就对任何人敞开了大门,只要拿到了接口地址就可以…

数据结构与算法--代码鲁棒性案例分析

代码鲁棒性 鲁棒是robust的音译,就是健壮性。指程序能够判断输入是否符合规范,对不合要求的输入能够给出合理的结果。容错性是鲁棒的一个重要体现。不鲁棒的代码发生异常的时候,会出现不可预测的异常,或者程序奔溃。由于鲁棒性非…

【半译】两个gRPC的C#库:grpc-dotnet vs Grpc.Core

grpc-dotnet 是在2019年随着 .NET Core 3.0 一起发布的一个gPRC官方库。在ASP.NET Core 的 gRPC项目模板里面就使用了这个库。.NET Core 3.0之前难道不可以使用gRPC吗?目前,gRPC 在.NET上有两种官方实现:Grpc.Core:这个是原来的gR…