【分布式】分布式事务及其解决方案

一、分布式事务

事务指的是一组操作，要么全部成功，要么全部失败。事务有四个特性ACID，具体涵义参考数据库原理这篇博客

这里举一个银行转账的例子来说明本地事务和分布式事务的区别。

本地事务可依赖数据库本身提供的事务特性来实现，因此以下逻辑可以控制本地事务：

begin transaction；
    //1.本地数据库操作：张三减少金额
    //2.本地数据库操作：李四增加金额
commit transation;

但是在分布式环境下，会变成下边这样：

begin transaction；
    //1.本地数据库操作：张三减少金额
    //2.远程调用：让李四增加金额
commit transation;

可以设想，当远程调用让李四增加金额成功了，由于网络问题远程调用并没有返回，此时本地事务提交失败就回滚了张三减少金额的操作，此时张三和李四的数据就不一致了。

​ 因此在分布式架构的基础上，传统数据库事务就无法使用了，张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。

二、分布式事务的解决方案

1. 全局事务

（1）DTP模型

DTP模型规定了要实现分布式事务的体系结构，包含多个协议、算法和机制等，以确保分布式环境下的事务能够以一致和可靠的方式执行。

它规定了要实现分布式事务，需要三种角色：

• AP：Application 应用系统它就是我们开发的业务系统，在我们开发的过程中，可以使用资源管理器提供的事务接口来实现分布式事务。

• TM：Transaction Manager 事务管理器

  • 提供分布式事务的操作接口供业务系统调用。这些接口称为TX接口
  • 事务管理器管理着所有的资源管理器，通过它们提供的XA接口来同一调度这些资源管理器
  • DTP只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，可采用2PC、3PC、Paxos等协议实现

• RM：Resource Manager 资源管理器

  • 能够提供数据服务的对象都可以是资源管理器，比如：数据库、消息中间件、缓存等
  • 资源管理器能够提供单数据库的事务能力，它们通过XA接口，将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理
  • XA是DTP模型定义的接口，用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力
  • DTP只是一套实现分布式事务的规范，RM具体的实现是由数据库厂商来完成的

DTP主要侧重于业务实现分布式事务时的体系结构，而后面介绍的2PC和3PC则侧重于实现的逻辑，相当于DTP是壳，而2PC/3PC等协议是核。

举个例子，在通信的场景下，DTP的作用相当于定义了通信中需要有发送方和接受方，要求这两方都需要有发送和接收的能力，要求通过一系列的通信方式使得他们能正常通话。而2PC/3PC则是相当于定义了具体的通信逻辑，比如TCP三次握手和IP协议等等。

（2） 两阶段提交协议（2PC）

原理

两阶段提交又称 2PC，是一个非常经典的强一致、中心化的原子提交协议。两阶段提交协议经常用来实现分布式事务。

2PC协议中，节点分为两种角色

• 事务协调者：协调事务的功能，通常一个系统中只有一个
• 事务参与者：一般包含多个

将整个事务流程分为两个阶段：

• 准备阶段（Prepare phase）：事务协调者给每个参与者发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务操作（如写本地的redo和undo日志），但不提交，到达一种“万事俱备，只欠东风”的状态
  • 事务询问：协调者向所有的参与者发送事务预处理请求，并开始等待各参与者的响应
  • 执行本地事务：各个参与者节点执行本地事务操作，但在执行完成后并不会真正提交数据库本地事务
  • 各参与者向协调者反馈事务询问的响应：各参与者根据自身事务执行情况反馈，成功反馈yes，失败返回no
• 提交阶段（commit phase）：根据不同的情况做出相应的操作
  • 所有的参与者反馈给协调者的信息都是 Yes，则执行事务提交
  • 有一个或者多个返回 No，或有超时，回滚

二阶段提交的缺点

