美文网首页
分布式事务之两阶段提交(2PC)

分布式事务之两阶段提交(2PC)

作者: AYSAML | 来源:发表于2020-08-19 16:09 被阅读0次

    两阶段提交(2PC) 是 Oracle Tuxedo 系统提出的 XA 分布式事务协议的其中一种实现方式。

    一、关于 XA 分布式事务协议

    XA 分布式协议主要有两个角色:

    • 事务管理器(协调者)
      事务管理器作为全局事务的协调管理者,与每个资源管理器通信,完成分布式事务的管理。
    • 资源管理器 (参与者)
      资源管理器管理每个参与者的事务资源,其应该具有提交和回滚的能力,如数据库。

    XA 分布式协议制定的分段提交过程:

    • 第一阶段( prepare )
      第一阶段每个参与者准备执行事务并对需要的资源加锁,进入 ready 状态,并通知协调者已经准备就绪。
    • 第二阶段( commit )
      第二阶段当协调者确认每个参与者都 ready 后,通知参与者进行 commit 操作;如果有参与者 fail ,则发送 rollback 命令,各参与者做回滚。

    二、两阶段提交( 2PC )

    基于 XA 协议,有了两阶段提交的实现,在 JAVA 中可以使用基于两阶段提交的 atomikos 来进行分布式事务管理。

    理解起来其实很简单,下面就从 2PC 的不同阶段和不同的状态来分析它的执行过程:

    第一阶段

    • 各参与者都成功的情况


      1. 首先事务协调者向所有参与者发送 prepare 请求。
      2. 参与者开始执行各自的数据更新,写入各自的 Undo Log 和 Redo Log。
      3. 参与者执行成功后,暂时不提交事务,向协调者发送 Done 消息。
      4. 进入第二阶段。
    • 有参与者失败的情况


      在第一阶段,如果参与者在本地事务中执行失败,会向协调者发送 Fail 消息,协调者产生事务中断。

    • 事务中断

    任何一个参与者向协调者反馈了 Fail 消息,或者在等待超时之后,协调者不能接收到参与者的反馈响应,就会中断事务。

    步骤如下:

    1. 协调者向所有参与者发出 Rollback 请求。
    2. 参与者收到 Rollback 请求之后,会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作,并在完成回滚之后释放在整个事物执行期间占用的资源。
    3. 参与者在完成事物回滚之后,向协调者发送 Ack 消息。
    4. 中断事务

    第二阶段

    第二阶段中,如果所有参与者的都执行成功,则协调者下发 Commit 消息,参与者提交本地事务,释放锁住的资源,并向协调者发送 Ack 确认。

    当协调者受到所有的参与者确认消息后,整个分布式事务结束。

    三、总结

    基于以上,可以很容易理解 2PC 的执行过程,同时我们也注意到它存在的缺点:

    1. 对高并发不友好。
      在分布式事务的执行过程中,存在多次通信,占用时间长,并且在这个过程中所有节点处于阻塞状态,每个参与者持有的资源始终要加锁。
    2. 单点故障。由上面可知协调者扮演着非常重要的角色,一旦协调者发生故障,参与者就会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。
    3. 数据不一致。在第二阶段中,当协调者向参与者发送 commit 请求之后,发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障,就会导致只有一部分参与者接受到了commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作,但是其他未接到 commit 请求的机器则无法执行事务提交,就导致了数据的不一致。

    欢迎访问个人博客 获取更多知识分享。

    相关文章

      网友评论

          本文标题:分布式事务之两阶段提交(2PC)

          本文链接:https://www.haomeiwen.com/subject/whqdjktx.html