MENU

分布式事务解决方案之二阶段提交

前言

为解决分布式一致性问题,在兼顾一致性、可用性的需求,提出一些协议以及算法。

  • 基于XA协议的二阶段提交
  • 基于XA协议的三阶段提交
  • Paxos算法
  • 事务补偿型TCC事务

XA协议

XA协议由Tuxedo首先提出的,并交给X/Open组织,作为资源管理器(数据库)与事务管理器的接口标准。目前,Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器事务管理器之间进行通信的标准接口。

摘自:百度百科

2PC

二阶段提交,是计算机网络尤其是在数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性设计。在分布式系统中,每一个机器节点能够知道自己在执行事务操作过程是成功或失败,却无法直接获取其他分布式节点的执行结果。因此,为保持事务处理的ACID,则引入协调者(即XA协议中的事务管理器)来统一调度所有分布式节点的执行逻辑,而被调度的分布式节点则称为参与者(即XA协议中的资源管理器)

详细二阶段执行流程

  • 阶段一:提交事务请求(也被称为投票阶段,即各参与者投票表明是否继续执行接下去的事务提交操作)

    • 事务询问:协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应。
    • 执行事务:各参与者节点执行事务操作,并将Undo和Redo信息记入事务日志中。
    • 各参与者向协调者反馈事务询问的响应:如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。
  • 阶段二:执行事务提交(也被称为执行阶段,协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作。)

    • 执行事务提交(所有参与者获得的反馈都是Yes响应,则执行提交事务)
      • 发送提交请求(协调者向所有参与者节点发出Commit请求)
      • 事务提交(参与者接收到Commit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源)
      • 反馈事务提交结果(参与者在完成事务提交之后,向协调者发送Ack消息)
      • 完成事务(协调者接收到所有参与者反馈的Ack消息后,完成事务)
        201911
    • 中断事务(任何一个参与者向协调者反馈No响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,则中断事务)
      • 发送回滚请求(协调者向所有参与者节点发出Rollback请求)
      • 事务回滚(参与者接收到Rollback请求后,利用其在阶段一记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源)
      • 反馈事务回滚结果(参与者在完成事务回滚之后,向协调者发送Ack消息)
      • 中断事务(协调者接收到所有参与者反馈的Ack消息后,完成事务中断)
        201912
  • 二阶段提交优点:原理简单、实现方便

  • 二阶段提交缺点:

    • 同步阻塞:同步阻塞,极大限制分布式系统的性能。在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,各参与者在等待其他参与者响应的过程中,将无法进行其他任何操作。
    • 单点问题:协调者的角色在整个二阶段提交协议中起到非常重要的作用。一旦协调者出现问题,那么整个二阶段提交流程将无法运转。如果协调者是在阶段二中出现问题,那么其他参与者将会一直处于锁定事务资源的状态中,无法继续完成事务操作。
    • 数据不一致:在执行事务提交时候,当协调者向所有的参与者发送Commit请求后,发生局部网络异常或者协调者在尚未发送完Commit请求之前自身发送了崩溃,导致最终只有部分参与者收到Commit请求。对于收到Commit请求的参与者则进行事务提交,对于没有收到Commit请求的参与者则无法进行事务提交,出现数据不一致性。
    • 太过保守:二阶段提交协议没有设计较为完善的容错机制,任意一个节点的失败都会导致整个事务的失败。
返回文章列表 文章二维码 打赏
本页链接的二维码
打赏二维码