AT、TCC、SAGA

在继续学习使用SEATA之前#xff0c;对s…一、SEATA是什么

Seata

是一款开源的分布式事务解决方案致力于提供高性能和简单易用的分布式事务服务。

Seata

AT、TCC、SAGA

在继续学习使用SEATA之前对seata介绍中提到的分布式事务、AT、TCC、SAGA

首先说下事务事务是应用程序中一系列严密的操作所有操作必须成功完成否则在每个操作中所作的所有更改都会被撤消。

事务应该具有

事务更多指的是单机版、单数据库的概念。

分布式事务用于在分布式系统中保证不同节点之间的数据一致性。

漫画:

有了分布式事务的场景就会有解决该问题的方式规范XA规范就是解决分布式事务的规范。

分布式事务的实现方式有很多种最具有代表性的是由Oracle

XA分布式事务协议。

XA协议包括两阶段提交2PC和三阶段提交3PC两种实现。

两阶段提交2PC

protocol,2pc是一个非常经典的强一致、中心化的原子提交协议。

这里所说的中心化是指协议中有两类节点一个是中心化协调者节点coordinator和N个参与者节点partcipant。

准备阶段

事务协调者向所有事务参与者发送事务内容询问是否可以提交事务并等待参与者回复。

事务参与者收到事务内容开始执行事务操作讲

如果参与者执行成功给协调者回复yes,表示可以进行事务提交。

如果执行失败给协调者回复no,表示不可提交。

XA一阶段提交

如果协调者收到了参与者的失败信息或超时信息直接给所有参与者发送回滚rollback信息进行事务回滚否则发送提交commit信息。

参与者根据协调者的指令执行提交或者回滚操作释放所有事务处理过程中使用的锁资源。

(注意必须在最后阶段释放锁资源)

[图片上传失败…(image-a6b970-1618380177779)]

xa规范2pc异常提交阶段

从流程上我们可以看得出其最大缺点就在于它的执行过程中间节点都处于阻塞状态。

各个操作数据库的节点此时都占用着数据库资源只有当所有节点准备完毕事务协调者才会通知进行全局提交参与者进行本地事务提交后才会释放资源。

这样的过程会比较漫长对性能影响比较大。

协调者单点故障问题

事务协调者是整个XA模型的核心一旦事务协调者节点挂掉会导致参与者收不到提交或回滚的通知从而导致参与者节点始终处于事务无法完成的中间状态。

在第二个阶段如果发生局部网络问题一部分事务参与者收到了提交消息另一部分事务参与者没收到提交消息那么就会导致节点间数据的不一致问题。

2PC

方案实现起来简单基于上面提到的两阶段提交协议中会遇到的问题实际项目中使用的比较少。

那么有没有其他的方案来解决呢

三阶段提交3PC

三阶段提交是在二阶段提交上的改进版本其在两阶段提交的基础上增加了

CanCommit阶段并加入了超时机制。

同时在协调者和参与者中都引入超时机制。

三阶段将二阶段的准备阶段拆分为2个阶段插入了一个preCommit阶段以此来处理原先二阶段参与者准备后参与者发生崩溃或错误导致参与者无法知晓是否提交或回滚的不确定状态所引起的延时问题。

1canCommit

阶段一中如果所有的参与者都返回Yes的话那么就会进入PreCommit阶段进行事务预提交。

此时分布式事务协调者会向所有的参与者节点发送PreCommit请求参与者收到后开始执行事务操作并将Undo和Redo信息记录到事务日志中。

参与者执行完事务操作后此时属于未提交事务的状态就会向协调者反馈“Ack”表示我已经准备好提交了并等待协调者的下一步指令。

如果阶段一中有任何一个参与者节点返回的结果是No响应或者协调者在等待参与者节点反馈的过程中因挂掉而超时2PC中只有协调者可以超时参与者没有超时机制。

整个分布式事务就会中断协调者就会向所有的参与者发送“abort”请求。

xa规范3pc-preCommit

该阶段进行真正的事务提交在阶段二中如果所有的参与者节点都可以进行PreCommit提交那么协调者就会从“预提交状态”

转变为

“提交状态”。

然后向所有的参与者节点发送doCommit请求参与者节点在收到提交请求后就会各自执行事务提交操作并向协调者节点反馈“Ack”消息协调者收到所有参与者的Ack消息后完成事务。

xa规范3pc-doCommit

