分布式事务(两阶段提交)模型详解

简介:

这一几天一直在回顾事务相关的知识,也准备把以前了解皮毛的知识进行一些深入总结,虽然这一些知识并没有用到,但是了解其实现原理还是很有必要的,因为知道了原理,你也能把它实现出来。

在上一节事务的编程模型里面,主要说明了三种编程模型,一般情况下,我们都接触的是单一资源的事务,也就是单独对一个数据库进行操作。如果需要跨多个资源保证事务一致性

举个例子:在ATM机取钱的时候,需要对用户的账户进行扣款处理,然后发送一条消息给消息服务器(假设消息服务器是用JMS实现的),由消息服务器异步通过短信通知用户。如果用户取款失败,那么消息服务器不应该发送短信给用户。如何保证 用户帐务扣款 和 消息服务器的消息保持一致性,也就是说 取款成功,消息服务器就持久化消息,然后发送短信给用户,取款失败,消息服务器就回滚消息,啥都不做。

在上面这种情况下,就需要使用分布式事务,也就是跨越多个资源的保证数据一致性。

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准,也就是了定义了规范和API接口,由这个厂商进行具体的实现。这个思想在java 平台里面到处都是。

X/Open DTP 定义了三个组件: AP,TM,RM

AP(Application Program):也就是应用程序,可以理解为使用DTP的程序

RM(Resource Manager):资源管理器,这里可以理解为一个DBMS系统,或者消息服务器管理系统,应用程序通过资源管理器对资源进行控制。资源必须实现XA定义的接口

TM(Transaction Manager):事务管理器,负责协调和管理事务,提供给AP应用程序编程接口以及管理资源管理器

其中,AP 可以和TM 以及 RM 通信,TM 和 RM 互相之间可以通信,DTP模型里面定义了XA接口,TM 和 RM 通过XA接口进行双向通信,例如:TM通知RM提交事务或者回滚事务,RM把提交结果通知给TM。AP和RM之间则通过RM提供的Native API 进行资源控制,这个没有进行约API和规范,各个厂商自己实现自己的资源控制,比如Oracle自己的数据库驱动程序。

 

下面一幅图说明了三者的关系:

 

其中在DTP定了以下几个概念:

事务:一个事务是一个完整的工作单元,由多个独立的计算任务组成,这多个任务在逻辑上是原子的。

全局事务:对于一次性操作多个资源管理器的事务,就是全局事务

分支事务:在全局事务中,某一个资源管理器有自己独立的任务,这些任务的集合作为这个资源管理器的分支任务

控制线程:用来表示一个工作线程,主要是关联AP,TM,RM三者的一个线程,也就是事务上下文环境。简单的说,就是需要标识一个全局事务以及分支事务的关系。

 

两阶段提交协议:如果一个事务管理器管理着多个资源管理器,如果控制全局事务和分支事务,在DTP里面说明两阶段提交的协议

第一阶段:准备阶段

事务管理器通知资源管理器准备分支事务,资源管理器告之事务管理器准备结果

第二阶段:提交阶段

事务管理器通知资源管理器提交分支事务,资源管理器告之事务管理器结果

下面一幅图演示了正常情况下的两阶段提交,

如果第一阶段某一个资源预提交失败,第二阶段就回滚第一阶段已经预提交成功的资源

 以上是比较正常的情况,但是由于RM有权利自己根据情况提交或者回滚自己的分支事务(官方说法是:Heuristic Decision)那三么就可能出现以下种情况:

1 在TM通知RM提交事务之前,RM分支事务已经提交

 

2 在TM通知RM提交事务之前,RM分支事务全部回滚

 

3 在TM通知RM提交事务之前,RM分支事务部分回滚

对于Heuristic Decision标记的分支事务,在没有TM通知RM forget 它之前,RM都必须保存分支事务的信息,等到TM从失败中恢复事务之后,通知RM forget 分支事务,这个时候RM才真正的完成事务。

