一、什么是Steata
Steata是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务,Steata将为用户提供了AT、TCC、SAGA和XA事务模式,为用户打造一站式的分布式解决方案,AT模式是阿里首推的模式,阿里云上用商用版的GTS
二、Setata的三大角色
在Seate的架构中,一共有三个角色:
TC:事务协调者
维护全局和分支事务的状态,驱动全局事务提交或回滚。
TM:事务管理器
定义全局事务的范围:开启全局事务、提交或回滚全局事务
RM:资源管理器
管理分支事务处理的资源,与TC交谈以注册分支事务事务和报告分支事务的状态,并驱动分支事务提交或回滚。
其中,TC为单独部署的Seata服务端,TM和RM为嵌入到应用中的Client客户端
三、常见的分布式事务解决方案
1、seata阿里云分布式事务框架
2、消息队列
3.saga
4.XA
他们有一个共同点,都是“两阶段(2PC)"。“两阶段”是指完成整个分布式事务,划分成两个步骤完成。实际上,这四种常见的分布式事务解决方案,分别对应着分布式事务的四种模式: AT、TCC、Saga、XA;四种分布式事务模式,都有各自的理论基础,分别在不同的时间被提出;每种模式都有它的适用场景,同样每个模式也都诞生有各自的代表产品;而这些代表今天,我们会分别来看4种模式(AT、TCC、 Saga、 XA)的分布式事务实现。产品,可能就是我们常见的(全局事务、基于可靠消息、最大努力通知、TCC)。在看具体实现之前,先讲下分布式事务的理论基础。
四、2PC两阶段提交协议
2PC(两阶段提交,Two-Phase Commit)
简单的来说,分为两个阶段:Prepare和commit
Prepare:提交事务请求
2PC的问题
1.同步阻塞参与者在等待协调者的指令时,其实是在等待其他参与者的响应,在此过程中,参与者是无法进行其他操作的,也就是阻塞了其运行。倘若参与者与协调者之间网1络异常导致参与者一直收不到协调者信息,那么会导致参与者一直阻塞下去。
2.单点在2PC中,一切请求都来自协调者,所以协调者的地位是至关重要的,如果协调者宕机,那么就会使参与者一直阻塞并一直占用事务资源。
如果协调者也是分布式,使用选主方式提供服务,那么在一个协调者挂掉后,可以选取另一个协调者继续后续的服务,可以解决单点问题。但是,新协调者无法知道上一个事务的全部状态信息(例如已等待 Prepare 响应的时长等),所以也无法顺利处理上一个事务。
3,数据不一致Commit事务过程中Commit请求/Rollback请求可能因为协调者宕机或协调者与参与者网络问题丢失,那么就导致了部分参与者没有收到Commit/Rollback请求,而其他参与者则正常收到执行了Commit/Rollback操作,没有收到请求的参与者则继续阻塞。这时,参与者之间的数据就不再一致了。当参与者执行Commit/Rollback后会向协调者发送Ack,然而协调者不论是否收到所有的参与者的Ack,该事务也不会再有其他补救措施了,协调者能做的也就是等待超时后像事务发起者返回一个“我不确定该事务是否成功”。
五、AT模式(auto transcation(自动提交事务))
AT模式是一种无侵入的分布式事务解决方案。在AT模式下,用户只需关注自己的”业务SQL“,用户的”业务SQL“作为一阶段,Seata框架会自动生成事务的二阶段提交和回滚操作。
第一阶段:在第一阶段,Seata会拦截“业务SQL”,首先解析SQL语义,找到“业务SQL”要更新的业务数据,在业务数据要被更新前,将其保存成“before image” ,然后执行“业务SQL“更新业务数据,在业务数据更新之后,,将其保存成”after image“,最后生成行锁,以上操作全部在一个数据库事务内完成,这样保证了一阶段操作的原子性。
第二阶段:
二阶段如果是提交的话,因为“业务SQL”在第一阶段已经提交到数据库,所以Seata框架只需将一阶段保存的快照数据和行锁删除掉,完成数据清理即可
二级段的回滚:
二阶段如果是回滚的话,Seata就需要回滚一阶段已经执行的的“业务SQL”,还原业务数据,回滚方式,便是用“before image”,还原业务数据,但在还原前要首先要校验脏写,对比数据库当前业务数据和“after image”,如果两份数据完全一致就说明没有脏写,可以还原数据,如果不一致,说明有脏写,出现脏写就需要转人工处理。
六、TCC模式
TCC模式需要用户根据自己的业务场景实现Try、Confirm和Cancel,三个操作,事务发起放在一阶段执行Try方式,在二阶段提交执行Confirm方法,二阶段回滚执行Cancel方法。
缺点:侵入性比较强,并且得自己实现相关事务控制逻辑
优点:在整个过程基本没有锁,性能更强
七、Seata Server(TC) 环境搭建
Server端存储模式(store.mode)支持三种:
1.file:单击模式,全局事务会话信息内存中读写并持久化本地文件root.data,性能较高(默认)
2.db:高可用模式,全局事务会话信息通过db共享,相应性能差些,
3.redis:Seata-Server1.3及以上版本支持,性能较高,存在事务信息丢失情况,请提前配置适合当前场景的Redis持久化配置