Seata:分布式解决方案
Spring声明式事务 @Transactional 注解解读
@Transactional注解解读
-
@Transactional 是 Spring 事务管理提供的注解，在一个方法上加上了这个注解，那么这个方法就是有事务的，事务内的操作要么一起提交、要么一起回滚
@Transactional注解事务的传播行为
-
它是用来表示当一个事务传播行为修饰的方法被另一个方法调用时，事务该如何进行传播
-
-
-
-
-
-
Spring事务@Transactional注解的应用
@Transactional注解最常见的应用
- 可以标注在类、方法和接口（不要使用）上；且方法上的注解会覆盖类上的注解
- 标记在方法上，标识事务开启，正常则提交事务，异常则回滚事务
- 自定指定rollbackFor 属性。让Checked Exception也能实现回滚
- 让TestCase也能实现回滚
分布式事务理论和解决方案
什么是分布式事务
-
分布式事务是来源于微服务的(或者是类似的场景)，服务之间存在者调用，且整个调用链路上存在着多出（分布在不同的微服务上的）写数据库的行为。那么分布式事务就要保证这些操作要么全部成功，要么全部失败。
分布式事务可能追求的一致性条件不同
- 强一致性：任何一次读都能读到某个数据的最近一次写的数据（要求最高）
- 弱一致性：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性（绝大多数的业务场景不允许）
- 最终一致性：不保证在任意时刻数据都是完整的（状态一致），但是，随着时间的推移（会有一个度量），数据总是会达到一致的状态。
最常用的分布式事务的解决方案：两阶段提交
-
两阶段指的是分两步提交；存在一个中央协调器负责协调各个分支事务
最常用的分布式事务的解决方案：两阶段提交
-
该方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行
分布式事务解决方案 Seata AT 模式
Seata的过程模型
- Seata 中的三个重要角色：TC、TM、RM
- TM：事务的发起者，用于通知TC，全局事务的开始、提交、回滚
- RM：事务资源，每一个RM都会作为一个分支事务注册在TC上
- TC：事务协调者，也就是中央协调器；用于接收事务的注册、提交、回滚
Seata的事务模式
- Seata定义了全局事务的框架；全局事务定义为若干分支事务的整体协调
- TM 向 TC请求发起、提交、回滚全局事务
- TM把代表全局事务的XID绑定到分支事务上
- RM向TC注册，把分支事务关联到XID上
- RM把分支事务的执行结果上报给TC
- TC发送分支提交或分支回滚命令给RM
AT 模式的整体机制
- AT 对业务代码完全无侵入性，使用非常简单，改造成本低；我们只需要关注自己的业务SQL。Seata会通过分析我们业务SQL，反向生成回滚数据
- 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源
- 提交异步化，非常快速的完成；回滚通过一阶段的回滚日志进行反向补偿
AT模式工作示例
- 两个全局事务tx1和tx2，分别对a表的m字段进行更新操作，m的初始值1000
- 一阶段本地事务提交前，需要确保先拿到全局锁
- 拿不到全局锁，不能提交事务
- 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁
-
如果tx1的二阶段全局回滚，则tx1需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚
Seata Server单机和高可用模式搭建
可以参考
Seata AT模式的应用
使用Seata（AT模式）的步骤
pom.xml文件中引入依赖- 创建
undo_log表（如果业务使用了多个数据库。每一个数据库都要有这张表） - 配置事务分组
- 配置Seata数据源代理
- 加载拦截器
SeataHandlerInterceptor，实现微服务之间xid的传递 - 将
@GlobalTransactional注解标注在需要分布式事务的方法上
Seata AT模式的工作机制
-
业务表
product
-
AT分支事务的业务逻辑
update product set name = 'GTS' where name = 'TXC';
一阶段过程
二阶段提交
二阶段回滚
Seata AT模式的实现原理
Seata AT模式的工作流程
-
AT 模式的工作流程分为两个阶段：一阶段执行业务SQL，二阶段提交或回滚
-
一阶段分支事务的实现原理
-
二阶段Commit流程的实现原理（服务端）
-
二阶段Commit流程的实现原理（客户端）
-
二阶段Rollback流程的实现原理
评论区