对于前面两种情况来说,TM会比较好处理,做事务恢复的时候,要么标记全局事务成功,要么标记全局事务回滚,通知RM可以完成分支事务了。对于第三种情况,可能就需要进行决策了,这个具体怎么处理,貌似DTP并没有说明细节,可以交给应用自己去判断。

 

DTP编程模型

虽然DTP内部的实现比较复杂,但是对于DTP编程模型就比较简单了

1 AP通过TM获取事务

2 AP申明需要哪些RM,TM注册RM

3 AP使用RM完成分支事务

4 AP通过TM提交事务

5 TM通知RM提交事务

 

而DTP的服务的实现就需要考虑以下几个问题:

  • 如何获取TM?

  • 如何启动和结束一个事务

  • 如何标识一个事务

  • 如何保存和传递事务上下文

  • 应用如何通过资源管理器操作共享资源

  • 资源管理器如何实现准备阶段以及与提交阶段的逻辑

  • 如何实现两阶段提交协议

  • 如何实现在异常情况下进行事务恢复

其实如果把这几个问题了解清楚了,就可以自己实现一个两阶段提交的分布式事务模型了。

转自:http://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html

特别说明:尊重作者的劳动成果,转载请注明出处哦~~~http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt369
相关文章
|
10天前
|
机器学习/深度学习 数据可视化 TensorFlow
使用Python实现深度学习模型的分布式训练
使用Python实现深度学习模型的分布式训练
127 73
|
6月前
|
机器学习/深度学习 算法 PyTorch
深度学习分布式模型
深度学习分布式模型
|
5月前
|
存储 缓存 NoSQL
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
redis分布式锁、redisson、可重入、主从一致性、WatchDog、Redlock红锁、zookeeper;Redis集群、主从复制,全量同步、增量同步;哨兵,分片集群,Redis为什么这么快,I/O多路复用模型——用户空间和内核空间、阻塞IO、非阻塞IO、IO多路复用,Redis网络模型
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
|
1月前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
1月前
|
存储 分布式计算 负载均衡
分布式计算模型和集群计算模型的区别
【10月更文挑战第18天】分布式计算模型和集群计算模型各有特点和优势,在实际应用中需要根据具体的需求和条件选择合适的计算架构模式,以达到最佳的计算效果和性能。
70 2
|
2月前
|
存储 分布式计算 负载均衡
EMQ
|
5月前
|
传感器 人工智能 安全
EMQX 与 MQTT: AI 大模型时代的分布式数据中枢
在以数据为核心的 AI 时代,基于 MQTT 协议的消息服务器 EMQX 能帮助企业更好的利用人工智能和机器学习模型,是智能化系统中核心的数据基础软件。
EMQ
267 15
|
4月前
|
存储 NoSQL MongoDB
(四)成为分布式高手必经之路:理解那些工作在分布式系统底层的一致性模型
在分布式领域里,一致性成为了炙手可热的名词,缓存、数据库、消息中间件、文件系统、业务系统……,各类分布式场景中都有它的身影,因此,想要更好的理解分布式系统,必须要理解“一致性”这个概念。本文就展开聊聊 分布式系统里的一致性模型。
110 6
|
5月前
|
人工智能 PyTorch TensorFlow
分布式训练:大规模AI模型的实践与挑战
【7月更文第29天】随着人工智能的发展,深度学习模型变得越来越复杂,数据集也越来越大。为了应对这种规模的增长,分布式训练成为了训练大规模AI模型的关键技术。本文将介绍分布式训练的基本概念、常用框架(如TensorFlow和PyTorch)、最佳实践以及可能遇到的性能瓶颈和解决方案。
891 2
|
4月前
|
算法 异构计算
自研分布式训练框架EPL问题之帮助加速Bert Large模型的训练如何解决
自研分布式训练框架EPL问题之帮助加速Bert Large模型的训练如何解决

热门文章

最新文章