Seata分布式事务

1.Seata介绍

Seata是由阿里中间件团队发起的开源项目 Fescar，后更名为Seata，它是一个是开源的分布式事务框架。

传统2PC的问题在Seata中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务。

是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服 务场景下面临的分布式事务问题，它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。

1.1. Seata的设计思想

seata 采用的是大量运用在数据库软件的 Write Ahead Log 思想，即把事务的信息以事务日志的方式记录下来。这种处理方式，实际上是对传统两阶段提交的一种改进和优化。主要有几个关键点：

1. 传统两阶段提交协议是阻塞协议，性能差

2. 传统两阶段提交协议高可用性不好

3. 传统两阶段提交协议的全局事务隔离机制不支持

4. 根据八二原则，80% 的涉及到全局事务的业务是能正常完成并提交的。

因此，seata 采取的做法是，一个事务分支的数据库操作执行完后，马上进行本地事务的提交，从而释放相关的数据库 资源。

 

• 分支事务中数据的 本地锁 由本地事务管理，在分支事务 Phase1 结束时释放。·

• 同时，随着本地事务结束，连接 也得以释放。·

• 分支事务中数据的 全局锁 在事务协调器侧管理，在决议 Phase2 全局提交时，全局锁马上可以释放。只有在决议全 局回滚的情况下，全局锁 才被持有至分支的 Phase2 结束。

1.2.本地事务执行流程

在进行本地提交的前提是，seata 会解析 SQL，获取数据库表的元数据，根绝 SQL 类型，选择性地生成数据的前置镜像和后置镜像， 保存在 undolog 表中，并且要求与保存 undolog 与业务 SQL 在同一个本地事务内。

这就保证了：

1. 如果一个本地事务被提交，那么必定对应着相应的 undo_log

2. 如果保存 undo_log 保存失败，那么业务 SQL 也会失败

 

1.3.全局事务提交流程

因为每个分支事务的本地事务都已经被提交，所以如果全局事务能够顺利进行到“提交“这一阶段，那么意味着所有事务分支的本地事 务都已经被提交了，数据的一致性已经得到了保证。

这个时候全局事务的提交就变得十分轻量级，就是把 undo_log 对应的记录删掉即可，即使是当时删除失败了，也已经不会影响全局事 务的最终结果，这次删不了，那就待会再删，程序删不了，没事，顶多人工删。

 

1.4.全局事务回滚流程

如果全局事务的任何一个事务分支失败了，那么全局事务就进入“回滚“流程，回滚时依据先前保存好数据镜像，将原来的数据回放回去。

如果全局回放成功，那么数据的一致性也就得到了保证，如果回放不成功，那么事务就进入异常。应对异常，可能需要重试，可能需要人工介入。

 

2.Seata在dubbo中的使用

2.1.新增mvn依赖

在需要增加分布式事务的模块加上