事务是保证数据库从一个一致性的状态永久地变成另外一个一致性状态的根本,其中,ACID是事务的基本特性。
A是Atomicity,原子性。一个事务往往涉及到许多的子操作,原子性则保证这些子操作要么都做,要么都不做,而不至于出现事务的部分操作成功,而另外一部分操作没有成功。如果事务在执行的过程中发生错误,那么数据库将回滚到事务发生之前的状态。比如银行的转账服务,这个事务的最终结果一定是:某个账户的余额增加了x,而另外一个账户的余额减少了x,或者两个账户的余额未发生变化。而不会出现其他情况。
C是Consistency,一致性。一致性是指事务发生前和发生以后,都不会破坏数据库的约束关系,保证了数据库元素的正确性、有效性和完整性。这种约束关系可以是数据库内部的约束,比如数据库元素的值必须在一定的范围内,也可以是应用带来的约束,比如转账以后银行账户的余额不能为负数。
I是Isolation,隔离性。一个事务的操作在未提交以前,是不会被并行发生的其他事务访问到的。也就是说,数据库操作不会看到某个事务的中间操作结果,比如转账过程中,用户是不能查询到一个账户余额减少了,而另外一个账户余额未发生变化的情况。
D是Durability,持久性。事务完成以后,它对数据库的影响是永久性的,即使在数据库系统发生宕机或者其他故障的情况下,这种影响也会得到保持。
实现分布式事务的关键就是两阶段提交协议。
在两阶段提交协议中,包含了两种角色:协调者与参与者。参与者就是实际处理事务的机器,而协调者就是其中一台单独的处理分布式事务的机器。
在此协议中,一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。此协议中的五个步骤如下:
•应用程序调用事务协调器中的提交方法。
•事务协调器将联络事务中涉及的每个资源管理器,并通知它们准备提交事务(这是第一阶段的开始)。
•为了以肯定的方式响应准备阶段,资源管理器必须将自己置于以下状态:确保能在被要求提交事务时提交事务,或在被要求回滚事务时回滚事务。大多数资源管理器会 将包含其计划更改的日记文件(或等效文件)写入持久存储区中。如果资源管理器无法准备事务,它会以一个否定响应来回应事务协调器。
•事务协调器收集来自资源管理器的所有响应。
•在第二阶段,事务协调器将事务的结果通知给每个资源管理器。如果任一资源管理器做出否定响应,则事务协调器会将一个回滚命令发送给事务中涉及的所有资源管理 器。如果资源管理器都做出肯定响应,则事务协调器会指示所有的资源管理器提交事务。一旦通知资源管理器提交,此后的事务就不能失败了。通过以肯定的方式响应第一阶段,每个资源管理器均已确保,如果以后通知它提交事务,则事务不会失败。
图 1 事务提交
图 2 事务被回滚
看一个典型的分布式事务场景。
业务场景描述: 用户购买商品,使用支付宝余额支付:
将提交分成两阶段进行的目的很明确,就是尽可能晚地提交事务,让事务在提交前尽可能地完成所有能完成的工作,这样,最后的提交阶段将是一个耗时极短的微小操作,这种操作在一个分布式系统中失败的概率是非常小的,也就是所谓的“网络通讯危险期”非常的短暂,这是两阶段提交确保分布式事务原子性的关键所在。
从两阶段提交的工作方式来看,很显然,在提交事务的过程中需要在多个节点之间进行协调,而各节点对锁资源的释放必须等到事务最终提交时,这样,比起一阶段提交,两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加,当事务的并发量达到一定数量的时候,就会出现大量事务积压甚至出现死锁,系统性能就会严重下滑。这就是使用XA事务
网络通讯危险期:
由于网络通讯故障随时可能发生,任何发出请求后等待回应的程序都会有失去联系的危险。这种危险发生在发出请求之后,服务器返回应答之前,如果在这个期间网 络通讯发生故障,发出请求一方无法收到回应,于是无法判断服务器是否已经成功地处理请求,因为收不到回应可能是请求没有成功地发送到服务器,也可能是服务 器处理完成后的回应无法传回请求方。这段时间称为网络通讯的危险期(In-doubt Time)。很显然,网络通讯的危险期是分布式系统除单点可靠性之外需要考虑的另一个可靠性问题。
两阶段提交协议最大的劣势是其通过阻塞完成的协议,在节点等待消息的时候处于阻塞状态,节点中其他进程则需要等待阻塞进程释放资源才能使用。如果协调器发生了故障,那么参与者将无法完成事务则一直等待下去。
以下情况可能会导致节点发生永久阻塞:
如果参与者发送同意提交消息给协调者,进程将阻塞直至收到协调器的提交或回滚的消息。如果协调器发生永久故障,参与者将一直等待,这里可以采用备份的协调器,所有参与者将回复发给备份协调器,由它承担协调器的功能。
如果协调器发送“请求提交”消息给参与者,它将被阻塞直到所有参与者回复了,如果某个参与者发生永久故障,那么协调器也不会一直阻塞,因为协调器在某一时间内还未收到某参与者的消息,那么它将通知其他参与者回滚事务。
同时两阶段提交协议没有容错机制,一个节点发生故障整个事务都要回滚,代价比较大。
基于此,后来有人提出了三阶段提交协议,在其中引入超时的机制,将阶段1分解为两个阶段:在超时发生以前,系统处于不确定阶段;在超时发生以后,系统则转入确定阶段。
- 大小: 6.2 KB
- 大小: 6.1 KB
- 大小: 63.2 KB
- 大小: 83.5 KB
分享到:
相关推荐
实现的一个简单2PC分布式事务框架,客户端与服务端通信使用Netty,市面上成熟的2PC分布式事务框架有:LCN,大致的处理流程都是按照这种方式来的,希望对于学习分布式事务的小伙伴有所帮助。
#资源达人分享计划#
NULL 博文链接:https://eleopard.iteye.com/blog/2107415
为了实现分布式事务,需要使用下面将介绍的两阶段提交协议。 * 阶段一:开始向事务涉及到的全部资源发送提交前信息。此时,事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务,则...
最全分布式事务视频课程详细...3.分布式事务解决方案之2PC(xa、seata) 4.分布式事务解决方案之TCC(hmily) 5.分布式事务解决方案之可靠消息最终一致性 6.分布式事务解决方案之最大努力通知 7.分布式事务综合案例分析
mysql索引,分布式事务,三阶段协议,b+树mysql索引,分布式事务,三阶段协议,b+树
基于Spring4.1.7+atomikos+mybaits 实现两阶段的分布式事务处理
交易中间件与数据库通过 XA 接口规范,使用两阶段提交来完成一个全局事务, XA 规范的基础是两阶段提交协议。 第一阶段是表决阶段,所有参与者都将本事务能否成功的信息反馈发给协调者;第二阶段是执行阶段,协调者...
这篇文章将介绍什么是分布式事务,分布式...相信耐心看完这篇文章,谈到分布式事务,不再只是有“2PC”、“3PC”、“MQ的消息事 务”、“最终一致性”、“TCC”等这些知识碎片,而是能够将知识连成一片,形成知识体系。
本文来自于csdn,本文主要从分布式的原因,事务特性,和解决方案中深入理解了分布式事务,希望对您的学习有所帮助。 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的...
java分布式事务demo
为了解决大家在实施分布式服务化架构过程中关于分布式事务问题的困扰,本教程将基于支付系统真实业务中的经典场景来对“可靠消息的最终一致性方案”、“TCC两阶段型方案”和“最大努力通知型方案”这3种柔性事务解决...
还有XA以及两阶段提交,并通过实例演示了使用JTA,通过两阶段提交,实现多数据源的事务实现。... 4-1 Spring事务机制_基本接口 4-2 Spring事务机制_实现 4-3 Jpa事务实例 4-4 Jms事务原理 4-5 Jms-session事务实例 4...
微服务架构的分布式事务处理方案
深入理解分布式事务
分布式事务ppt
spring+druid+AtomikosDataSource实现多数据源切换及分布式事务控制
分布式系统会把一个应用系统拆分为可独立部署的...分布式事务解决方案之两阶段提交;分布式事务解决方案之TCC;分布式事务解决方案之可靠消息最终一致性;分布式事务解决方案之最大努力通知;分布式事务综合案例分析;
自己封装redisson方法,同时通过注解的方式加入redis分布式事务锁,可靠。
详细讲解了通过消息来解决分布式事务的问题