分布式事物(2PC,3PC,CAP,柔性与刚性事物,LCN)
转载自 https://blog.csdn.net/lizhen1114/article/details/80110317
分布式事物解决方案
分布式事物产生原因:主要产生与在微服务系统中,数据库的垂直拆分或者是RPC远程调用,
不在同一个数据源中,而是多个数据源中,每个数据源的事物都是本地事物,互不影响。
所以当A服务的数据源的事物发生回滚,不会影响到B服务的数据源回滚,从而产生分布式事物问题,无法保证分布式通讯数据一致性问题。
分布式事物基本理论:基本遵循CPA理论或者Base理论,采用柔性事物特征,软状态或者最终一致性特点保证分布式事物一致性问题。
分布式事物常见解决方案:
1.2pc两段提交协议
2.3pc三段提交协议(弥补两端提交协议缺点)
3.TCC或者GTS(阿里)
4.消息中间件最终一致性
5.传统项目采用Jta(Java操作分布式事物XA接口)+atomikos 注意不适合于分布式常见、只适合多数据源情况下。
6.使用LCN解决分布式事物,理念“LCN并不生产事务,LCN只是本地事务的搬运工”。
2PC
2PC,将事务的提交过程分为:准备阶段和提交阶段。事务的发起者称协调者,事务的执行者称参与者。
阶段1:准备阶段
1、协调者向所有参与者发送事务内容,询问是否可以提交事务,并等待所有参与者答复。
2、各参与者执行事务操作,但不提交事务。
3、如参与者执行成功,给协调者反馈YES,即可以提交;如执行失败,给协调者反馈NO,即不可提交。
阶段2:提交阶段
此阶段分两种情况:所有参与者均反馈YES、或任何一个参与者反馈NO。
所有参与者均反馈YES时,即提交事务。
任何一个参与者反馈NO时,即中断事务。
提交事务:(所有参与者均反馈YES)
1、协调者向所有参与者发出正式提交事务的请求(即Commit请求)。
2、参与者执行Commit请求,并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后,即完成事务提交。
中断事务:(任何一个参与者反馈NO)
1、协调者向所有参与者发出回滚请求(即Rollback请求)。
2、参与者使用阶段1中的Undo信息执行回滚操作,并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后,即完成事务中断。
附如下示意图:
2PC的缺陷
1、同步阻塞:最大的问题即同步阻塞,即:所有参与事务的逻辑均处于阻塞状态。
2、单点:协调者存在单点问题,如果协调者出现故障,参与者将一直处于锁定状态。
3、脑裂:在阶段2中,如果只有部分参与者接收并执行了Commit请求,会导致节点数据不一致。
由于2PC存在如上同步阻塞、单点、脑裂问题,因此又出现了2PC的改进方案,即3PC。
3PC
3PC,三阶段提交协议,是2PC的改进版本,即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。
阶段1:CanCommit
1、协调者向参与者发出CanCommit请求,询问是否可以提交事务,并等待所有参与者答复。
2、参与者收到CanCommit请求后,如果认为可以执行事务操作,则反馈YES,否则反馈NO。
阶段2:PreCommit
此阶段分两种情况:
1、所有参与者均反馈YES,即执行事务预提交。
2、任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈,即中断事务。
事务预提交:(所有参与者均反馈YES时)
1、协调者向所有参与者发出PreCommit请求,进入准备阶段。
2、参与者收到PreCommit请求后,执行事务操作,但不提交事务。
3、各参与者向协调者反馈Ack响应或No响应,并等待最终指令。
中断事务:(任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈时)
1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求,或者在等待协调者请求过程中出现超时,参与者均会中断事务。
阶段3:do Commit
此阶段也存在两种情况:
1、所有参与者均反馈Ack响应,即执行真正的事务提交。
2、任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈,即中断事务。
提交事务:(所有参与者均反馈Ack响应时)
1、如果协调者处于工作状态,则向所有参与者发出do Commit请求。
2、参与者收到do Commit请求后,会正式执行事务提交,并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后,即完成事务提交。
中断事务:(任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈时)
1、如果协调者处于工作状态,向所有参与者发出abort请求。
2、参与者使用阶段1中的Undo信息执行回滚操作,并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后,即完成事务中断。
注意:进入阶段三后,无论协调者出现问题,或者协调者与参与者网络出现问题,都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时,参与者都会在等待超时之后,继续执行事务提交。
附示意图如下:
3PC的优点和缺陷
优点:降低了阻塞范围,引入了超时机制,在等待超时后协调者或参与者会中断事务。
缺陷:脑裂问题依然存在,即在参与者收到PreCommit请求后等待最终指令,如果此时协调者无法与参与者正常通信,会导致参与者继续提交事务,造成数据不一致。
分布式领域CAP理论
C(一致性), 数据一致更新,所有数据变动都是同步的
A(可用性), 好的响应性能(指系统能够很好的为用户服务,访问超时等用户体验不好的情况)
P(分区容忍性) 可靠性(遇到某节点或网络分区故障时,仍然能够对外提供满足一致性和可用性的服务。)
定理:任何分布式系统只可同时满足二点,没法三者兼顾。
关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区:
Atomicity原子性:一个事务中所有操作都必须全部完成,要么全部不完成。
Consistency一致性. 在事务开始或结束时,数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库,彼此不知晓。
Durability. 一旦事务完成,就不能返回。
跨数据库两段提交事务:2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,JavaEE中的JTA事务可以支持2PC。因为2PC是反模式,尽量不要使用2PC,使用BASE来回避。
BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性:
BASE思想主要强调基本的可用性,如果你需要High 可用性,也就是纯粹的高性能,那么就要以一致性或容忍性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。、
柔性事务和刚性事务
柔性事务满足BASE理论(基本可用,最终一致)
刚性事务满足ACID理论
柔性事务分为两阶段型,补偿型,异步确保型。最大努力通知型几种。
由于支付宝整个架构是SOA架构,因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要,以上几种事务类似就是针对分布式环境下业务需要设定的。
软状态:状态有一段时间可以不同步,异步的。
LCN分布式事务框架
框架介绍
LCN分布式事务框架其本身并不创建事务,而是基于对本地事务的协调从而达到事务一致性的效果。
核心步骤
- 创建事务组
是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象,然后拿到事务标示GroupId的过程。 - 添加事务组
添加事务组是指参与方在执行完业务方法以后,将该模块的事务信息添加通知给TxManager的操作。 - 关闭事务组
是指在发起方执行完业务代码以后,将发起方执行结果状态通知给TxManager的动作。当执行完关闭事务组的方法以后,TxManager将根据事务组信息来通知相应的参与模块提交或回滚事务。
LCN事务控制原理是由事务模块TxClient下的代理连接池与TxManager的协调配合完成的事务协调控制。
TxClient的代理连接池实现了javax.sql.DataSource
接口,并重写了close
方法,事务模块在提交关闭以后TxClient连接池将执行"假关闭"操作,等待TxManager协调完成事务以后在关闭连接。
分布式事物(2PC,3PC,CAP,柔性与刚性事物,LCN)相关推荐
- 【分布式事务】内容较多CAP/BASE/2PC/3PC/TCC/Sega等等等等~,一次性捋清楚
分布式事务 概述 什么是分布式事务 分布式事务就是指事务的资源分别位于分布式系统的不同节点之上的事务 分布式事务产生的原因 数据库分库分表 当业务数据量达到单库单表的极限时,就需要考虑分库分表,跨多个 ...
- 分布式理论 二阶段提交 2PC 3PC 端到端一致性 分布式事务
一.临界知识对我们学习的巨大帮助 临界知识这个概念,是我上个月读<好好学习:个人知识管理精进指南>这本书学到的概念,真的有被启发到,现在觉得它对于我们深刻了解世界有着非常大的作用. 所谓临 ...
- 分布式事务2PC、3PC模型
工作中使用最多的是本地事务,但是在对单一项目拆分为 SOA.微服务之后,就会牵扯出分布式事务场景 文章以分布式事务为主线展开说明,并且针对 2PC.3PC 算法进行详细的讲解,最后通过一个 Demo ...
- 事务 | Spring Cloud 分布式事务管理(二)2pc/3pc
Spring Cloud 分布式事务管理(二)2pc/3pc 上一篇 Spring Cloud 分布式事务管理 上一章,讲到了微服务带来的优点和缺点以及分布式事务的不确定性.这节说一下2pc/3pc ...
- 分布式事务,EventBus 解决方案:CAP【中文文档】
前言 很多同学想对CAP的机制以及用法等想有一个详细的了解,所以花了将近两周时间写了这份中文的CAP文档,对 CAP 还不知道的同学可以先看一下 .NET Core 事件总线,分布式事务解决方案:CA ...
- 2PC/3PC到底是啥
讨论 提到2PC/3PC首先想到的是它是一致性协议,而且经常把它和Paxos协议放在一起比较,并且经常看到这样的说法"世上只有一种一致性算法,那就是Paxos",2PC/3PC并不 ...
- 2PC/3PC、paxos与ZAB协议
为什么80%的码农都做不了架构师?>>> 2PC 即Two-phase Commit,参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还 ...
- 从分布式一致性谈到CAP理论、BASE理论
问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车 票, ...
- 有关2pc, 3pc,Tcc 的理解
对于分布式事务的概念,可能还会有很多同学不理解或者理解得不是很深刻的地方,在这篇文章中,作者打算重点给大家先介绍下分布式事务相关的基本概念,诸如2PC.3PC.TCC之类的基本问题. 1. 二阶段提交 ...
最新文章
- 三关节机械臂控制需求说明压缩文件中的相关文档说明
- 池化层:最大池化MaxPool、平均池化AvgPool、自适应池化AdaptiveMaxPool区别--基于pytorch框架
- RS232与串口通信的4个注意事项详解
- s4800扫描电镜的CSS3_Hitachi S-4800型场发射扫描电子显微镜+能谱
- openlayers根据坐标定位_车辆定位技术概述
- UVA1091 WF4786 Barcodes【编码检查】
- android编译单独image
- jQuery插件——自定义jQuery插件
- 动态规划——最大整除子集C++
- Puppet 笔记 package file services
- hdoj4540:威威猫系列故事——打地鼠(dp基础题-数塔思想)
- Water Tree CodeForces 343D 树链剖分+线段树
- 新春活动策划案例(共31份)
- python开发100个小程序_Python小程序100例
- vfp python_Visual Fox Pro和Python
- xp系统怎么关闭wmi服务器,教你win10系统wmi服务器怎么关闭
- 2022,一名85后程序猿之感慨,加油
- 一篇文章让你全面了解TDengine
- JavaScript注释(多行注释+单行注释)
- SIP协议详解(中文)-1