强一致性分布式事务解决方案

一、概述

1. 简介

  • 强一致性分布式事务要求在任意时刻查询参与全局事务的各节点的数据都是一致的
  • 适用场景:主要用于对数据一致性要求高,在任意时刻都要查询到最新写入数据的场景,比如跨行转账业务
  • 优点:
    • 数据一致性高
    • 在任意时刻都能够查询到最新写入的数据
  • 缺点:
    • 存在性能问题,在分布式事务未完全提交和回滚之前,应用程序不会查询到最新的数据
    • 实现复杂
    • 牺牲了可用性
    • 不适合高并发场景

2. 典型方案

  • DTP 模型(全局事务模型):典型的解决方案是分布式通信协议 XA 规范。MySQL 默认支持,Atomikos 框架和 Dromara 开源社区的 RainCat 框架也在应用层支持 XA 规范
  • 2PC 模型(二阶段提交模型):典型的解决方案是 Dromara 开源社区的 RainCat 框架,在应用层实现了 2PC 模型,避免出现在数据库层实现 2PC 模型时阻塞数据库的情况
  • 3PC 模型(三阶段提交模型):设计过于复杂,在解决 2PC 问题的同时又引入了新的问题,应用不是很广泛

二、DTP 模型

  • DTP 模型是 X/Open 组织定义的一套分布式事务标准,这套标准主要定义了实现分布式事务的规范和 API,具体的实现交给相应的厂商来做

1. 重要概念

  • 事务:一个事务就是一个完整的工作单元,具备 ACID 特性
  • 全局事务:由事务管理器管理的事务,能够一次性操作多个资源管理器
  • 分支事务:由事务管理器管理的全局事务中,每个资源管理器中独立执行的事务
  • 控制线程:执行全局事务的线程,这个线程用来关联应用程序、事务管理器和资源管理器三者之间的关系,也就是表示全局事务和分支事务的关系,通常称为事务上下文环境

2. 执行流程

  • AP(Application Program,应用程序):可以理解为参与 DTP 分布式事务模型的应用程序
  • RM(Resource Manager,资源管理器):可以理解为数据库管理系统或消息服务管理器。应用程序可以通过资源管理器对相应的资源进行有效的控制。相应的资源需要实现 XA 定义的接口
  • TM(Transaction Manager,事务管理器):负责协调和管理 DTP 模型中的事务,为应用程序提供编程接口,同时管理资源管理器
  • AP 可以和 TM、RM 通信,TM 和 RM 互相之间可以通信,DTP 模型定义了 XA 接口,TM 和 RM 能够通过 XA 接口进行双向通信。TM 控制着全局事务,管理事务的生命周期并协调资源。RM 控制和管理实际的资源

三、2PC 模型

  • 2PC 模型是指两阶段提交协议模型,这种模型将整个事务流程分为 Prepare 阶段和 Commit 阶段

1. 执行流程

  • Prepare 阶段:事务管理器给每个参与全局事务的资源管理器发送 Prepare 消息。资源管理器要么返回失败,要么在本地执行相应的事务,将事务写入本地的 Redo Log 文件和 Undo Log 文件,并向事务管理器返回事务执行成功的状态,此时事务并没有提交
  • Commit 阶段:如果事务管理器收到了参与全局事务的资源管理器返回的失败消息,则直接给 Prepare 阶段执行成功的资源管理器发送回滚消息,否则向每个资源管理器发送 Commit 消息。相应的资源管理器根据事务管理器发送过来的消息指令,执行对应的事务回滚或事务提交操作,并将回滚成功或提交成功的消息返回给事务管理器,同时释放事务处理过程中使用的锁资源

2. 存在的问题

  • 同步阻塞问题:事务的执行过程中,所有参与事务的节点都会对其占用的公共资源加锁,导致其他访问公共资源的进程或者线程阻塞
  • 单点故障问题:如果事务管理器发生故障,则资源管理器会一直阻塞
  • 数据不一致问题:如果在 Commit 阶段,由于网络或者部分资源管理器发生故障,导致部分资源管理器没有接收到事务管理器发送过来的 Commit 消息,会引起数据不一致的问题
  • 无法解决的问题:如果在 Commit 阶段,事务管理器发出 Commit 消息后宕机,并且唯一接收到这条 Commit 消息的资源管理器也宕机了,则无法确认事务是否已经提交

四、3PC 模型

  • 3PC 模型是指三阶段提交模型,是在 2PC 模型的基础上改进的版本。3PC 模型把 2PC 模型中的 Prepare 阶段一分为二,最终形成 3 个阶段:CanCommit 阶段、PreCommit 阶段和 doCommit/doRollback 阶段

1. 执行流程

  • CanCommit 阶段:事务管理器向参与全局事务的资源管理器发送 CanCommit 消息。如果资源管理器认为能够执行事务,会向事务管理器响应 Yes 消息,并进入预备状态,否则响应 No 消息
  • PreCommit 阶段:如果都可以执行事务,事务管理器向参与全局事务的资源管理器发送 PreCommit 消息,资源管理器执行事务操作,将 Undo 和 Redo 信息写入事务日志,并向事务管理器响应 Ack 状态,此时不会提交事务。如果不能执行事务,事务管理器会向参与全局事务的资源管理器发送 Abort 消息,资源管理器收到 Abort 消息或者期间出现超时,都会中断事务的执行
  • doCommit 阶段:事务管理器向参与全局事务的资源管理器发送 doCommit 消息,资源管理器正式提交事务,并释放执行事务期间占用的资源,同时向事务管理器响应事务已提交的状态。事务管理器收到资源管理器响应的事务已提交的状态,完成事务的提交
  • doRollback 阶段:事务管理器向参与全局事务的资源管理器发送 Rollback 消息,资源管理器会利用 Undo Log 日志信息回滚事务,并释放执行事务期间占用的资源,向事务管理器返回事务已回滚的状态。事务管理器收到资源管理器返回的事务已回滚的消息,完成事务回滚

2. 存在的问题

  • 3PC 模型主要解决了单点故障问题,并减少了事务执行过程中产生的阻塞现象
  • 3PC 模型中,如果资源管理器无法及时收到来自事务管理器发出的消息,那么资源管理器就会在一段时间后执行提交事务的操作,而不是一直持有事务的资源并处于阻塞状态,但是这种机制会导致数据不一致的问题

参考

  • 《深入理解分布式事务:原理与实战》