乐趣区

关于java:一文搞明白分布式事务解决方案真的-so-easy

jiezi

@[toc]
分布式事务，咱们前边也聊过很屡次了，网上其实也有不少文章在介绍分布式事务，不过里边都会波及到不少专业名词，看的大家云里雾里，所以还是有一些小伙伴在微信上问我。

那么明天，我就再来一篇文章，和大家捋一捋这个话题。以下的内容次要围绕阿里的 seata 来和大家解释。

1. 什么是反向弥补

首先，来和大家解释一个名词，大家在看分布式事务相干材料的时候，常常会看到一个名词：反向弥补。啥是反向弥补呢？

我举一个例子：假如咱们当初有三个微服务别离是 A、B、C，当初在 A 服务中别离调用 B 和 C 服务，为了确保 B 和 C 同时胜利或者同时失败，咱们须要应用到分布式事务。然而依照咱们之前对本地事务的了解，B 和 C 中的本地事务，当 B 服务中的事务执行结束并且提交之后，当初 C 服务中的事务出现异常须要回滚了，然而，B 曾经提交了还怎么回滚呀？

此时咱们所说的回滚其实并不是传统意义上的，通过 MySQL redo log 日志来回滚的那种，而是通过一条更新 SQL，再把 B 服务中曾经更改过的数据还原。

这就是咱们所说的反向弥补！

2. 基本概念梳理

Seata 中有三个外围概念：

  • TC (Transaction Coordinator) – 事务协调者：保护全局和分支事务的状态，驱动全局事务提交或回滚。
  • TM (Transaction Manager) – 事务管理器：定义全局事务的范畴，开始全局事务、提交或回滚全局事务。
  • RM (Resource Manager) – 资源管理器：治理分支事务处理的资源(Resource)，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

其中，TC 为独自部署的 Server 服务端，TM 和 RM 为嵌入到利用中的 Client 客户端。咱们来看如下一张图片：

这张图基本上把这个三个概念解释分明了。

其实不看这张图，咱们大略也能猜到分布式事务的实现原理：首先得有一个全局的事务协调者（TC），各个本地事务（RM）在开始执行的时候，或者在执行的过程中，及时将本人的状态报告给全局事务协调者，这个全局事务协调者晓得每一个分支事务目前的执行状态，当他（TC）发现所有的本地事务都执行胜利的时候，就告诉大家一起提交；当他发现在本次事务中，有人执行失败的时候，就告诉大家一起回滚（当然这个回滚不肯定是真的回滚，而是反向弥补）。那么一个事务什么时候开始什么时候完结呢？也就是事务的边界在哪里？seata 中的分布式事务都是通过 @GlobalTransactional 注解来实现的，换句话说，这个注解该加在哪里？增加该注解的中央其实就是事务管理器 TM 了。

通过下面的介绍，小伙伴们应该明确了，其实用 Seata 实现分布式事务没有设想的那么难，原理还是十分 Easy 的。

Seata 中波及到四种不同的模式，接下来介绍的四种不同模式，其实都是在说当有一个本地事务失败的时候，该如何回滚？这就是咱们前面要说的四种不同的分布式事务模式了。

3. 什么是两阶段提交

先来看上面一张图：

这张图里波及到三个概念：

  • AP：这个不必多说，AP 就是应用程序自身。
  • RM：RM 是资源管理器，也就是事务的参与者，大部分状况下就是指数据库，一个分布式事务往往波及到多个 RM。
  • TM：TM 就是事务管理器，创立分布式事务并协调分布式事务中的各个子事务的执行和状态，子事务就是指在 RM 上执行的具体操作。

那么什么是两阶段 (Two-Phase Commit, 简称 2PC) 提交？

两阶段提交说白了情理很简略，松哥举个简略例子来和大家阐明两阶段提交：

比方上面一张图：

咱们在 Business 中别离调用 Storage 与 Order、Account，这三个中的操作要同时胜利或者同时失败，然而因为这三个分处于不同服务，因而咱们只能先让这三个服务中的操作各自执行，三个服务中的事务各自执行就是两阶段中的第一阶段。

