Seata分布式事务模型和基本应用

Seata事务模型

Seata是Alibaba提供的开源框架，提供了四种分布式事务的解决方案：

• AT：基于数据库层面的ACID事务，弱一致性事务模型；
• XA：基于数据库层面的，强一致性事务模型；
• TCC：基于代码逻辑实现的，弱一致性模型；
• SAGA：基于代码逻辑实现的，长事务解决方案，基于事件驱动，高性能、高吞吐；

AT模型

AT模型是2阶段段提交(2PC)协议的演变

第一阶段

写本地事务更新数据到本地数据库，申请全局事务id：

• 开启本地事务
• 执行update更新操作，执行sql语句更新数据到数据库
• 记录回滚日志UNDO_LOG:
  • 记录afterImage: 更新之后的数据快照
  • 记录beforeImage: 更新之前的数据快照
• 提交本地事务
• 将第一阶段执行结果提交给TC，交给第二阶段处理

第二阶段

根据第一阶段的执行结果决定是commit / rollback

如果是commit：donothing，因为第一阶段已经提交了

如果是rollback：从UNDO_LOG中找到修改之前的数据快照，进行回滚

如果rollback出错，TC会持久化回滚任务，不停重试直到回滚成功，所以这是基于应用层面逻辑实现UNDO_LOG回滚的弱一致性模型

事务隔离级别

写隔离(加全局锁)：避免两个事务对同一条数据进行更改

如下图所示，假如tx1和tx2两个线程同时对一条数据进行修改

1. 先获取数据库层面本地锁
2. 执行sql语句
3. 获取全局锁
4. 本地锁提交，完成数据更新
5. 释放本地锁
6. 一旦执行出错，需要回滚
7. 先获取本地锁
8. 执行语句回滚数据
9. 提交本地锁
10. 最后释放全局锁

读隔离：默认读未提交(未提交的数据可以读到)，可以开启读已提交功能

XA模型

强一致性模型，数据库层面的二阶段提交

TCC模型

弱一致性模型，和XA类似，都是二阶段提交，只是TCC是代码逻辑层面二阶段提交

三个核心方法

• Try：先将资源占用
• Confirm：如果Try成功，那么Confirm提交
• Cancel：如果Try失败，那么Cancel回滚

TCC常见问题

• TCC空回滚问题：try没有执行，执行了cancel；为了防止空回滚，执行cancel之前先看下try的状态。
• TCC幂等性问题：要保证try执行成功，那么confirm或者cancel也一定要执行成功。
• TCC空悬挂问题：cancel先执行，try后执行；为了防止空悬挂，执行try之前先看下cancel的状态。

Seata SAGA

基于事件驱动，性能更高

 Seata的集成方式

• seata-all
• seata-spring-boot-starter
• springcloud-starter-seata

seata-all

复制两个文件到项目resources目录下

file.conf, registry.conf

seata-spring-boot-starter

不需要加file.conf和registry.conf文件 

Seata配置中心

Seata注册中心