分布式事务 - seata

最新推荐文章于 2024-05-15 09:57:45 发布

黄土地的孩子

最新推荐文章于 2024-05-15 09:57:45 发布

阅读量735

点赞数

分类专栏：微服务文章标签：微服务

本文链接：https://blog.csdn.net/u011528738/article/details/127743243

版权

2 篇文章 0 订阅

订阅专栏

Seata中的三大产品模块分别是TM-事务管理器、RM-资源管理器和TC-事务协调者。其中TM和RM是作为Seata的客户端与业务系统集成在一起，TC作为Seata的服务端独立部署。

Seata中分布式事务的执行流程图

AT模式是一种无侵入的的分布式事务解决方案。在AT模式下，用户只需关注自己的“业务SQL”，用户的业务SQL作为一阶段，Seata会自定生成事务的二阶段提交和回滚操作。
AT模式流程图
2. AT模式原理

一阶段
在一阶段，Seata会拦截“业务SQL”。首先解析SQL语义，找到“业务SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务SQL”更新业务数据。在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的完整性。
二阶段

提交

二阶段如果是提交的话，因为“业务SQL”在一阶段已经提交至数据库，所以Seata框架只需要将一阶段保存的快照数据和行锁删掉，完成数据清理即可；
回滚

二阶段如果是回滚的话，Seata就需要回滚一阶段已经执行的“业务SQL”，还原业务数据。回滚的方式便是用“before image”还原业务数据。但在还原前首先要校验脏写，对比数据库“当前业务数据”和“after image“。如果两份数据完全一致就没有脏写，可以还原业务数据；如果不一致就说明有脏写，出现脏写就需要转人工处理。

AT模式的一阶段、二阶段提交和回滚均由Seata框架自动生成，用户只需编写“业务SQL”，便能轻松接入分布式事务。AT模式是一种对业务无任何侵入的分布式事务解决方案。

TCC模式需要用户根据自己的业务场景实现Try、Confirm和Cancel三个操作。事务发起方在一阶段执行Try方式，在二阶段提交执行Confirm方法，二阶段回滚执行Cancel方法。
在这里插入图片描述
2. TCC三个方法描述：

用户接入TCC模式，最重要的是考虑如何将业务模型拆成2个阶段，实现TCC的三个方法，并保证try成功的confirm一定能成功。相对于AT模式，TCC模式对业务代码有一定的侵入性，但是TCC模式没有AT模式全局行锁，因此TCC模式性能要比AT模式高很多。

saga模式简介
Saga 模式是 Seata 开源的⻓事务解决⽅案，将由蚂蚁⾦服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每⼀个参与者都是⼀个冲正补偿服务，需要⽤户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执⾏过程中，依次执⾏各参与者的正向操作，如果所有正向操作均执⾏成功，那么分布式事务提交。如果任何⼀个正向操作执⾏失败，那么分布式事务会去退回去执⾏前⾯各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
适⽤场景：

总结：

AT 模式是⽆侵⼊的分布式事务解决⽅案，适⽤于不希望对业务进⾏改造的场景，⼏乎0学习成本。
TCC 模式是⾼性能分布式事务解决⽅案，适⽤于核⼼系统等对性能有很⾼要求的场景。
Saga 模式是⻓事务解决⽅案，适⽤于业务流程⻓且需要保证事务最终⼀致性的业务系统。
Saga 模式⼀阶段就会提交本地事务，⽆锁，⻓流程情况下可以保证性能，多⽤于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，⽆法进⾏改造和提供 TCC 要求的接⼝，也可以使⽤Saga 模式。

关注