• 性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。也就是说从投票阶段到提交阶段完成这段时间，资源是被锁住的，对性能影响比较大。
• 单点故障：主要指协调者发生故障，这种情况下参与者会一直阻塞下去，尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
• 网络分区是会数据不一致：阶段二中，当协调者向参与者发送commit请求之后，发生了网络分区，那就只有一部分参与者执行了commit，产生了数据不一致的情况

（3）三阶段提交协议（3PC）

原理

三阶段提交（Three-phase commit）是二阶段提交（2PC）的改进版本。三阶段提交协议（3PC）主要是为了解决两阶段提交协议的单点故障阻塞问题，2PC 存在的问题是当协调者崩溃时，参与者可能在协调者恢复之前保持阻塞。

增加的改进措施：

• 增加超时机制：不只有协调者能感知参与者的超时，参与者也能感知协调者的超时，当其超时时，就释放自身的资源，不再继续阻塞
• 在准备阶段前多加了一个准备阶段，变成有 CanCommit、PreCommit、DoCommit 三个阶段

过程：

• CanCommit 阶段：协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应，这个过程很轻量，比如尝试获取数据库锁
  • 事务询问：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应
  • 响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
• PreCommit阶段：根据第一阶段接受到的结果采取相应操作
  • 都是yes，进行预执行，参与者进行事务预提交，相应反馈
  • 有no或超时，参与者中断事务，释放其资源
• doCommit阶段：该阶段进行真正的事务提交，也可以分为以下两种情况
  • 执行提交：协调者发送事务commit通知，参与者执行commit操作，反馈
  • 中断事务：协调者没有收到所有的ack，或者有超时情况，中断事务，参与者进行事务的rollback

几种情况示意图如下

2. 基于可靠消息服务

通过消息中间件来实现。

假设有A和B两个系统，分别可以处理任务A和任务B。此时系统A中存在一个业务流程，需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。

• 在系统A处理任务A前，首先向消息中间件发送一条消息
• 消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在。
• 消息中间件持久化成功后，便向系统A返回一个确认应答；
• 系统A收到确认应答后，则可以开始处理任务A；
• 任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了。
• 消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行；
• 当任务B执行完成后，系统B向消息中间件返回一个确认应答，告诉消息中间件该消息已经成功消费，此时，这个分布式事务完成。

总结一下上述过程的特点，

• 消息中间件扮演者分布式事务协调者的角色。
• 系统A完成任务A后，到任务B执行完成之间，会存在一定的时间差。在这个时间差内，整个系统处于数据不一致的状态，但这短暂的不一致性是可以接受的，因为经过短暂的时间后，系统又可以保持数据一致性，满足BASE理论。

上述过程中，如果任务A处理失败，那么需要进入回滚流程，如下图所示：

• 向消息中间件发送Rollback请求。和发送Commit请求一样，系统A发完之后便可以认为回滚已经完成，它便可以去做其他的事情。
• 消息中间件收到回滚请求后，直接将该消息丢弃，而不投递给系统B，从而不会触发系统B的任务B
  
  Commit和Rollback指令都有可能在传输途中丢失，当出现这种情况的时候，消息中间件通过超时询问机制保证事务的一致性

询问的结果有三种

• 提交若获得的状态是“提交”，则将该消息投递给系统B。
• 回滚若获得的状态是“回滚”，则直接将条消息丢弃。
• 处理中若获得的状态是“处理中”，则继续等待。
  
  为保证一致性，消息中间件必须确保发送的消息能被下游接收到，如果超时就会重传，直到得到应答

3. 最大努力通知

是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务。

最大努力通知型的实现方案，一般符合以下特点：

​ 1、不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。

​ 2、定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。

4. TCC

TCC分别对应Try、Confirm和Cancel三种操作

• Try：预留业务资源
• Confirm：确认执行业务操作
• Cancel：取消执行业务操作

TCC实际上把数据库层的二阶段提交上提到了应用层来实现，即Try、Confirm和Cancel操作功能需业务提供