1.Seata介绍
Seata是由阿里中间件团队发起的开源项目 Fescar,后更名为Seata,它是一个是开源的分布式事务框架。
传统2PC的问题在Seata中得到了解决,它通过对本地关系数据库的分支事务的协调来驱动完成全局事务。
是工作在应用层的中间件。主要优点是性能较好,且不长时间占用连接资源,它以高效并且对业务0侵入的方式解决微服 务场景下面临的分布式事务问题,它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。
1.1. Seata的设计思想
seata 采用的是大量运用在数据库软件的 Write Ahead Log 思想,即把事务的信息以事务日志的方式记录下来。这种处理方式,实际上是对传统两阶段提交的一种改进和优化。主要有几个关键点:
-
传统两阶段提交协议是阻塞协议,性能差
-
传统两阶段提交协议高可用性不好
-
传统两阶段提交协议的全局事务隔离机制不支持
-
根据八二原则,80% 的涉及到全局事务的业务是能正常完成并提交的。
因此,seata 采取的做法是,一个事务分支的数据库操作执行完后,马上进行本地事务的提交,从而释放相关的数据库 资源。
-
分支事务中数据的 本地锁 由本地事务管理,在分支事务 Phase1 结束时释放。·
-
同时,随着本地事务结束,连接 也得以释放。·
-
分支事务中数据的 全局锁 在事务协调器侧管理,在决议 Phase2 全局提交时,全局锁马上可以释放。只有在决议全 局回滚的情况下,全局锁 才被持有至分支的 Phase2 结束。
1.2.本地事务执行流程
在进行本地提交的前提是,seata 会解析 SQL,获取数据库表的元数据,根绝 SQL 类型,选择性地生成数据的前置镜像和后置镜像, 保存在 undolog 表中,并且要求与保存 undolog 与业务 SQL 在同一个本地事务内。
这就保证了:
-
如果一个本地事务被提交,那么必定对应着相应的 undo_log
-
如果保存 undo_log 保存失败,那么业务 SQL 也会失败
1.3.全局事务提交流程
因为每个分支事务的本地事务都已经被提交,所以如果全局事务能够顺利进行到“提交“这一阶段,那么意味着所有事务分支的本地事 务都已经被提交了,数据的一致性已经得到了保证。
这个时候全局事务的提交就变得十分轻量级,就是把 undo_log 对应的记录删掉即可,即使是当时删除失败了,也已经不会影响全局事 务的最终结果,这次删不了,那就待会再删,程序删不了,没事,顶多人工删。
1.4.全局事务回滚流程
如果全局事务的任何一个事务分支失败了,那么全局事务就进入“回滚“流程,回滚时依据先前保存好数据镜像,将原来的数据回放回去。
如果全局回放成功,那么数据的一致性也就得到了保证,如果回放不成功,那么事务就进入异常。应对异常,可能需要重试,可能需要人工介入。