seata笔记

分布式事务产生背景

数据库拆分

  • 单库单表支撑不了业务时需要对数据库进行水平拆分。分库分表后,原来在一个数据库上就能完成的写操作,可能会跨多个数据库,就产生了跨数据库事务问题

业务服务化拆分

  • 业务拆分后,一个完整的业务逻辑可能会涉及多个服务,多个服务之间存在跨服务事务问题

分布式事务理论基础

两阶段提交协议(对应阿里的AT模式)

事务管理器分为两个阶段来协调资源管理器,第一阶段准备资源,也就是预留事务所需资源,如果资源管理器资源预留成功,则进行第二阶段资源提交,否则协调资源管理器回滚资源

例如:扣款流程,第一步先冻结资金,冻结成功后进行第二步扣款,扣除成功则把事务提交。若第二步扣款失败则将第一步回滚,恢复冻结资金

TCC (Try-Confirm-Cancel)

实际上是对服务化的两个阶段提交协议,业务开发者需要实现这三个服务接口,第一阶段服务自由业务代码编排来调用Try接口进行资源预留,所有参与者的Try接口都成功了,事务管理器会提交事务,并调用每个参与者的Confirm接口真正提交业务操作,否则调用每个参与者的Cancel接口回滚事务

Saga

  • saga是一种补偿协议,在Saga模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作

  • 分布式事务执行过程中,依次执行各参与者的正向操作,如果所有正向操作均执行成功,那么分布式事务提交。如果任何一个正向操作执行失败,那么分布式事务会退回去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态

  • Saga正向服务与补偿服务也需要业务开发者实现

其实TCC、Saga都是两阶段提交的补充

Seata概述

  • Simple Extensible Autonomous Transaction Architecture 简单可扩展自治事务框架。2019年1月开源

2019年1月开源

  • 三大模块,TM、RM、TC。其中TM和RM是作为Seata的客户端与业务系统集成在一起,TC作为Seata的服务端独立部署

  • 有四种分布式解决方案,AT模式、TCC模式、Saga模式和XA模式

Seata模块

image-20200712173947722

三大模块

  • TC(Transaction Coordinator):事务协调器

    维护全局和分支事务的状态,用于全局性事务的提交和回滚

  • TM(Transaction Manager): 事务管理器

    定义全局事务域:开启全局事务、提交或者回滚全局事务。向事务指定标识,监视它们的进场,并负责处理事务的完成和失败。事务分支标识(称为XID)由TM指定,以标识一个RM内的全局事务和特定分支

  • RM(Resource Manager):资源管理器

    管理分支事务所使用的资源,向TC注册分支事务并报告分支事务状态,接受TC的命令来提交或者回滚分支事务

Seata管理分布式事务典型的生命周期

  • TM向TC请求开始全局事务,TC生成一个代表全局性事务的XID

  • XID通过微服务的调用链传播

  • RM向TC注册本地事务,作为XID对应的全局事务的分支

  • TM要求TC提交或者回滚XID相应的全局事务

  • TC驱动XID相应的全局事务下的分支事务完成分支的提交或者回滚

AT模式

AT模式是一种无入侵的分布式事务解决方案。在AT模式下,用户只需关注自己的业务SQL,用户的业务SQL作为一阶段,seata框架会自动生成事务的二阶段提交和回滚操作

AT模式-第一阶段

image-20200712190551518

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

AT模式-第二阶段

image-20200712191048031

二阶段如果是提交的话,因为业务sql在一阶段已经提交至数据库,所以seata框架只需将一阶段保存的快照数据和行锁删除,完成数据清理即可

TCC模式基本原理

分为Try-Confirm-Cancel 3个操作。其和两阶段提交有点类似,Try为第一阶段,Confirm-Cancel为第二阶段,是一种应用层面侵入业务的两阶段提交

操作方法 含义
Try 预留业务资源/数据校验
Confirm 确认执行业务操作,实际提交数据,不做任何业务检查,try成功,confirm必定成功,需要保证幂等
Cancel 取消执行业务操作,实际回滚数据需保证幂等

其核心在于将业务分为两个操作步骤完成。不依赖RM对分布式事务的支持,而是通过对业务逻辑的分解来实现分布式事务。相对于AT模式,TCC模式对业务代码有一定的入侵性,但是TCC模式无AT模式的全局行锁,TCC性能会比AT模式高很多

TCC模式原理图

TCC幂等操作

image-20200712192403826

使用TCC时需要注意Try-Confirm-Cancel 3个操作的幂等控制,网络原因,或者重试操作都有可能导致这几个操作的重复执行

TCC空回滚

image-20200712192707516

事务协调器在调用TCC一阶段Try操作时,可能会出现因为丢包而导致网络超时,此时事务协调器会触发二阶段回滚,TCC在未收到Try请求的情况下收到Cancel请求,这种场景被称为空回滚。

解决思路:

回滚请求处理时,如果对应的具体业务数据为空,则返回成功,让事务服务管理器认为已回滚,否则会不断重试,而Cancel又没有对应的业务数据可以进行回滚

TCC防悬挂

image-20200712193205428

事务协调器在调用TCC服务的一阶段Try操作时,可能会出现因网络拥堵而导致的超时,此时事务协调器会触发二阶段回滚,调用TCC服务的Cancel操作;在此之后,拥堵在网络上的一阶段Try数据包被TCC服务收到,出现二阶段Cancel请求比一阶段Try请求先执行的情况;

解决思路:

在二阶段执行时插入一条事务控制记录,状态为已回滚,这样当一阶段执行时,先读取记录,如果记录存在,就认为二阶段回滚操作已经执行,不再执行Try方法

Saga模式

长事务解决方案。

image-20200713174827037

Saga模式使用场景

  • 适用于业务流程长且徐亚保证事务最终一致性的业务系统

  • 无法进行改造和提供TCC要求的接口,可以使用Saga模式

Saga模式优势

  • 无锁,高性能

  • 异步执行,高吞吐

  • 补充服务容易理解,容易实现

TM事务管理器

开启、提交、回滚分布式事务

RM 资源管理器

注册、汇报、执行资源

TC 事务管理器服务功能

存储事务管理日志,补偿异常事务

posted @ 2021-05-12 19:12  link_ed  阅读(115)  评论(0编辑  收藏  举报