Seata的一些介绍

在今晚的月色下刺猹

已于 2022-04-01 10:09:11 修改

阅读量382

点赞数

分类专栏： mysql 文章标签：数据库 Seata 分布式事务

于 2022-03-05 16:58:47 首次发布

本文链接：https://blog.csdn.net/caiqianzhigai0859/article/details/123279432

版权

mysql 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Seata是什么

基本概念

分布式事务

一般事务是一个服务访问一个数据库，本地锁和数据库锁就能解决了，但是涉及到多个服务或者数据库就不一样了，比如：

多个服务需要在同一个事务：像购物场景，付款和减库存需要在一个事务里，但是两个功能可能分别在账户服务和商品服务里面；
一个服务但是操作多个数据库：数据量上来之后分库操作就是很平常的操作了，一般的本地事务依赖的是数据库提供的事务性，但是多个数据库的事务数据库事务就无能为力了；
当然还有多个服务操作多个数据库的情况。

Seata

一款分布式事务的解决方案，致力于提供高性能和简单易用的分布式事务服务，并且对业务代码是0入侵的；

Seata的一些术语

TC（事务协调者）：这是一个单独部署的服务，相当于整个分布式事务的管理者，维护分支事务的状态，驱动全局事务的提交或者回滚，也就是说分支事务要怎么做都要听它的；
TM（事务管理器）：开启全局事务、提交或者回滚全局事务，相当于TC和RM的中间商；
RM（资源管理器）：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务的提交和回滚，也就是真正做事的，真正执行事务的角色；

运行过程

TM开启全局事务，向TC注册，TC会开启一个全局锁，并返回XID；
TM将XID传给RM，RM先用XID向TC注册获取分支事务BID，然后执行真正的业务事务，修改数据库数据，RM还会保存执行前和执行后的两份数据记录，并将这两份记录作为回滚记录写入数据库中；
RM会将执行结果通知给TM，如果有一个RM执行异常了，TM就会通知TC回滚事务，随后TC就会通知所有的RM进行回滚操作；
如果所有的RM都执行成功了，TM也会通知TC完成事务，随后TC会通知所有的RM删除之前保存的回滚记录；
因为TC、TM、RM之间的通信都是通过网络进行的，是不可靠的，所以TC会有四个定时任务，定时处理系统中的超时事务、异步提交事务、重试回滚事务和重试提交事务，以此来保证分布式事务的一致性。

Seata的四种模式

AT模式

现在一般公司都是采用的这种模式，也是Seata文档中介绍最详细的一种模式。AT模式的工作机制采用的是两阶段提交，跟上面说的流程大体相似。

工作机制

一阶段：执行sql，以update product set name = ‘GTS’ where name = ‘TXC’;sql语句为例说明
1、解析SQL：得到SQL的类型（update），表名（product）、语句条件等等；
2、查询前置镜像：根据解析SQL语句，然后查询出相关数据记录，生成前置镜像；
3、执行业务SQL；
4、查询后置镜像：查询出执行SQL之后相关的数据记录，生成后置镜像；
5、添加回滚日志：用前后的镜像数据和SQL相关的信息生成一条回滚日志数据，添加到UNDO_LOG表中；
6、注册分支：向TC申请一个对product表中，name='TXC’记录的全局锁；
7、提交事务：获取到全局锁之后，将业务SQL和回滚日志数据一并提交；
8、上报结果：将事务提交结果上报给TC，释放本地锁和连接资源。
二阶段-回滚：如果后续的RM执行出现异常，TC就会通知前面的RM进行回滚操作
1、开启本地事务：RM收到TC的回滚请求后，会先开启一个本地事务；
2、查询回滚日志：通过XID和BID到UNDO_LOG表中查询到之前添加的回滚日志数据；
3、校验数据：对比回滚日志中的后置镜像数据和当前数据，如果有出入，则说明已经有其他事务修改了这条数据，这个时候就需要其他策略处理或者人工介入；
4、回滚操作：根据回滚日志中的前置镜像和SQL相关信息生成回滚SQL并执行；
5、提交本地事务：提交事务并向TC上报回滚执行结果。
二阶段-提交：如果所有的RM都提交成功，TC就会通知所有的RM提交成功了
1、TC通知RM：TC自己会去异步删除全局事务、分支事务和全局锁信息，并异步通知RM；
2、RM删除UNDO_LOG记录：RM收到TC的异步通知之后，会各自删除自己在UNDO_LOG表中添加的数据。

一些知识点

存储模式：TC记录的信息有全局事务（XID）、分支事务（BID）和全局锁（LOCK），这些信息的存储方式有三种：db（数据库）、redis（缓存插件）和file（文件）；
隔离级别：AT的默认的事务隔离级别是读未提交，一般数据库的默认隔离级别是读已提交，如果特定场景需要读已提交的隔离级别需要使用SELECT … FOR UPDATE语句，但是这样这个查询语句也需要先获取全局锁才能执行。

TCC模式

TCC模式和AT模式大体流程上是相似的，只是AT模式是基于支持本地ACID事务的关系型数据库，而TCC不需要依赖这个，可以有更广泛的应该，但是作为代价就需要自己实现两阶段提交了，大体区别是：

AT模式：
一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
二阶段 commit 行为：马上成功结束，自动异步批量清理回滚日志。
二阶段 rollback 行为：通过回滚日志，自动生成补偿操作，完成数据回滚。
TCC模式：
一阶段 prepare 行为：调用自定义的 prepare 逻辑。
二阶段 commit 行为：调用自定义的 commit 逻辑。
二阶段 rollback 行为：调用自定义的 rollback 逻辑。
相当于自动挡和手动挡的区别