Seata能控制的事务隔离级别能到哪一级别?

LinkedBear 发布于 2019/10/09 08:53
阅读 412
收藏 0

在两个由Seata控制的全局事务中,Seata可以通过锁机制来解决两个全局事务的事务隔离。

但假设有如下情景:

服务1和服务2连接到事务协调器,组成分布式服务,服务3不参与分布式事务。服务2和服务3都连接到同一个数据库。

以跨行转账的场景为例:

1. 服务1与服务2构成跨行转账的业务场景,服务3为ATM。按照Seata的AT模式控制分布式事务,当服务1发起跨行转账的动作时,服务1从数据库中扣减金额,并完成一阶段事务提交和undo_log的写入。

2. 服务2收到服务1发送的远程请求,并向数据库写入增加金额的动作和undo_log并提交本地分支事务,但分支事务提交完毕后,通知事务协调器时由于网络出现波动,没有及时通知成功。

3. 在网络波动的这期间,ATM服务(另一个jvm进程)发起一个取款动作,此时数据库中金额被扣减,取款成功,事务提交。

4. 网络恢复,事务协调器收到分支事务提交成功的消息,继续通知服务1进行后续业务逻辑,恰好服务1中出现了业务错误,抛出异常,全局事务需要回滚。服务1的本地事务可以正常回滚,但服务2的分支事务在回滚时,由于Seata的回滚规则中发现undo_log中前后两个余额值均与当前余额不同,会认为出现错误,抛出异常。

从ATM服务的角度来讲,ATM在他的本地事务中读到了跨行转账的全局事务中未真正提交的数据,应该判定为出现脏读。Seata是否有方案解决该问题(多进程之间的事务)?

加载中
1
s
slievrly

我来回答一下这个问题,这个问题和网络抖动恢复之类都没有关系。这个问题是服务3没有纳入到全局事务中,如果服务3纳入到全局事务中有全局锁的判断这时发生不了ATM服务的取款动作。这里等于ATM服务的数据直接走到了数据库没有经过seata中间件。存在于seata之外的数据修改seata无法进行控制,对于这种数据校验失败的回滚也不能进行覆盖性的回滚,这个决策只能交给用户。所以对于seata AT模式的一个原则是数据修改的入口都要交给seata事务控制。

0
大王来巡山
大王来巡山

现阶段还不能跨语言

返回顶部
顶部