事务是数据库的概念，数据库事务（ACID：原子性、一致性、隔离性和持久性）；
分布式事务的产生，是由于数据库的拆分和分布式架构(微服务)带来的，在常规情况下，我们在一个进程中操作一个数据库，这属于本地事务，如果在一个进程中操作多个数据库，或者在多个进程中操作一个或多个数据库，就产生了分布式事务；
（1）数据库分库分表就产生了分布式事务；
（2）项目拆分服务化也产生了分布式事务；
Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务；
Seata为用户提供了AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案；
四种事务模式中，XA模式正在开发中...，其他事务模式已经实现；
目前使用的流行度情况是：AT > TCC > Saga；
我们可以参看seata各公司使用列表：
https://github.com/seata/seata/issues/1246 大部分公司都采用的AT事务模式；
Seata已经在国内很多团队开始落地，其中不乏有大公司；
Github：https://github.com/seata/seata
官网：http://seata.io/
当前最新版本：1.3.0
在Seata的架构中，一共有三个角色：
TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚；
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务；
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交互以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚；
其中TC为单独部署的 Server 服务端，TM和RM为嵌入到应用中的 Client 客户端；
在Seata中，一个分布式事务的生命周期如下：
TM请求TC开启一个全局事务，TC会生成一个XID作为该全局事务的编号，XID会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起；
RM请求TC将本地事务注册为全局事务的分支事务，通过全局事务的XID进行关联；
TM请求TC告诉XID对应的全局事务是进行提交还是回滚；
TC驱动RM将XID对应的自己的本地事务进行提交还是回滚；
我们先部署单机环境的 Seata TC Server，用于学习或测试，在生产环境中要部署集群环境；
因为TC需要进行全局事务和分支事务的记录，所以需要对应的存储，目前，TC有三种存储模式( store.mode )：
file模式：适合单机模式，全局事务会话信息在内存中读写，并持久化本地文件 root.data，性能较高；
db模式：适合集群模式，全局事务会话信息通过 db 共享，相对性能差点；
redis模式：解决db存储的性能问题；
我们先采用file模式，最终我们部署单机TC Server如下图所示：
下载Seata：http://seata.io/zh-cn/blog/download.html
解压：tar -zxvf seata-server-1.3.0.tar.gz
切换cd seata
默认seata-server.sh脚本设置的jvm内存参数2G，我们再虚拟机里面做实验，可以改小一点；
在bin目录下启动：./seata-server.sh
默认配置下，Seata TC Server 启动在 8091 端口；
因为我们没有修改任何配置文件，默认情况seata使用的是file模式进行数据持久化，所以可以看到用于持久化的本地文件 root.data；
在Spring Boot单体项目中，如果使用了多数据源，就需要考虑多个数据源的数据一致性，即产生了分布式事务的问题，我们采用Seata的AT事务模式来解决该分布式事务问题；
以电商购物下单为例：
其中每个库中的undo_log表，是 Seata AT模式必须创建的表，主要用于分支事务的回滚；
测试：http://localhost:8080/order?userId=1&productId=1
前提
基于支持本地 ACID 事务的关系型数据库；（mysql、oracle）
Java 应用，通过JDBC访问数据库；
整体机制
就是两阶段提交协议的演变：
一阶段：
“业务数据“和“回滚日志记录“在同一个本地事务中提交，释放本地锁和连接资源；
二阶段：
如果没有异常异步化提交，非常快速地完成；
如果有异常回滚通过一阶段的回滚日志进行反向补偿；
具体举例说明整个AT分支的工作过程：
业务表：product
Field Type Key
id bigint(20) PRI
name varchar(100)
since varchar(100)AT分支事务的业务逻辑：
update product set name = 'GTS' where name = 'TXC';
一阶段过程：
1、解析SQL，得到SQL的类型（UPDATE），表（product），条件（where name = 'TXC'）等相关的信息；
2、查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据；
select id, name, since from product where name = 'TXC';
得到前镜像：
id name since
1 TXC 2014
3、执行业务 SQL：更新这条记录的 name 为 'GTS'；
4、查询后镜像：根据前镜像的结果，通过 主键 定位数据；
select id, name, since from product where id = 1;
得到后镜像：
id name since
1 GTS 2014
5、插入回滚日志：把前后镜像数据以及业务SQL相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中；
6、分支事务提交前，向TC注册分支，申请product表中，主键值等于1的记录的全局锁（在当前的同一个全局事务id范围内是可以申请到全局锁的，不同的全局事务id才会排斥）；
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记录；
回滚日志表：
Field Type
branch_id bigint PK
xid varchar(100)
context varchar(128)
rollback_info longblob
log_status tinyint
log_created datetime
log_modified datetime
SQL建表语句：
CREATE TABLE `undo_log` (
`id` bigint NOT NULL AUTO_INCREMENT,
`branch_id` bigint NOT NULL,
`xid` varchar(100) NOT NULL,
`context` varchar(128) NOT NULL,
`rollback_info` longblob NOT NULL,
`log_status` int NOT NULL,
`log_created` datetime NOT NULL,
`log_modified` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
转载自：https://www.bilibili.com/video/BV1vy4y167Dc