分布式事务——两阶段提交

  • 时间:
  • 浏览:10

在两阶段提交协议中,系统一般暗含两类角色:

下图为两阶段提交协议中的协调者及参与者的情況机。左侧a为协调者情況机;右侧b为参与者情況机。

在准备阶段,协调者将通知事务参与者准备提交或撤回事务,写本地的redo和undo日志,但不提交,以后 进入表决过程。在表决过程中,参与者将告知协调者当事人的决策:同意(事务参与者本地作业执行成功)或撤回(本地作业执行故障)。

两阶段提交协议最早是分布式事务的专家Jim Gray在1978年的一篇文章Notes on Database Operating Systems中提及。两阶段提交协议还也能 保证数据的强一致性,即保证了分布式事务的原子性:所有结点要么全做要么全不做。统统分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者,并决定提交或撤回(回滚)的分布式算法。同时也是正确处理一致性问题报告 的算法。该算法也能正确处理统统的临时性系统故障(包括多线程 池池、网络节点、通信等故障),被广泛地使用。以后 ,它并非也能通过配置来正确处理所有的故障,在统统情況下它还也能 人为的参与也能正确处理问题报告 。

大每段的关系型数据库通过两阶段提交(Two Phase Commit,2PC)算法来完成分布式事务,比如Oracle中通过dblink土方式进行事务正确处理。下面重点介绍下2PC算法。

MySQL从5.5版本以后 刚现在现在开始支持,SQL Server 10005以后 刚现在现在开始支持,Oracle 7以后 刚现在现在开始支持。

为了正确处理你本身分布式一致性问题报告 ,前人在性能和数据一致性的反反复复权衡过程中总结了统统典型的协议和算法。其中比较著名的有二阶提交协议(Two Phase Commitment Protocol)、三阶提交协议(Three Phase Commitment Protocol)和Paxos算法。针对分布式事务,是X/Open 你本身组织定义的一套分布式事务的标准X/Open DTP(X/Open Distributed Transaction Processing ReferenceModel),定义了规范和API接口,还也能 由各个厂商进行具体的实现。

协调者协议流程如下:

顾名思义,两阶段提交分为以下另一个 多阶段:

分布式事务是指趋于稳定在多个数据节点之间的事务,分布式事务比单机事务要比较复杂的多。在分布式系统中,各个节点之间在是相互独立的,也能 通过网络进行沟通和协调。肯能趋于稳定事务机制,还也能 保证每个独立节点上的数据操作还也能 满足ACID。以后 ,相互独立的节点之间无法准确地知道统统节点的事务执行情況。统统从理论上来讲,另一个 多节点的数据是无法达到一致的情況。肯能想让分布式部署的多个节点中的数据保持一致性,这麼就要保证在所有节点数据的写操作,要么删剪都执行,要么删剪都有执行。以后 ,一台机器在执行本地事务的以后 无法知道统统机器中的本地事务的执行结果,统统它也就问你本次事务到底应该commit还是rollback。统统,常规的正确处理土方式统统引入另一个 多"协调者"的组件来统一调度所有分布式节点的执行。

若收到任何另一个 多参与者发送的“VOTE_ABORT”消息;

在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica), 那些副本会放置在不同的节点上。那些数据节点肯能是物理机器,也肯能是虚拟机。为了对用户提供正确的CURD等语意,人们人们人们 也能 保证那些放置在不同节点上的副本是一致的,这就涉及分布式事务的问题报告 。

在该阶段,协调者将基于第另一个 多阶段的投票结果进行决策:提交或撤回。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务,以后 协调者将通知所有的参与者撤回事务。参与者在接收到协调者发来的消息后将执行响应的操作。

若收到所有参与者发送的“VOTE_COMMIT”消息;

一般情況下,两阶段提交机制都能较好的运行,当在事务进行过程中,有参与者宕机时,重启以后 ,还也能 通过询问统统参与者肯能协调者,从而知道你本身事务到底提交了这麼。当然,你本身切的前提都有各个参与者在进行每一步操作时,都有以后 写入日志。

本文介绍分布式事务正确处理方案之一的两阶段提交协议。

两阶段提交这麼正确处理的困境如下:

协调者协议流程如下: