SpringCloud Alibaba Seata处理分布式事务-微服务(四十)

Test

下订单->减库存->扣余额->改(订单)状态

数据库初始情况

SELECT *  FROM  `seata_order`.`t_order`

SELECT * FROM `seata_storage`.`t_storage`

SELECT *  FROM  `seata_account`.`t_account`;

正常下单

http://localhost:2001/order/create?userId=1&productId=1&count=10&money=100

数据库情况

超时异常，没加@GlobalTransactional

AccountServiceImpl添加超时

数据库情况

故障情况

• 当库存和账户金额扣减后，订单状态并没有设置为已经完成，没有从零改为1。
• 而且由于feign的重试机制，账户余额还有可能被多次扣减

超时异常，添加@GlobalTransactional

AccountServiceImpl添加超时

OrderServiceImpl@GlobalTransactional

 
@GlobalTransactional(name = "fsp-create-order",rollbackFor = Exception.class)
public void create(Order order)
{
。。。。。。
}

下单后数据库数据并没有任何改变

• 记录都添加不进来

一部分补充

Seata

2019年1月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。
Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架。

2020起始，参加工作后用1.0以后的版本

再看TC/TM/RM三大组件

分布式事务的执行流程

• TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
• 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
• TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
• TC 汇总事务信息，决定分布式事务是提交还是回滚；
• TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。​

AT模式如何做到对业务的无侵入

是什么

一阶段加载

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

二阶段提交

二阶段如是顺利提交的话，
因为“业务 SQL”在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚

二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。
回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，
如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

BUG

补充