Seata快速入门小知识

一家之言,简单理解

角色

TC

• Transaction Coordinator
• 事务协调者
• 维护全局事务和分支事务的状态,驱动全局事务和分支事务的提交和回滚. 请注意!TC只驱动操作,并不实际操作

TM

• Transaction Manager
• 事务管理者
• 定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM

• Resource Manager
• 资源管理器
• 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

全局事务和分支事务的关系

全局事务

一个业务操作可能会产生多个事务,对多个事务的调用分配,所产生的事务操作称之为全局事务,全局事务的实际操控是由TM控制

分支事务

在全局事务中必须要保证正确的操作事务单元,称之为分支事务,分支事务的实际控制是由RM控制

TM和RM与TC的连接关系

• RM和TM都分别会同步自己的状态,通知给TC.
• TC根据同步的状态,发出下一步的指令给到TM和RM
• 也就是说我们可以自己实现RM和TM只要完成了对资源的代理管控,和对操作动作的响应,此处的源代码比较简单,可以查看一下

事务模式

AT

• AT模式下,实现了全局锁
• 全局锁是针对于主键和间隙的锁
• 在Rm端实现了对于数据库连接的代理,在执行SQL前,对SQL的操作进行分析
• 判断自己的操作是否被全局锁占据
• 如果被全局锁锁住,则会进入等待,即自旋,默认时间10ms
• 在全局锁释放后,获取到锁,执行自身操作

AT模式的回滚

• AT模式下的回滚是通过Seata的RM端代理的数据库链接,在执行SQL时生成的UnDoLog进行自动回滚
  *.这种回滚和前面的提交本身不是同一个"数据库事务"
• 但即便此此时,全局事务的锁并没有释放,其他的全局事务依旧不会更新数据

以上便是AT模式下达成的写隔离手段

不难发现AT存在的一些问题

1.所有的敏感资源更新插入操作都必须被全局事务包裹,以便进行全局锁竞争
2.在提交操作和回滚操作间的数据,是已经落库的,所以是对其余事务可见的
那么这么显而易见的读隔离问题Seata是怎么解决的?

AT模式的读隔离

其实很简单,只要在进行读操作的时候也竞争一下全局锁就可以了
但是所有的读操作都进行全局锁的竞争,性能自然就会变差.
所以Seata本身开放了这个操作的能力给开发者,如何在执行操作的时候,参与全局锁的竞争

• 1.在执行方法上添加@GlobalLock,执行的方法在运行前,就会检查是否被全局锁锁住.
• 2.使用for update.

For update本身是mysql的操作的语法,其作用是行锁,锁住需要操作的行.
RM的数据库链接代理在检测到for update关键字的时候就会检测全局锁的状态.

AT模式的优缺点

优点:

• 代码侵入少
• 功能完整
• 实现了读写隔离
• 并没有阻塞服务的事务提交,提高了性能

缺点:

• 所有的敏感操作必须被全局事务管理,否则就会产生脏数据的风险(自动回滚不成功,事务失效,后续事务无法获取到全局锁)

TCC模式

• 使用注解@LocalTCC声明类或接口使用的是TCC模式
• 使用注解@TwoPhaseBusinessAction(name = “”, commitMethod = “”, rollbackMethod = “”)注释TCC三个方法的名称
• TCC方法的参数接受->
  @BusinessActionContextParameter(paramName = “”)注释参数 (obj/Map)
• 参数使用BusinessActionContext

*AT模式和TCC模式是可以混用的

TCC模式的优劣

优

• 逻辑上完备
• 速度相对快

劣

• 代码和业务上侵入比较高