十堰响应式网站建设,海外网站开发,建设项目从哪个网站可以查,对外宣传及网站建设文件稿刚性事务
1.DTP模型
X/Open组织介绍
X/OPEN是一个组织#xff08;现在的open group#xff09;X/Open国际联盟有限公司是一个欧洲基金会#xff0c;它的建立是为了向UNIX环境提供标准。它主要的目标是促进对UNIX语言、接口、网络和应用的开放式系统协议的制定。它还促进在…刚性事务
1.DTP模型
X/Open组织介绍
X/OPEN是一个组织现在的open groupX/Open国际联盟有限公司是一个欧洲基金会它的建立是为了向UNIX环境提供标准。它主要的目标是促进对UNIX语言、接口、网络和应用的开放式系统协议的制定。它还促进在不同的UNIX环境之间的应用程序的互操作性以及支持对电气电子工程师协会IEEE对UNIX的可移植操作系统接口POSIX规范
主要成员 DTP模型介绍
X/Open DTPDistributed Transaction Process是一个分布式事务模型。这个模型主要使用了两段提交2PC - Two-Phase-Commit来保证分布式事务的完整性
这套标准主要定义了实现分布式事务的规范和API具体的实现则交给相应的⼚商来实现
X/Open提供的参考文档
DTP 参考模型http://pubs.opengroup.org/onlinepubs/9294999599/toc.pdfDTP XA规范http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf
相关概念
事务⼀个事务就是⼀个完整的⼯作单元具备ACID特性全局事务由事务管理器管理的事务能够⼀次性操作多个资源管理器分⽀事务由事务管理器管理的全局事务中每个资源管理器中独⽴执⾏的事务控制线程执⾏全局事务的线程这个线程⽤来关联应⽤程序、事务管理器和资源管理器 三者之间的关系也就是表示全局事务和分⽀事务的关系通常称为事务上下⽂环境
核心组件
AP应用程序Application Program用于定义事务边界即定义事务的开始和结束并且在事务边界内对资源进行操作可以理解为参与DTP分布式事务模型的应⽤程序RM资源管理器Resource Manager可以理解为数据库管理系统或消息服务管理器。应⽤程序可以通过资源管理器对相应的资源进⾏有效的控制。相应的资源需要实现XA定义的接⼝TM事务管理器Transaction Manager负责分配事务唯一标识监控事务的执行进度并负责全局事务的提交、回滚等为应⽤程序提供编程接⼝CRM不重要通信资源管理器Communication Resource Manager控制一个TM域TM domain内或者跨TM域的分布式应用之间的通信CP不重要通信协议Communication Protocol提供CRM提供的分布式应用节点之间的底层通信服务
注意
DTP模型定义了XA接⼝TM和RM能够通过XA接⼝进⾏双向通信。TM控制着全局事务管理事务的⽣命周期并协调资源。 RM控制和管理实际的资源一个DTP模型实例至少有3个组成部分AP、RM、TM也叫做DTP本地模型实例
执行流程 2.两阶段提交协议2PC
为什么会诞生2PC和3PC
在分布式系统中会有多个机器节点每一个机器节点虽然能够明确地知道自己在进行事务操作过程中的结果是成功或失败但无法直接获取到其他分布式节点的操作结果因此当一个事务操作需要跨越多个分布式节点的时候为了保证事务处理的ACID特性就需要引入一个“协调者”的组件来统一调度所有分布式节点的执行逻辑这些被调度的节点则称为“参与者”协调者负责调度参与者的行为并最终决定这些参与者是否要把事务真正进行提交。基于这个思想就衍生了二阶段提交和三阶段提交两种协议
介绍
2PC是Two Phase Commit缩写即两阶段提交。准备阶段Prepare phase、提交阶段commitphase。是计算机网络尤其是数据库领域中为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法通常2PC也被认为是一种一致性协议用来保证分布式系统数据的一致性目前绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的利用该协议能够非常方便地完成所有分布式事务参与者的协调统一决定事务的提交和回滚从而能够有效地保证分布式数据的一致性
角色
协调者Coordinater事务管理器TM参与者participants资源管理器RM
整体执行流程 Prepare阶段
事务询问协调者向所有的参与者发送事务内容询问是否可以执行事务提交请求并开始等待各参与者的响应执行事务但不提交各参与者节点执行事务操作并将Undo和Redo信息记入事务日志中参与者向协调者反馈事务询问的响应如果参与者成功执行了事务操作那么就反馈给协调者Yes的响应表示事务可以执行。如果参与者没有成功执行事务就返回No给协调者表示事务不可执行。还有可能参与者根本没接收到事务询问所以没有响应 Commit阶段之执行事务
发送提交请求协调者向所有参与者发出commit请求事务提交参与者收到commit请求后会正式执行事务提交操作并在完成提交之后释放整个事务执行期间占用的事务资源反馈事务提交结果参与者在完成事务提交之后向协调者发送Ack信息完成事务协调者接收到所有参与者反馈的Ack信息后完成事务 Commit阶段之回滚事务
发送回滚请求协调者向所有参与者发出Rollback请求事务回滚参与者接收到Rollback请求后会利用其在阶段一中记录的Undo信息来执行事务回滚操作并在完成回滚之后释放在整个事务执行期间占用的资源反馈事务回滚结果参与者在完成事务回滚之后向协调者发送Ack信息中断事务协调者接收到所有参与者反馈的Ack信息后完成事务中断 问题
同步阻塞问题在二阶段提交的执行过程中所有参与该事务操作的逻辑都处于阻塞状态也就是说各个参与者在等待其他参与者响应的过程中无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能单点故障问题协调者在整个二阶段提交过程中很重要如果协调者在提交阶段出现问题那么整个流程将无法运转更重要的是其他参与者将会处于一直锁定事务资源的状态中而无法继续完成事务操作数据不⼀致问题假设当协调者向所有的参与者发送commit请求之后发生了局部网络异常或者是协调者在尚未发送完所有commit请求之前自身发生了崩溃导致最终只有部分参与者收到了commit请求。这将导致严重的数据不一致问题过于保守如果在事务询问中参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话这时协调者只能依靠其自身的超时机制来判断是否需要中断事务显示这种策略过于保守。换句话说二阶段提交协议没有设计较为完善的容错机制任意一个节点失败都会导致整个事务的失败
使用场景
单个服务操作多个数据库并发不高
3.三阶段提交协议3PC
介绍
3PC全称“three phase commit”是2PC的改进版将2PC的“提交事务请求”过程一分为二共形成了由CanCommitPreCommit和doCommit三个阶段组成的事务处理协议
相比于二阶段提交改进的地方
在协调者与参与者都引入了超时机制在2PC中只有协调者拥有超时机制既如果在一定时间内没有收到参与者的消息则默认失效当进入第三阶段由于网络超时等原因虽然参与者没有收到commit或abort响应但是它有理由相信成功提交的几率很大
整体流程 CanCommit阶段
事务询问协调者向所有的参与者发送一个包含事务内容的canCommit请求询问是否可以执行事务提交操作并开始等待各参与者的响应各参与者向协调者反馈事务询问的响应参与者在接收到来自协调者的包含了事务内容的canCommit请求后正常情况下如果自身认为可以顺利执行事务则反馈Yes响应并进入预备状态否则反馈No响应
PreCommit阶段之执行事务预提交
发送预提交请求协调者向所有参与者节点发出preCommit请求并进入prepared阶段事务预提交参与者接受到preCommit请求后会执行事务操作并将Undo和Redo信息记录到事务日志中各参与者向协调者反馈事务执行的结果若参与者成功执行了事务操作那么反馈Ack同时等待最终的指令提交或终止
PreCommit阶段之执行中断事务
发送中断请求协调者向所有参与者发出abort请求中断事务无论是收到来自协调者的abort请求或者等待协调者请求过程中超时参与者都会中断事务
DoCommit阶段之执行事务提交
发送提交请求进入这一阶段假设协调者处于正常工作状态并且它接收到了来自所有参与者的Ack响应那么它将从预提交状态转换为提交状态并向所有的参与者发送doCommit请求事务提交参与者接收到doCommit请求后会正式执行事务提交操作并在完成提交之后释放整个事务执行过程中占用的事务资源反馈事务提交结果参与者在完成事务提交后向协调者发送Ack响应完成事务协调者接收到所有参与者反馈的Ack消息后完成事务
DoCommit阶段之中断事务
发送中断请求协调者向所有的参与者节点发送abort请求事务回滚参与者接收到abort请求后会根据记录的Undo信息来执行事务回滚并在完成回滚之后释放整个事务执行期间占用的资源反馈事务回滚结果参与者在完成事务回滚后向协调者发送Ack信息中断事务协调者接收到所有参与者反馈的Ack信息后中断事务
进入阶段三可能会出现两种故障
协调者出现问题协调者和参与者之间的网络故障
如果出现了任意一种情况最终都会导致参与者无法收到doCommit请求或者abort请求针对这种情况参与者都会在等待超时之后继续进行事务提交
优缺点
优点
相比较于2PC最大的优点就是降低了参与者的阻塞范围(第一个阶段是不阻塞的)其次能够在单点故障后继续达成一致2PC在提交阶段会出现此问题而3PC会根据协调者的状态进行回滚或提交
缺点
阶段三发送abort请求的时候出现了网络分区有的节点收到了abort请求有的没有此时协调者所在的节点和参与者所在的节点无法进行正常的网络通信那么参与者等待超时后会进行事务的提交这必然会出现分布式数据不一致的问题
4.XA协议
作用
XA规范的最主要的作用是就是定义了RM-TM的交互接口下图更加清晰了演示了XA规范在DTP模型中发挥作用的位置从下图中可以看出来XA仅仅出现在RM和TM的连线上 官方说法
XA 规范 是 X/Open 组织定义的分布式事务处理DTPDistributed Transaction Processing标准XA 规范 描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范 的目的是允许的多个资源如数据库应用服务器消息队列等在同一事务中访问这样可以使 ACID 属性跨越应用程序而保持有效XA 规范 最终完成两阶段提交2PCTwo-Phase Commit协议来保证所有资源同时提交或回滚任何特定的事务XA 规范 在上世纪 90 年代初就被提出。目前几乎所有主流的数据库都对 XA 规范 提供了支持
常见的误解
有些人可能会误认为两阶段提交协议是在XA规范中提出来的。事实上 两阶段协议是在OSI TP标准中提出的在DTP参考模型中指定了全局事务的提交要使用two-phase commit协议而XA规范只是定义了两阶段提交协议中需要使用到的接口也就是上述提到的RM-TM交互的接口因为两阶段提交过程中的参与方只有TM和RMs
介绍
XA规范XA Specification 是X/OPEN 提出的分布式事务处理规范。XA则规范了TM与RM之间的通信接口在TM与多个RM之间形成一个双向通信桥梁从而在多个数据库资源下保证ACID四个特性。目前知名的数据库如Oracle, DB2,mysql等都是实现了XA接口的都可以作为RM
XA是数据库的分布式事务强一致性在整个过程中数据一直锁住状态即从prepare到commit、rollback的整个过程中TM一直把持这数据库的锁如果有其他人要修改数据库的该条数据就必须等待锁的释放存在长事务风险
准确讲XA是一个规范、协议它只是定义了一系列的接口只是目前大多数实现XA的都是数据库或者MQ所以提起XA往往多指基于资源层的底层分布式事务解决方案。其实现在也有些数据分片框架或者中间件也支持XA协议毕竟它的兼容性、普遍性更好
规定中RM提供的接口
xa_openxa_close建立和关闭与资源管理器的连接xa_startxa_end开始和结束一个本地事务xa_preparexa_commitxa_rollback预提交、提交和回滚一个本地事务xa_recover回滚一个已进行预提交的事务ax_开头的函数使资源管理器可以动态地在事务管理器中进行注册并可以对XIDTRANSACTION IDS进行操作ax_regax_unreg允许一个资源管理器在一个TMSTRANSACTION MANAGER SERVER中动态注册或撤消注册
XA各个阶段的处理流程 支持XA协议的常见分布式事务框架
AtomikosSeata
5.JTA规范
规范下载地址
https://download.oracle.com/otn-pub/jcp/jta-1.1-spec-oth-JSpec/jta-1_1-spec.pdf?AuthParam1678249590_c72c2e509ad94b22138dce2f61f66b12
介绍
它是JavaEE的13个规范之一
Java事务API/Java平台事务规范JTAJava Transaction API和它的同胞Java事务服务JTSJava Transaction Service为J2EE平台提供了分布式事务服务distributed transaction的能力。 某种程度上可以认为JTA规范是XA规范的Java版其把XA规范中规定的DTP模型交互接口抽象成Java接口中的方法并规定每个方法要实现什么样的功能
JTA是基于XA架构上建模的在JTA 中事务管理器抽象为javax.transaction.TransactionManager接口并通过底层事务服务即JTS实现。像很多其他的java规范一样JTA仅仅定义了接口
JTA的常见实现
JTA规范规定事务管理器的功能应该由application server提供如EJB Server。一些常见的其他web容器如jboss、weblogic、websphere等都可以作为application server这些web容器都实现了JTA规范。特别需要注意的是并不是所有的web容器都实现了JTA规范如tomcat并没有实现JTA规范因此并不能提供事务管理器的功能
J2EE容器所提供的JTA实现JBoss独立的JTA实现如JOTMAtomikos这些实现可以应用在那些不使用J2EE应用服务器的环境里用以提供分布事事务保证。如TomcatJetty以及普通的java应用
接口定义
依赖
JTA是java扩展包在应用中需要额外引入相应的jar包依赖
dependencygroupIdjavax.transaction/groupIdartifactIdjta/artifactIdversion1.1/version
/dependency重要类含义 JTA规范中定义的这些接口并不需要应用程序的开发人员去实现。而是由各个厂商去实现根据在DTP模型中扮演的不同角色需要实现不同的接口 javax.transaction.Status事务状态这个接口主要是定义一些表示事务状态的常量此接口无需实现javax.transaction.Synchronization同步javax.transaction.Transaction事务javax.transaction.TransactionManager事务管理器javax.transaction.UserTransaction用于声明一个分布式事务javax.transaction.TransactionSynchronizationRegistry事务同步注册javax.transaction.xa.XAResource定义RM提供给TM操作的接口javax.transaction.xa.Xid事务id
TM供应商
实现UserTransaction、TransactionManager、Transaction、TransactionSynchronizationRegistry、Synchronization、Xid接口通过与XAResource接口交互来实现分布式事务。此外TM厂商如果要支持跨应用的分布式事务那么还要实现JTS规范定义的接口
常见的TM提供者包括我们前面提到的application server包括:jboss、ejb server、weblogic等以及一些以第三方类库形式提供事务管理器功能的jotm、Atomikos
RM供应商
XAResource接口需要由资源管理器者来实现XAResource接口中定义了一些方法这些方法将会被TM进行调用如
start方法开启事务分支end方法结束事务分支prepare方法准备提交commit方法提交rollback方法回滚recover方法列出所有处于PREPARED状态的事务分支一些RM提供者可能也会提供自己的Xid接口的实现
此外不同的资源管理器有一些各自的特定接口要实现
如JDBC2.0规范定义支持分布式事务的jdbc driver需要实现javax.sql.XAConnection、javax.sql.XADataSource接口JMS1.0规范规定支持分布式事务的JMS厂商需要实现javax.jms.XAConnection、javax.jms.XASession接口
注意
作为DTP模型中Application开发者的我们并不需要去实现任何JTA规范中定义的接口只需要使用TM提供的UserTransaction实现来声明、提交、回滚一个分布式事务即可
使用案例
需要注意的是在分布式事务中当我们需要提交或者回滚一个事务时不应该再使用Connection接口提供的commit和rollback方法。而是应该使用UserTransaction接口的commit接口和rollback接口替代。
另外在本案例中我们并没有说明UserTransaction实例是如何构建的这是由事务管理器TM实现者提供的而目前我们还没有接触过任何事务管理器
UserTransaction userTransaction...try{//开启分布式事务userTransaction.begin(); //执行事务分支1conn1 db1.getConnection();ps1 conn1.prepareStatement(INSERT into user(name,age) VALUES (tianshouzhi,23));ps1.executeUpdate();//执行事务分支2conn2 db2.getConnection();ps2 conn2.prepareStatement(INSERT into user(name,age) VALUES (tianshouzhi,23));ps2.executeUpdate();//提交两阶段提交发生在这个方法内部userTransaction.commit();}catch (Exception e){try {userTransaction.rollback();//回滚} catch (SystemException ignore) {}}6.JTS规范
事务是编程中必不可少的一项内容基于此为了规范事务开发Java增加了关于事务的规范即JTA和JTS
JTA定义了一套接口其中约定了几种主要的角色TransactionManager、UserTransaction、Transaction、XAResource并定义了这些角色之间需要遵守的规范如Transaction的委托给TransactionManager等
JTS也是一组规范上面提到JTA中需要角色之间的交互那应该如何交互JTS就是约定了交互细节的规范
总体上来说JTA更多的是从框架的角度来约定程序角色的接口而JTS则是从具体实现的角度来约定程序角色之间的接口两者各司其职
7.Atomikos分布式事务
Atomikos公司旗下有两款著名的分布事务产品
TransactionEssentials开源的免费产品ExtremeTransactions商业版需要收费
这两个产品的关系如下图所示 XA的主要限制
必须要拿到所有数据源而且数据源还要支持XA协议。目前MySQL中只有InnoDB存储引擎支持XA协议性能比较差要把所有涉及到的数据都要锁定是强一致性的会产生长事务
