精华内容
下载资源
问答
  • 二阶段提交与三阶段提交

    千次阅读 2019-05-22 23:35:20
    二阶段提交 二阶段提交的算法思路可以概括为: 参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。 阶段是指: 第一阶段 - 请求阶段(表决阶段) 第阶段 -...

    二阶段提交

    在这里插入图片描述
    二阶段提交的算法思路可以概括为: 参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

    二阶段是指: 第一阶段 - 请求阶段(表决阶段) 第二阶段 - 提交阶段(执行阶段)

    (1) 请求阶段(表决):

    事务协调者通知每个参与者准备提交或取消事务,然后进入表决过程,参与者要么在本地执行事务,写本地的redo和undo日志,但不提交,到达一种"万事俱备,只欠东风"的状态。请求阶段,参与者将告知协调者自己的决策: 同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)

    (2) 提交阶段(执行):

    在该阶段,写调整将基于第一个阶段的投票结果进行决策: 提交或取消

    当且仅当所有的参与者同意提交事务,协调者才通知所有的参与者提交事务,否则协调者将通知所有的参与者取消事务

    参与者在接收到协调者发来的消息后将执行响应的操作

    两阶段提交的缺点

    1.同步阻塞问题。执行过程中,所有参与节点都是事务阻塞型的。
    当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。

    2.单点故障。由于协调者的重要性,一旦协调者发生故障。
    参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。(如果是协调者挂掉,可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题)

    3.数据不一致。在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求。
    而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

    两阶段提交无法解决的问题

    当协调者出错,同时参与者也出错时,两阶段无法保证事务执行的完整性。
    考虑协调者在发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。
    那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

    使用实例

    jta+atomikos分包管理分布式事务,不适用微服项目

    三阶段提交

    在这里插入图片描述
    三阶段提交协议在协调者和参与者中都引入超时机制,并且把两阶段提交协议的第一个阶段分成了两步: 询问,然后再锁资源,最后真正提交

    (1) canCommit阶段

    3PC的canCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求,参与者如果可以提交就返回yes响应,否则返回no响应

    (2) preCommit阶段

    协调者根据参与者canCommit阶段的响应来决定是否可以继续事务的preCommit操作。根据响应情况,有下面两种可能:

    a) 协调者从所有参与者得到的反馈都是yes:

    那么进行事务的预执行,协调者向所有参与者发送preCommit请求,并进入prepared阶段。参与泽和接收到preCommit请求后会执行事务操作,并将undo和redo信息记录到事务日志中。如果一个参与者成功地执行了事务操作,则返回ACK响应,同时开始等待最终指令

    b) 协调者从所有参与者得到的反馈有一个是No或是等待超时之后协调者都没收到响应:

    那么就要中断事务,协调者向所有的参与者发送abort请求。参与者在收到来自协调者的abort请求,或超时后仍未收到协调者请求,执行事务中断。

    (3) doCommit阶段

    协调者根据参与者preCommit阶段的响应来决定是否可以继续事务的doCommit操作。根据响应情况,有下面两种可能:

    a) 协调者从参与者得到了ACK的反馈:

    协调者接收到参与者发送的ACK响应,那么它将从预提交状态进入到提交状态,并向所有参与者发送doCommit请求。参与者接收到doCommit请求后,执行正式的事务提交,并在完成事务提交之后释放所有事务资源,并向协调者发送haveCommitted的ACK响应。那么协调者收到这个ACK响应之后,完成任务。

    b) 协调者从参与者没有得到ACK的反馈, 也可能是接收者发送的不是ACK响应,也可能是响应超时:

    执行事务中断。

    展开全文
  •  因为事务需要实现ACID,即原子性、一致性、隔离性、持久性,所以需要采用一定的机制来... XA:XA协议,规定事务管理器和资源管理器接口,采用二阶段提交协议。 一阶段提交协议  一阶段提交协议相对简单,如

    原文地址:http://blog.csdn.net/lidatgb/article/details/38468073

        因为事务需要实现ACID,即原子性、一致性、隔离性、持久性,所以需要采用一定的机制来保证,通常采用的是分阶段提交的方式。

        XA:XA协议,规定事务管理器和资源管理器接口,采用二阶段提交协议。

    一阶段提交协议

        一阶段提交协议相对简单,如下图:

        

        当然,前提是开启了事务,然后在应用程序发出提交/回滚请求后,数据库执行操作,而后将成功/失败返回给应用程序,程序继续执行。

        一阶段提交协议相对简单,简单带来的优点就是,它不用再与其他的对象交互,节省了判断步骤和时间,所以在性能上是在阶段提交协议中最好的。

    二阶段提交协议

        一阶段提交协议有其优点,但缺点也很明显:

    • 数据库确认执行事务的时间较长,出问题的可能性就随之增大。
    • 如果有多个数据源,一阶段提交协议无法协调他们之间的关系。

       所以在一阶段协议的基础上,有了二阶段协议,二阶段协议的好处是添加了一个管理者角色,如下:

        

        很明显,二阶段协议通过将两层变为三层,增加了中间的管理者角色,从而协调多个数据源之间的关系,二阶段提交协议分为两个阶段。

        第一阶段

        

        应用程序调用了事务管理器的提交方法,此后第一阶段分为两个步骤:

    • 事务管理器通知参与该事务的各个资源管理器,通知他们开始准备事务。
    • 资源管理器接收到消息后开始准备阶段,写好事务日志并执行事务,但不提交,然后将是否就绪的消息返回给事务管理器(此时已经将事务的大部分事情做完,以后的内容耗时极小)。

        第二阶段

        

        第二阶段也分为两个步骤:    

    • 事务管理器在接受各个消息后,开始分析,如果有任意其一失败,则发送回滚命令,否则发送提交命令。
    • 各个资源管理器接收到命令后,执行(耗时很少),并将提交消息返回给事务管理器。
        事务管理器接受消息后,事务结束,应用程序继续执行。
        为什么要分两步执行?一是因为分两步,就有了事务管理器统一管理的机会;二尽可能晚地提交事务,让事务在提交前尽可能地完成所有能完成的工作,这样,最后的提交阶段将是耗时极短,耗时极短意味着操作失败的可能性也就降低。
        同时,二阶段提交协议为了保证事务的一致性,不管是事务管理器还是各个资源管理器,每执行一步操作,都会记录日志,为出现故障后的恢复准备依据。
        二阶段提交协议的存在的弊端是阻塞,因为事务管理器要收集各个资源管理器的响应消息,如果其中一个或多个一直不返回消息,则事务管理器一直等待,应用程序也被阻塞,甚至可能永久阻塞。

    事务与协议

        那么本地事务和分布式事务,分别采用的是哪些协议?我在RedBooks的一个文档中看到的是:
    Global transactions
        Although the XAResource interface is intended to support two phase commit, the specification does not force an adapter to support two phase commit. However, if the resource adapter does implement XAResource it must also implement support for one phase commit. This allows the transaction manager to do one phase commit optimization (explained later) by setting the onePhase flag to true when doing acommit.……
    Local transactions
        A local transaction is managed by the resource manager without the need for an external transaction manager, and can be utilized when only one resource is involved. Local transactions only support one phase commit, because they only reference one EIS.……
        大意是:虽然实现XA接口的目的是为了支持二阶段提交协议,但是它也支持一阶段提交协议。本地事务只支持一阶段提交;分布式事务默认采用的是二阶段提交,如果在分布式事务中非得使用一阶段提交协议,那么只要数据源多余一个就会抛出异常,如果只有一个数据源则正确执行。

    总结

        一阶段提交协议和二阶段提交协议只是比较常用的两个,此外还有其他协议,可自行研究。
    展开全文
  • 图片来源:pexels网站java4all原创,欢迎关注摘要:本文主要讲解分布式事务中二阶段提交协议(2pc)相关基础概念,原理及详细的执行过程。1.理论基础二阶段提交(...
        

    640?wx_fmt=jpeg

    图片来源:pexels网站


    640?wx_fmt=png

    java4all原创,欢迎关注
    640?wx_fmt=gif

    摘要:本文主要讲解分布式事务中二阶段提交协议(2pc)相关基础概念,原理及详细的执行过程。

    640?wx_fmt=gif

    1.理论基础

    二阶段提交(Two-phaseCommit)是在计算机网络以及数据库领域内,为了使分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。

    在分布式系统中,每个节点虽然可以知晓自己的操作是成功或者失败,却无法知道其他节点操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的一致性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。

    因此,二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情况决定各参与者是要提交操作还是中止操作。

    两个阶段是指:

    • 第一阶段:准备阶段(投票阶段voting phase)

    • 第二阶段:提交阶段(执行阶段commit phase)


    2.pc实现

    2.1准备阶段

    事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息,每个参与者要么直接返回失败(如权限验证失败),要么在本地执行事务,写本地的redo和undo日志,但不提交。 

    这个准备阶段又可以细分为三个步骤:

    1.协调者节点向所有参与者节点询问是否可以执行提交操作(vote),并开始等待各参与者节点的响应。 

    2.参与者节点执行询问发起为止的所有事务操作,并将Undo信息和Redo信息写入日志。(注意理解这个点:若成功这里其实每个参与者已经执行了事务操作,只是执行完事务操作,并没有进行commit或者roolback )。

    3.各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功,则它返回一个"同意"消息;如果参与者节点的事务操作实际执行失败,则它返回一个"中止"消息。 

    准备阶段如下:

    640?wx_fmt=png


    640?wx_fmt=png


    2.2提交阶段

    如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;

    参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源) 


    在提交阶段,又分为2种情况:

    1.当协调者节点从所有参与者节点获取的都是“同意”时:

    1)协调者节点向所有参与者节点发出"正式提交(commit)"的请求。

    2)参与者节点正式完成commit操作,并释放在整个事务期间内占用的资源。

    3)参与者节点向协调者节点发送"完成"消息。

    4)协调者节点收到所有参与者节点反馈的"完成"消息后,完成事务。


    640?wx_fmt=png


    640?wx_fmt=png


    2.当协调者节点在第一阶段中收到的反馈有“终止”,或者协调者节点在询问超时之前没有获取到所有参与者节点的“同意”时:

    1)协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求。

    2)参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间内占用的资源。

    3)参与者节点向协调者节点发送"回滚完成"消息。

    4)协调者节点受到所有参与者节点反馈的"回滚完成"消息后,取消事务。

    不管最后结果如何,第二阶段都会结束当前事务。 

    当第一阶段的反馈结果不全是“同意”,执行流程如下:


    640?wx_fmt=png


    640?wx_fmt=png


    640?wx_fmt=png


    640?wx_fmt=png


    3.2pc优缺点

    3.1同步阻塞问题

    执行过程中,所有参与节点都是事务阻塞型的。当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态,效率低下。

    3.2单点故障

    由于协调者的重要性,一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。(如果是协调者挂掉,可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题) 

    3.3数据不一致

    在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作,但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。 

    3.4不确定性

    协调者再发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

     

    由于二阶段提交存在着上述同步阻塞、单点问题、脑裂等缺陷,所以,研究者们在二阶段提交的基础上做了改进,提出了三阶段提交。 


    上一篇:分布式事务-01:分布式事务产生原因及相关概念

    下一篇:分布式事务-03:3PC 三阶段提交协议实现过程及原理


    对文章内容有疑问或者不同的见解,欢迎关注公众号java4all,或添加我的微信w1186355422一起交流讨论。

    640?wx_fmt=png

    640?wx_fmt=jpeg

    IT云清

    640?wx_fmt=jpeg

    展开全文
  • MongoDB两阶段提交实现事务

    万次阅读 2017-03-29 09:42:03
    MongoDB两阶段提交实现事务  MongoDB数据库中操作单个文档总是原子性的,然而,涉及多个文档的操作,通常被作为一个“事务”,而不是原子性的。因为文档可以是相当复杂并且包含多个嵌套文档,单文档的...

    MongoDB两阶段提交实现事务

        MongoDB数据库中操作单个文档总是原子性的,然而,涉及多个文档的操作,通常被作为一个“事务”,而不是原子性的。因为文档可以是相当复杂并且包含多个嵌套文档,单文档的原子性对许多实际用例提供了支持。尽管单文档操作是原子性的,在某些情况下,需要多文档事务。在这些情况下,使用两阶段提交,提供这些类型的多文档更新支持。因为文档可以表示为Pending数据和状态,可以使用一个两阶段提交确保数据是一致的,在一个错误的情况下,事务前的状态是可恢复的。

        事务最常见的例子是以可靠的方式从A账户转账到B账户,在关系型数据库中,此操作将从A账户减掉金额和给B账户增加金额的操作封装在单个原子事务中。在MongoDB中,可以使用两阶段提交达到相同的效果。本文中的所有示例使用mongo shell与数据库进行交互,并假设有两个集合:首先,一个名为accounts的集合存储每个账户的文档数据,另一个名为transactions的集合存储事务本身。

        首先创建两个名为A和B的账户,使用下面的命令:

    db.accounts.save({name: "A", balance: 1000, pendingTransactions: []})
    db.accounts.save({name: "B", balance: 1000, pendingTransactions: []})

    使用find()方法验证这两个操作已经成功:

    db.accounts.find()

    mongo会返回两个类似下面的文档:

    { "_id" : ObjectId("4d7bc66cb8a04f512696151f"), "name" : "A", "balance" : 1000, "pendingTransactions" : [ ] }
    { "_id" : ObjectId("4d7bc67bb8a04f5126961520"), "name" : "B", "balance" : 1000, "pendingTransactions" : [ ] }
    • 事务过程:

    设置事务初始状态initial:

        通过插入下面的文档创建transaction集合,transaction文档持有源(source)和目标(destination),它们引用自accounts集合文档的字段名,以及value字段表示改变balance字段数量的数据。最后,state字段反映事务的当前状态。

    db.transactions.save({source: "A", destination: "B", value: 100, state: "initial"})

    验证这个操作已经成功,使用find():

    db.transactions.find()

    这个操作会返回一个类似下面的文档:

    { "_id" : ObjectId("4d7bc7a8b8a04f5126961522"), "source" : "A", "destination" : "B", "value" : 100, "state" : "initial" }

    切换事务到Pending状态:

        在修改accounts集合记录之前,将事务状态从initial设置为pending。使用findOne()方法将transaction文档赋值给shell会话中的局部变量t:
    t = db.transactions.findOne({state: "initial"})

    变量t创建后,shell将返回它的值,将会看到如下的输出:

    { "_id" : ObjectId("4d7bc7a8b8a04f5126961522"), "source" : "A", "destination" : "B", "value" : 100, "state" : "initial" }

    使用update()改变state的值为pending:

    db.transactions.update({_id: t._id}, {$set: {state: "pending"}})
    db.transactions.find()

    find()操作将返回transaction集合的内容,类似下面:

    { "_id" : ObjectId("4d7bc7a8b8a04f5126961522"), "source" : "A", "destination" : "B", "value" : 100, "state" : "pending" }

    将事务应用到两个账户:

        使用update()方法应用事务到两个账户。在update()查询中,条件pendingTransactions:{$ne:t._id}阻止事务更新账户,如果账户的pendingTransaction字段包含事务t的_id:

    db.accounts.update(
    	{ name: t.source, pendingTransactions: { $ne: t._id } },
    	{ $inc: { balance: -t.value }, $push: { pendingTransactions: t._id } }
    )
    db.accounts.update(
    	{ name: t.destination, pendingTransactions: { $ne: t._id } },
    	{ $inc: { balance: t.value }, $push: { pendingTransactions: t._id } }
    )
    db.accounts.find()

    find()操作将返回accounts集合的内容,现在应该类似于下面的内容:

    { "_id" : ObjectId("4d7bc97fb8a04f5126961523"), "balance" : 900, "name" : "A", "pendingTransactions" : [ ObjectId("4d7bc7a8b8a04f5126961522") ] }
    { "_id" : ObjectId("4d7bc984b8a04f5126961524"), "balance" : 1100, "name" : "B", "pendingTransactions" : [ ObjectId("4d7bc7a8b8a04f5126961522") ] }

    设置事务状态为committed:

        使用下面的update()操作设置事务的状态为committed:

    db.transactions.update({_id: t._id}, {$set: {state: "committed"}})
    db.transactions.find()

    find()操作发回transactions集合的内容,现在应该类似下面的内容:

    { "_id" : ObjectId("4d7bc7a8b8a04f5126961522"), "destination" : "B", "source" : "A", "state" : "committed", "value" : 100 }

    移除pending事务:

        使用下面的update()操作从accounts集合中移除pending事务:

    db.accounts.update({name: t.source}, {$pull: {pendingTransactions: t._id}})
    db.accounts.update({name: t.destination}, {$pull: {pendingTransactions: t._id}})
    db.accounts.find()

    find()操作返回accounts集合内容,现在应该类似下面内容:

    { "_id" : ObjectId("4d7bc97fb8a04f5126961523"), "balance" : 900, "name" : "A", "pendingTransactions" : [ ] }
    { "_id" : ObjectId("4d7bc984b8a04f5126961524"), "balance" : 1100, "name" : "B", "pendingTransactions" : [ ] }

    设置事务状态为done:

        通过设置transaction文档的state为done完成事务:

    db.transactions.update({_id: t._id}, {$set: {state: "done"}})
    db.transactions.find()

    find()操作返回transaction集合的内容,此时应该类似下面:

    { "_id" : ObjectId("4d7bc7a8b8a04f5126961522"), "destination" : "B", "source" : "A", "state" : "done", "value" : 100 }
    • 从失败场景中恢复:

        最重要的部分不是上面的典型例子,而是从各种失败场景中恢复未完成的事务的可能性。这部分将概述可能的失败,并提供方法从这些事件中恢复事务。这里有两种类型的失败:

    1、所有发生在第一步(即设置事务的初始状态initial)之后,但在第三步(即应用事务到两个账户)之前的失败。为了还原事务,应用应该获取一个pending状态的transaction列表并且从第二步(即切换事务到pending状态)中恢复。

    2、所有发生在第三步之后(即应用事务到两个账户)但在第五步(即设置事务状态为done)之前的失败。为了还原事务,应用需要获取一个committed状态的事务列表,并且从第四步(即移除pending事务)恢复。

        因此应用程序总是能够恢复事务,最终达到一个一致的状态。应用程序开始捕获到每个未完成的事务时运行下面的恢复操作。你可能还希望定期运行恢复操作,以确保数据处于一致状态。达成一致状态所需要的时间取决于应用程序需要多长时间恢复每个事务。

    回滚:

         在某些情况下可能需要“回滚”或“撤消”事务,当应用程序需要“取消”该事务时,或者是因为它永远需要恢复当其中一个帐户不存在的情况下,或停止现有的事务。这里有两种可能的回滚操作:

    1、应用事务(即第三步)之后,你已经完全提交事务,你不应该回滚事务。相反,创建一个新的事务,切换源(源)和目标(destination)的值。

    2、创建事务(即第一步)之后,在应用事务(即第三步)之前,使用下面的处理过程:

    设置事务状态为canceling:

        首先设置事务状态为canceling,使用下面的update()操作:

    db.transactions.update({_id: t._id}, {$set: {state: "canceling"}})
    撤销事务:

        使用下面的操作顺序从两个账户中撤销事务:

    db.accounts.update({name: t.source, pendingTransactions: t._id}, {$inc: {balance: t.value}, $pull: {pendingTransactions: t._id}})
    db.accounts.update({name: t.destination, pendingTransactions: t._id}, {$inc: {balance: -t.value}, $pull: {pendingTransactions: t._id}})
    db.accounts.find()

    find()操作返回acounts集合的内容,应该类似下面:

    { "_id" : ObjectId("4d7bc97fb8a04f5126961523"), "balance" : 1000, "name" : "A", "pendingTransactions" : [ ] }
    { "_id" : ObjectId("4d7bc984b8a04f5126961524"), "balance" : 1000, "name" : "B", "pendingTransactions" : [ ] }

    设置事务状态为canceled:

         最后,使用下面的update()状态将事务状态设置为canceled:

    db.transactions.update({_id: t._id}, {$set: {state: "canceled"}})
    参考资料:http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/

    标签:数据库MongoDBNoSQL

    展开全文
  • 一、二阶段提交算法的描述: 二阶段提交算法的成立基于以下假设: 该分布式系统中,存在一个节点作为协调者(Coordinator),其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。所有节点都采用预写式...
  • 二阶段提交,三阶段提交,Paxos

    千次阅读 2017-02-08 10:17:50
    随着大型网站的各种高并发访问、海量数据处理等场景越来越多,...本文主要介绍关于分布式事务,二阶段提交和三阶段提交。  在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些
  • 分布式系统,这早已不是什么新鲜的东西了,在分布式系统的架构设计过程中,往往会存在分布式一致性的问题,经过前人的辛苦探究,提出了二阶段提交协议,三阶段提交协议,Paxos算法等等,用来解决分布式一致性的问题...
  • 在分布式系统中,事务往往包含有多个参与者的活动,单个参与者上的活动是能够保证原子性的,而多个参与者之间原子性的保证则需要通过两阶段提交实现,两阶段提交是分布式事务实现的关键。
  • 分布式基础之二阶段提交

    千次阅读 2016-01-04 20:29:06
    分布式基础之二阶段提交二阶段提交(Two Phase Commit)在分布式事务处理中非常常见。它主要用来保证分布式事务处理的一致性,决定事务的提交或回滚。目前二阶段提交广泛应用于关系型数据库的分布式事务处理中,它是...
  • 正确理解二阶段提交(Two-Phase Commit)

    万次阅读 多人点赞 2019-03-07 15:42:56
    二阶段提交出现的背景是, 当我们使用分布式系统时, 如果分布式系统中的机器发生故障之后, 如何保证事务数据的一致性。 从一个场景入手, 假设一个人要从 A 银行向 B 银行进行跨行转账 100 元。 此时我们需要对 A ...
  • 基于Oceanbase现有架构,设计了两阶段提交的具体实现流程,已经在各阶段失败的回复流程。在没有全局时钟的情况下,设计了分布式快照读的实现优化。
  • MySQL二阶段提交与xtrabackup如何保证备份不丢失数据 MySQL二阶段提交与crash recovery 1. MySQL二阶段提交 2. crash recovery的实现 xtrabackup如何实现数据不丢失 1. general log中xtrabackup的备份记录 ...
  • rocketMq事务消息原理与二阶段提交

    千次阅读 2019-04-12 14:45:16
    两个方法的返回值都是消息状态,就是告诉broker应该提交或者回滚半消息 从上面的流程中,我们不难看到,rocketMq通过二阶段提交的思想实现了事务消息,那我们就顺便说说二阶段提交: 我们将使用二阶段提交保证数据...
  • java4all原创,欢迎关注摘要:本文主要讲解分布式事务中三阶段提交协议(3pc)相关基础概念、原理及详细的执行过程。上一篇:分布式事务-02:2PC 二阶段提交协议实...
  • Percolator中的两阶段提交实现分析

    千次阅读 2011-11-16 23:40:32
    在Percolator的论文中用银行转账的经典案例来说明Percolator是如何实现阶段提交的,如下图: data, lock, write的含义分别为...
  • 二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后...
  • 在分布式系统中,每一个机器...二阶段提交 二阶段提交将一个事务的处理过程分为投票和执行两个阶段,核心是对每个事务都采用先尝试后提交的处理方式 阶段一:提交事务请求 (1)事务询问 协调者向所有的参与者发送.
  • 对分布式事务及两阶段提交、三阶段提交的理解 一、分布式数据一致性 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上。 1.什么是数据一致性 ...
  • 什么是2PC两阶段提交 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(commit phase). 2是指两个阶段,P是指准备阶段,C是指提交阶段。 举例:张三和李四好久不见,...
  • 分布式两阶段提交和三阶段提交

    万次阅读 2016-07-31 23:59:26
    随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何...本文主要介绍关于分布式事务,二阶段提交和三阶段提交。 在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些
  • 文章目录问题协调者统一调度二阶段提交协议 问题 在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。 在关系型数据库中,由于存在事务机制,可以保证每个独立节点上的数据操作满足 ACID。 ...
  • 这是碧桂园旺生活二阶段提交分布式事务开源解决方案。github地址 支持dubbo,springcloud等rpc框架进行分布式事务 本地事务存储,支持redis,mogondb,zookeeper,file,mysql等关系型数据库 序列化方式,支持java,...
  • PostgreSQL中的两阶段提交

    千次阅读 2018-10-17 18:29:35
    多台数据库之间的原子性,需要通过两阶段提交协议来实现。  两阶段提交协议的步骤: (1)应用程序调用事务协调器中的提交方法。 (2)事务协调器将联络事务中涉及的所有数据库,通知它们准备提交事务(PREPARE ...
  • PHP因此语言特性和适用场景所限,其分布式事务实现不如Java那么成熟。如果想通过PHP自行实现分布式事务,1、可以参考一下Atomikos项目Atomikos, 该方案说明文档可通过如下资源下载阅读:...
  • 前言:X/A协议实际上也是分两阶段提交的编码实现,只是X/A协议依赖于数据库,需要数据库支持X/A协议,TCC的核心思想是"参与事务的应用程序都应该提供三个http接口,由一个事务协调者进行整体事务的协调" ...
  •   分布式事务的实现并不是很难,比如下 文要展开的两阶段提交(2PC:Two-Phrase Commit)和三阶段提交(3PC:Three-Phrase Commit)都给我们提供了思路,但是如果要保证数据的强一致性,并要求对外提供可用的服务...
  •   分布式事务的实现并不是很难,比如下 文要展开的两阶段提交(2PC:Two-Phrase Commit)和三阶段提交(3PC:Three-Phrase Commit)都给我们提供了思路,但是如果要保证数据的强一致性,并要求对外提供可用的服务...
  • sink —— kafka producer 作为sink,采用两阶段提交 sink,需要实现一个 TwoPhaseCommitSinkFunction 步骤: 第一条数据来了之后,开启一个 kafka 的事务(transaction),正常写入 kafka 分区日志但标记为未提交...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 195,279
精华内容 78,111
关键字:

二阶段提交实现