第一阶段执行结束后，先不要急着提交，因为三个服务中有的可能执行失败了，此时须要三个服务各自把本人一阶段的执行后果报告给一个事务协调者，事务协调者收到音讯后，如果三个服务的一阶段都执行胜利了，此时就告诉三个事务别离提交，如果三个服务中有服务执行失败了，此时就告诉三个事务别离回滚。

这就是所谓的两阶段提交。

总结一下：两阶段提交中，事务分为参与者（例如上图的各个具体服务）与协调者，参与者将操作成败告诉协调者，再由协调者依据所有参与者的反馈情报决定各参与者是要提交操作还是停止操作，这里的参与者能够了解为 RM，协调者能够了解为 TM。

不过 Seata 中的各个分布式事务模式，根本都是在二阶段提交的根底上演变进去的，因而并不齐全一样，这点须要小伙伴们留神。

4. AT 模式

AT 模式是一种全自动的事务回滚模式。

整体上来说，AT 模式是两阶段提交协定的演变：

  1. 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，开释本地锁和连贯资源。
  2. 二阶段则分两种状况：
    2.1 提交异步化，十分疾速地实现。
    2.2 回滚通过一阶段的回滚日志进行反向弥补。

大抵上的逻辑就是下面这样，咱们通过一个具体的案例来看看 AT 模式是如何工作的：

假如有一个业务表 product，如下：

当初咱们想做如下一个更新操作：

update product set name = 'GTS' where name = 'TXC';

步骤如下：

一阶段：

  1. 解析 SQL：失去 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相干的信息。
  2. 查问前镜像：依据解析失去的条件信息，生成查问语句，定位数据（查找到更新之前的数据）。
  3. 执行下面的更新 SQL。
  4. 查问后镜像：依据前镜像的后果，通过 主键 定位数据。
  5. 插入回滚日志：把前后镜像数据以及业务 SQL 相干的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
  6. 提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁。
  7. 本地事务提交：业务数据的更新和后面步骤中生成的 UNDO LOG 一并提交。
  8. 将本地事务提交的后果上报给 TC。

二阶段：

二阶段分两种状况，提交或者回滚。

先来看 回滚 步骤：

  1. 首先收到 TC 的分支回滚申请，开启一个本地事务，执行如下操作。
  2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录（这条记录中保留了数据批改前后对应的镜像）。
  3. 数据校验：拿 UNDO LOG 中的后镜像与以后数据进行比拟，如果有不同，阐明数据被以后全局事务之外的动作做了批改。这种状况，须要依据配置策略来做解决。
  4. 依据 UNDO LOG 中的前镜像和业务 SQL 的相干信息生成并执行回滚的语句：update product set name = 'TXC' where id = 1;
  5. 提交本地事务。并把本地事务的执行后果（即分支事务回滚的后果）上报给 TC。

再来看 提交 步骤：

  1. 收到 TC 的分支提交申请，把申请放入一个异步工作的队列中，马上返回提交胜利的后果给 TC。
  2. 异步工作阶段的分支提交申请将异步和批量地删除相应 UNDO LOG 记录。

大抵上就是这样一个步骤，思路还是比拟清晰的，就是当你要更新一条记录的时候，零碎将这条记录更新之前和更新之后的内容生成一段 JSON 并存入 undo log 表中，未来要回滚的话，就依据 undo log 中的记录去更新数据（反向弥补），未来要是不回滚的话，就删除 undo log 中的记录。

在整个过程中，开发者只须要额定创立一张 undo log 表就行了，而后给须要解决全局事务的中央加上 @GlobalTransactional 注解就行了。

其余的提交呀回滚呀都是全自动的，比拟省事。所以如果你我的项目中抉择了用 seata 来解决分布式事务，那么用 AT 模式的概率还是相当高的。

5. TCC 模式

TCC（Try-Confirm-Cancel）模式就带一点手动的感觉了，它也是两阶段，然而和 AT 又不太一样，咱们来看下流程。

官网上有一张 TCC 的流程图，咱们来看下：

