分布式事务

发表于 | 分类于

前言

常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。

所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务。

例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。

2PC

在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。

当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。

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

所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。

准备阶段

事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。

可以进一步将准备阶段分为以下三个步骤：

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

  2. 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）

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

提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

2PC存在的问题

  1. 单点故障。协调者发生故障。参与者会一直阻塞下去等待指令。参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。这里可以采用备份的协调器，所有参与者将回复发给备份协调器，由它承担协调器的功能。

    参与者发生永久故障，协调器将被阻塞直到所有参与者回复了。

    在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到cohort的消息则默认失败。

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

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

3PC

考虑一个问题，就是若在2PC的第二阶段中参与者和协调者都宕机的情况下，挂了的这个参与者在挂之前已经执行了第二阶段协调者的指令（要么是commit，要么是rollback）且只有这台挂了。所以就算有了新的协调者，但是获取不了宕机的参与者最后执行的情况。协调者不知道该给没宕机的参与者什么指令。

我想的是可不可以让协调者重新执行这个事务呢，上一个就不管了。这样是是不行的。因为没有挂掉的参与者已经执行了DAO，必需等到一个commit或者rollback。重新执行的话会造成多个DAO的重复执行。

所以必需给出一个指令，但是假设给出了指令和宕机的那个参与者不一致，等到宕机的参与者回复的时候，参与者就不能保证事务的一致性了。

针对上述的问题3PC提出了解决方案。

与两阶段提交不同的是，三阶段提交有两个改动点。除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。但是这个阶段没有执行DAO。

PreCommit阶段

协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

  1. 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。参与者进入到prepared状态。
  2. 假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。所有参与者退出prepared状态。

这就是三个阶段的好处，它可以保证在最后提交阶段之前各参与节点的状态是一致的。要么是都是prepared，要么都不是。这个就可以解决2PC中当参与者和协调者都宕机的时候，新的协调者获取不了参与者宕机之前执行的是commit还是rollback，但是它可以观察其他参与者就可以知道。因为每一个参与者的状态是一致的。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

  1. 中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
  2. 执行提交

2PC和3PC的区别

像2PC中的网络问题，3PC也不能很好的解决。但是针对等待指令或者回复，3PC对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制，所以可以减少阻塞的时间。

3PC也解决了，2PC中因为协调者、参与者都宕机情况下不一致问题的。

2PC和3PC是基于XA的，XA 协议通常实现在数据库资源层，直接作用于资源管理器上。因此，基于 XA 协议实现的分布式事务产品，无论是分布式数据库，还是分布式事务框架，对业务几乎都没有侵入，就像使用普通数据库一样。是依靠MySQL XA实现的，是DB层实现。

TCC

TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖资源管理器（RM）对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。对代码的侵入性比较大。通常可以使用一些框架来实现三段业务逻辑的划分。

因此，针对一个具体的业务服务，TCC 分布式事务模型需要业务系统提供三段业务逻辑：

  1. 初步操作 Try：完成所有业务检查，预留必须的业务资源。
  2. 确认操作 Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务有且只能成功一次。
  3. 取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。

你想输入的替代文字