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

一、分布式事务

事务指的是一组操作，要么全部成功，要么全部失败。事务有四个特性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指令都有可能在传输途中丢失，当出现这种情况的时候，消息中间件通过超时询问机制保证事务的一致性