X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准,也就是了定义了规范和API接口,由这个厂商进行具体的实现
DTP模式规定了三种角色:
- AP:Application应用系统
- TM(协调者):Transaction Manager事务管理器
- RM(参与者):Resource Manager资源管理器
三者的关系:
其中在DTP定了以下几个概念:
- 事务:一个事务是一个完整的工作单元,由多个独立的计算任务组成,这多个任务在逻辑上是原子的。
- 全局事务:对于一次性操作多个资源管理器的事务,就是全局事务
- 分支事务:在全局事务中,某一个资源管理器有自己独立的任务,这些任务的集合作为这个资源管理器的分支任务
- 控制线程:用来表示一个工作线程,主要是关联AP,TM,RM三者的一个线程,也就是事务上下文环境。简单的说,就是需要标识一个全局事务以及分支事务的关
整个事务提交分两个阶段:
- 阶段一:表决阶段,所有参与者都将本事务执行预提交,并将能否成功的信息反馈发给协调者
- 阶段二:执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地执行提交或回滚
注:2PC的传统方案是在数据库层面实现的,如Oracle,Mysql都支持2PC协议,为了统一标准减少行业内不必要的对接成本
以上是比较二阶段提交协议正常的情况,但是由于RM有权利自己根据情况提交或者回滚自己的分支事务(官方说法是:Heuristic Decision)那三么就可能出现以下种情况:
- 在TM通知RM提交事务之前,RM分支事务已经提交
- 在TM通知RM提交事务之前,RM分支事务全部回滚
- 在TM通知RM提交事务之前,RM分支事务部分回滚
对于前面两种情况来说,TM会比较好处理,做事务恢复的时候,要么标记全局事务成功,要么标记全局事务回滚,通知RM可以完成分支事务了,对于第三种情况,可能就需要进行决策了,这个具体怎么处理,DTP并没有说明细节,可以交给开发者自己去判断
DTP本质上只是一个理论基础,它并没有提供具体的实现,往往实现需要考虑更多问题:
- 如何获取TM?
- 如何启动和结束一个事务
- 如何标识一个事务
- 如何保存和传递事务上下文
- 应用如何通过资源管理器操作共享资源
- 资源管理器如何实现准备阶段以及与提交阶段的逻辑
- 如何实现两阶段提交协议
- 如何实现在异常情况下进行事务恢复
基于DTP模型的方案有TCC,AT,Sage,XA都基于这个DTP模型(二阶段提交协议)
DTP二阶段提交协议的弊端:
- 单点问题:以事务协调者为中心,假如它挂了就没办法了
- 同步堵塞:延迟了提交时间,加长了资源堵塞时间
- 数据不一致:提交二阶段,依然存在commit结果未知的情况,有可能导致数据不一致
Comments | NOTHING
Warning: Undefined variable $return_smiles in /www/wwwroot/wql_luoqin_ltd/wp-content/themes/Sakura/functions.php on line 1109