相比较2PC而言3PC对于协调者Coordinator和参与者Partcipant都设置了超时时间而2PC只有协调者才拥有超时机制。

这解决了一个什么问题呢这个优化点主要是避免了参与者在长时间无法与协调者节点通讯协调者挂掉了的情况下无法释放资源的问题因为参与者自身拥有超时机制会在超时后自动进行本地commit从而进行释放资源。

而这种机制也侧面降低了整个事务的阻塞时间和范围。

另外通过CanCommit、PreCommit、DoCommit三个阶段的设计相较于2PC而言多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

以上就是3PC相对于2PC的一个提高相对缓解了2PC中的前两个问题但是3PC依然没有完全解决数据不一致的问题。

假如在

DoCommit

过程参与者A无法接收协调者的通信那么参与者A会自动提交但是提交失败了其他参与者成功了此时数据就会不一致。

AT(Auto

SQL”要更新的业务数据在业务数据被更新前将其保存成“before

image”然后执行“业务

SQL”更新业务数据在业务数据更新之后再将其保存成“after

image”最后生成行锁。

以上操作全部在一个数据库事务内完成这样保证了一阶段操作的原子性。

update

SQL”更新业务数据SQL。

根据前镜像数据主键查询出后镜像数据查询结果为

select

把业务数据在更新前后的数据镜像组织成回滚日志将业务数据的更新和回滚日志在同一个本地事务中提交分别插入到业务表和

UNDO_LOG

image”还原业务数据但在还原前要首先要校验脏写对比“数据库当前业务数据”和

“after

image”如果两份数据完全一致就说明没有脏写可以还原业务数据如果不一致就说明有脏写出现脏写就需要转人工处理。

Seata

模式是一种对业务无任何侵入的分布式事务解决方案。

但AT模式存在的不足就是

TCC方案其实是两阶段提交的一种改进。

分成了Try、Confirm、Cancel三个操作。

事务发起方在一阶段执行

Try

方法。

TwoPhaseBusinessAction是TCC服务参与者必须加的注解指定服务名称提交方法commitMethod及回滚方法rollbackMethodSecondAction同理

TCC

的分支事务纳入到全局事务的管理中。

简单点概括SEATA的TCC模式就是手工的AT模式它允许你自定义两阶段的处理逻辑而不依赖AT模式的undo_log。

LocalTCC

注解try方法其中name为当前tcc方法的bean名称写方法名便可记得全局唯一commitMethod指向提交方法rollbackMethod指向事务回滚方法。

指定好三个方法之后seata会根据全局事务的成功或失败去帮我们自动调用提交方法或者回滚方法。

注解可以将参数传递到二阶段commitMethod/rollbackMethod的方法。

业务模型分2阶段设计

Saga模式是SEATA提供的长事务解决方案在Saga模式中业务流程中每个参与者都提交本地事务当出现某一个参与者失败则补偿前面已经成功的参与者一阶段正向服务和二阶段补偿服务都由业务开发实现。

Saga模式示意图

如图T1-T3都是正向的业务流程都对应着一个冲正逆向操作C1-C3。

分布式事务执行过程中依次执行各参与者的正向操作如果所有正向操作均执行成功那么分布式事务提交。

如果任何一个正向操作执行失败那么分布式事务会退回去执行前面各参与者的逆向回滚操作回滚已提交的参与者使分布式事务回到初始状态。

Saga

模式下分布式事务通常是由事件驱动的各个参与者之间是异步执行的Saga

Saga

模式适用于业务流程长且需要保证事务最终一致性的业务系统Saga

事务参与者可能是其它公司的服务或者是遗留系统的服务无法进行改造和提供

TCC

模式由于一阶段已经提交本地数据库事务且没有进行“预留”动作所以不能保证隔离性。

后续会讲到对于缺乏隔离性的应对措施。

空补偿逆向操作早于正向操作时

四种分布式事务模式分别在不同的时间被提出每种模式都有它的适用场景

模式是无侵入的分布式事务解决方案适用于不希望对业务进行改造的场景几乎0学习成本。

TCC

模式是高性能分布式事务解决方案适用于核心系统等对性能有很高要求的场景。

Saga

模式是长事务解决方案适用于业务流程长且需要保证事务最终一致性的业务系统Saga

模式一阶段就会提交本地事务无锁长流程情况下可以保证性能多用于渠道层、集成层业务系统。

事务参与者可能是其它公司的服务或者是遗留系统的服务无法进行改造和提供

TCC

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