能够看到，TCC 也是分为两阶段：

  • 第一阶段是 prepare，在这个阶段次要是做资源的检测和预留工作，例如银行转账，这个阶段就先去查看下用户的钱够不够，不够就间接抛异样，够就先给解冻上。
  • 第二阶段是 commit 或 rollback，这个次要是等各个分支事务的一阶段都执行结束，都执行结束后各自将本人的状况报告给 TC，TC 一统计，发现各个分支事务都没有异样，那么就告诉大家一起提交；如果 TC 发现有分支事务产生异样了，那么就告诉大家回滚。

那么小伙伴可能也发现了，下面这个流程中，一共波及到了三个办法，prepare、commit 以及 rollback，这三个办法都齐全是用户自定义的办法，都是须要咱们本人来实现的，所以我一开始就说 TCC 是一种手动的模式。

和 AT 相比，大家发现 TCC 这种模式其实是不依赖于底层数据库的事务反对的，也就是说，哪怕你底层数据库不反对事务也没关系，反正 prepare、commit 以及 rollback 三个办法都是开发者本人写的，咱们本人将这三个办法对应的流程捋顺就行了。

6. XA 模式

如果小伙伴们懂得 MySQL 数据库的 XA 事务，那么一下子就懂得 seata 中的 XA 模式是咋回事了。

XA 标准是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）规范。

XA 标准形容了全局的事务管理器与部分的资源管理器之间的接口。XA 标准的目标是容许的多个资源（如数据库，应用服务器，音讯队列等）在同一事务中拜访，这样能够使 ACID 属性逾越应用程序而放弃无效。

XA 标准应用两阶段提交来保障所有资源同时提交或回滚任何特定的事务。

XA 标准在上世纪 90 年代初就被提出。目前，简直所有支流的数据库都对 XA 标准提供了反对。

XA 事务的根底是两阶段提交协定。须要有一个事务协调者来保障所有的事务参与者都实现了筹备工作(第一阶段)。如果协调者收到所有参与者都筹备好的音讯，就会告诉所有的事务都能够提交了（第二阶段）。MySQL 在这个 XA 事务中表演的是参与者的角色，而不是协调者(事务管理器)。

MySQL 的 XA 事务分为外部 XA 和内部 XA。内部 XA 能够参加到内部的分布式事务中，须要应用层染指作为协调者；外部 XA 事务用于同一实例下跨多引擎事务，由 Binlog 作为协调者，比方在一个存储引擎提交时，须要将提交信息写入二进制日志，这就是一个分布式外部 XA 事务，只不过二进制日志的参与者是 MySQL 自身。MySQL 在 XA 事务中表演的是一个参与者的角色，而不是协调者。

换言之，MySQL 人造的就能够通过 XA 标准来实现分布式事务，只不过须要借助一些内部利用的反对。咱们来看下 Seata 中的 XA 模式应用流程。

先来看一张来自官网的图片：

能够看到，这也是一个两阶段提交：

  1. 一阶段：业务 SQL 操作放在 XA 分支中进行，XA 分支实现后，执行 XA prepare，由 RM 对 XA 协定的反对来保障长久化（即之后任何意外都不会造成无奈回滚的状况）。
  2. 二阶段分两种状况：提交或者回滚：
  3. 分支提交：执行 XA 分支的 commit
  4. 分支回滚：执行 XA 分支的 rollback

和后面两种模式的区别在于，XA 模式中的回滚，是正儿八经的回滚，是咱们传统意义上所了解的回滚，而不是一种反向弥补。

7. Saga 模式

最初再来看看 saga 模式，这种模式利用很少，大家作为理解即可。

saga 模式是 seata 提供的长事务解决方案，然而长事务是咱们在开发中应该防止的，因为效率低并且容易造成死锁。

这个 saga 模式就有点像流程引擎，开发者先本人画一个流程引擎，把整个事务中波及到的办法都囊括进来，每一个办法返回什么的时候就是失常的，返回什么就是异样的，失常的就持续往下走，异样的就执行另一套流程，也就是咱们须要提前准备好两套办法，第一套是各种失常状况的执行流程，第二套则是产生异样之后的执行流程，相似上面这样：

绿色的都是失常的流程，红色的则是产生异样后回滚的流程。回滚中也是一种反向弥补。

8. 小结

好啦，分布式事务 4 种模式就和大家说分明啦～前面有空整几个案例一起实际下！

退出移动版