一文搞明白分布式事务解决方案 , 真的 so easy..

原创 :江南一点雨 

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

那么今天，我就再来一篇文章，和大家捋一捋这个话题。以下的内容主要围绕阿里的 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 了。

经过上面的