文章目录
- 在你的项目中哪些模块使用了分布式事务控制 ? 能否举例说明 ?
- 说一说Seat AT模式的工作原理?
- 说一说Seat XA模式的工作原理?
- 说一说Seat TCC模式的工作原理?
- 什么是TCC模式的 业务悬挂 和 空回滚 ? 如何解决业务悬挂 和 空回滚 ?
更多相关内容可查看
在你的项目中哪些模块使用了分布式事务控制 ? 能否举例说明 ?
我最近做的项目中很多地方都使用到了分布式事物 , 例如 :
功能一 :
在用户实名认证审核功能中, 用户实名认证审核通过需要做二个操作
- 调用自媒体微服务创建自媒体帐号
- 修改用户微服务实名认证审核的数据状态
这个业务中涉及到了多个服务的调用, 为了 保证数据的一致性 , 使用了分布式事物控制
功能二 :
在文章审核发布的案例中, 文章审核通过后 , 会调用文章微服务发布文章 , 同时调用自媒体微服务修改文章的发布状态 , 也涉及到了多个服务之间的调用 , 所以需要使用分布式事务
功能三 :
在自媒体用户发布文章的功能中, 文章发布成功之后需要调用阿里云进行审核, 阿里云审核通过之后需要修改自媒体服务的文章状态 , 同时需要发布延迟任务 ,为了保证服务数据的一致性 , 这里也使用了分布式事务
说一说Seat AT模式的工作原理?
AT模式是Seata的默认模式 , 是一种无侵入式的事物解决方案
Seata事务管理中有三个重要的角色:
- TC (Transaction Coordinator) -事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚
- TM (Transaction Manager) -事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务
- RM (Resource Manager) -资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚
第一阶段 :
- TM感知到需要进行分布式事务控制的方法开始执行, 需要向TC发送指令开启全局事务
- TC会开启一个全局事务, 分配一个全局事务ID (XID)
- 之后TM会调用各个分支事务RM , RM收到指令后会向TC注册各自的分支事务 , 注册到同一个全局事务中 , 跟XID进行关联
- RM注册分支事务完毕后首先会记录业务SQL执行之前的数据快照 , 然后执行业务SQL , 再记录业务SQL执行之后的数据快照, 将 数据快照保存到一个undolog表中 , 业务SQL和undolog表的操作在同一个本地事务中 , 要保证同时成功或者同时失败 , 之后直接提交分支事物
- RM执行完毕后向TC汇报各自的执行状态
第二阶段 :
- TM感知到所有的分支事务执行完毕 , 通知TC进行期全局事务决议 , TC收到指令后 , 检查各个分支事务的状态
- 如果所有的分支事务全部执行成功 , 通知各个RM提交事务 , 如果有任何一个分支事物执行失败 , 通知各个RM回滚事务
- RM收到提交/回滚的请求后 , 利用undolog实现数据的提交/回滚
- 提交操作 : 删除undolog日志
- 回滚操作 : 根据全局事务ID以及分支事务ID查询 , 前后镜像数据, 生成反向补偿SQL语句 , 将前镜像数据更新回数据库即可
因为他在第一阶段业务SQL执行完毕之后直接提交, 最后通过反向补偿机制实现事务回滚, 所以AT模式是一种最终一致性的分布式事务解决方案
脏写问题 : 在AT模式中 , 因为分二阶段 ,第一阶段直接提交事物, 如果出现事务并发, 可能会出现脏写问题 , seata是通过全局锁的形式解决数据脏写问题的 ! seata的全局锁就是一张数据库表global_lock表 , 当某一个分布式事物获取了全局锁 , 会在表中记录, 其他事物再次获取锁就会失败
说一说Seat XA模式的工作原理?
Seata事务管理中有三个重要的角色:
- TC (Transaction Coordinator) -事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚。
- TM (Transaction Manager) -事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
- RM (Resource Manager) -资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
XA模式流程 :
第一阶段 :
- TM感知到需要进行分布式事务控制的方法开始执行, 需要向TC发送指令开启全局事务
- TC会开启一个全局事务, 分配一个全局事务ID (XID)
- 之后TM会调用各个分支事务RM , RM收到指令后会向TC注册各自的分支事务 , 注册到同一个全局事务中 , 跟XID进行关联
- RM注册分支事务完毕后开启执行业务SQL , 业务SQL执行完毕之后不提交
- RM执行完毕后向TC汇报各自的执行状态
第二阶段 :
- TM感知到所有的分支事务执行完毕 , 通知TC进行期全局事务决议 , TC收到指令后 , 检查各个分支事务的状态
- 如果所有的分支事务全部执行成功 , 通知各个RM提交事务 , 如果有任何一个分支事物执行失败 , 通知各个RM回滚事务
- RM收到提交/回滚的请求后 , 执行数据库本身的提交和回滚指令 , 完成事务的提交和回滚
因为他在第一阶段业务SQL执行完毕之后, 不提交等待, 等到最后一起提交和回滚, 所以XA模式是一种强一致性的分布式事务解决方案
说一说Seat TCC模式的工作原理?
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过我们自己编码来实现数据恢复。需要实现三个方法:
- Try:资源的检测和预留;
- Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功
- Cancel:预留资源释放,可以理解为try的反向操作
第一阶段 :
- TM感知到需要进行分布式事务控制的方法开始执行, 需要向TC发送指令开启全局事务
- TC会开启一个全局事务, 分配一个全局事务ID (XID)
- 之后TM会调用各个分支事务RM , RM收到指令后会向TC注册各自的分支事务 , 注册到同一个全局事务中 , 跟XID进行关联
- RM注册分支事务完毕后开始执行Try接口完成资源预留
- RM执行完毕后向TC汇报各自的执行状态
第二阶段 :
- TM感知到所有的分支事务执行完毕 , 通知TC进行期全局事务决议 , TC收到指令后 , 检查各个分支事务的状态
- 如果所有的分支事务全部执行成功 , 通知各个RM提交事务 , 如果有任何一个分支事物执行失败 , 通知各个RM回滚事务
- RM收到提交/回滚的请求后 , 利用confirm和cancel实现数据的确认和回滚
- 提交操作 : 执行confirm方法完成数据确认提交
- 回滚操作 : 执行cancel方法完成数据恢复
因为他在第一阶段业务SQL执行完毕之后直接提交, 没有使用全局锁 , 也不需要生成数据快照 , 所以性能比较好 , 而且不需要依赖数据库事务所以可以用于非关系型数据库 , 但是需要手动编写 try .confirm和cancel方法 , 实现比较复杂
什么是TCC模式的 业务悬挂 和 空回滚 ? 如何解决业务悬挂 和 空回滚 ?
空回滚 : 当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚,就是空回滚。
解决方案就是 : 执行cancel操作时,应当判断try是否已经执行,如果尚未执行,则应该空回滚。空回滚的解决方案就是保存一条空的回滚记录
业务悬挂 : 对于已经空回滚的业务,之前被阻塞的try操作恢复,继续执行try,就永远不可能confirm或cancel ,事务一直处于中间状态,这就是业务悬挂。
业务悬挂应该避免 , 执行try操作时,应当判断cancel是否已经执行过了,如果已经执行,应当阻止空回滚后的try操作,避免悬挂