1.X/OpenDTP事务模型
X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open这个组织定义的一套分布式事务的标准,也就是定义了规范和API接口,由各个厂商进行具体的实现。 这个标准提出了使用二阶段提交(2PC – Two-Phase-Commit)来保证分布式事务的完整性。后来J2EE也遵循了X/OpenDTP规范,设计并实现了java里的分布式事务编程接口规范-JTA。
在X/OpenDTP事务模型中,定义了三个角色:
当一个事务涉及多个分布式节点时,为了保证事务处理的ACID特性,就需要引入一个调度者(TM)来统一调度跨节点的执行逻辑,这些被调度的节点被称为(AP)。TM调度这些AP,并最终决定这些的AP处理后,事务是否进行提交或者回滚,而事务操作最终落实的地方就是RM。
- AP: application, 应用程序,也就是业务层。哪些操作属于一个事务,就是AP定义的。比如上图的用户服务。
- RM: Resource Manager,资源管理器。一般是数据库,也可以是其他资源管理器,比如消息队列, 文件系统。比如上图的db。
- TM: Transaction Manager ,事务管理器、事务协调者,负责接收来自用户程序(AP)发起的XA事务 指令,并调度和协调参与事务的所有RM(数据库),确保事务正确完成。
关于 XA
XA 是X/Open DTP定义的资源管理器和事务管理器之间的接口规范,TM用它来通知和协调相关RM事务的开始、结束、提交或回滚。目前Oracle、Mysql、DB2都提供了对XA的支持;
XA接口是双向的系统接口,在事务管理器(TM)以及多个资源管理器之间形成通信的桥梁(XA不能自动提交)
2.关于2PC协议
在X/OpenDTP事务模型中用到了2PC,即二阶段提交(2PC – Two-Phase-Commit)。这两个阶段主要包括 Propose(投票)和Commit(正式提交)。
PS:2PC是一个强一致性协议。因为整个事务在TM处理下分为两个阶段提交,所以叫2PC
2.1 阶段一:提交事务请求(投票)
1)事务询问:TM向所有的参与者发送事务内容,询问能否执行事务提交操作,并开始等待各参与者的响应
2)执行事务:各个参与者节点执行事务操作,并将Undo和Redo信息记录到事务日志中
关于Undo、Redo日志可以参考 【MySQL】运行原理(四):重做日志(redo log),回滚日志(undo log),二进制日志(binlog)…
3)反馈执行结果:如果参与者事务执行成功就返回yes,失败就返回no;向调度者返回结果就类似一个投票过程
2.2 阶段二:执行事务提交
根据AP的投票结果(执行结果)最终决定:执行事务 或 回滚事务
存在的问题: 因为2pc是强一致性协议,所以如果第一阶段其中一个RM在写入日志时宕机,或返回后TM网络出现故障,那么第二阶段就会无法进行,RM会一直阻塞,全局事务就卡死在这里了。
- 降低一致性要求,引入过半提交机制;比如zk在第一阶段只要半数节点完成,就进入第二次提交
- 引入timeout超时机制;比如3pc针对此问题进行了改造引入了timeout机制









还没有评论,来说两句吧...