【2024最新精简版】分布式事物面试篇

更多相关内容可查看

在你的项目中哪些模块使用了分布式事务控制 ? 能否举例说明 ?

我最近做的项目中很多地方都使用到了分布式事物 , 例如 :
功能一 :
在用户实名认证审核功能中, 用户实名认证审核通过需要做二个操作

1. 调用自媒体微服务创建自媒体帐号
2. 修改用户微服务实名认证审核的数据状态

这个业务中涉及到了多个服务的调用, 为了 保证数据的一致性 , 使用了分布式事物控制
功能二 :
在文章审核发布的案例中, 文章审核通过后 , 会调用文章微服务发布文章 , 同时调用自媒体微服务修改文章的发布状态 , 也涉及到了多个服务之间的调用 , 所以需要使用分布式事务
功能三 :
在自媒体用户发布文章的功能中, 文章发布成功之后需要调用阿里云进行审核, 阿里云审核通过之后需要修改自媒体服务的文章状态 , 同时需要发布延迟任务 ,为了保证服务数据的一致性 , 这里也使用了分布式事务

说一说Seat AT模式的工作原理?

AT模式是Seata的默认模式 , 是一种无侵入式的事物解决方案
Seata事务管理中有三个重要的角色：

• TC (Transaction Coordinator) -事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚
• TM (Transaction Manager) -事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务
• RM (Resource Manager) -资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚

第一阶段 :

1. TM感知到需要进行分布式事务控制的方法开始执行, 需要向TC发送指令开启全局事务
2. TC会开启一个全局事务, 分配一个全局事务ID (XID)
3. 之后TM会调用各个分支事务RM , RM收到指令后会向TC注册各自的分支事务 , 注册到同一个全局事务中 , 跟XID进行关联
4. RM注册分支事务完毕后首先会记录业务SQL执行之前的数据快照 , 然后执行业务SQL , 再记录业务SQL执行之后的数据快照, 将 数据快照保存到一个undolog表中 , 业务SQL和undolog表的操作在同一个本地事务中 , 要保证同时成功或者同时失败 , 之后直接提交分支事物
5. RM执行完毕后向TC汇报各自的执行状态

第二阶段 :

1. TM感知到所有的分支事务执行完毕 , 通知TC进行期全局事务决议 , TC收到指令后 , 检查各个分支事务的状态
2. 如果所有的分支事务全部执行成功 , 通知各个RM提交事务 , 如果有任何一个分支事物执行失败 , 通知各个RM回滚事务
3. 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模式流程 :

第一阶段 :

1. TM感知到需要进行分布式事务控制的方法开始执行, 需要向TC发送指令开启全局事务
2. TC会开启一个全局事务, 分配一个全局事务ID (XID)
3. 之后TM会调用各个分支事务RM , RM收到指令后会向TC注册各自的分支事务 , 注册到同一个全局事务中 , 跟XID进行关联
4. RM注册分支事务完毕后开启执行业务SQL , 业务SQL执行完毕之后不提交
5. RM执行完毕后向TC汇报各自的执行状态

第二阶段 :

1. TM感知到所有的分支事务执行完毕 , 通知TC进行期全局事务决议 , TC收到指令后 , 检查各个分支事务的状态
2. 如果所有的分支事务全部执行成功 , 通知各个RM提交事务 , 如果有任何一个分支事物执行失败 , 通知各个RM回滚事务
3. RM收到提交/回滚的请求后 , 执行数据库本身的提交和回滚指令 , 完成事务的提交和回滚

因为他在第一阶段业务SQL执行完毕之后, 不提交等待, 等到最后一起提交和回滚, 所以XA模式是一种强一致性的分布式事务解决方案

说一说Seat TCC模式的工作原理?

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过我们自己编码来实现数据恢复。需要实现三个方法：

• Try：资源的检测和预留；
• Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功
• Cancel：预留资源释放，可以理解为try的反向操作

第一阶段 :

1. TM感知到需要进行分布式事务控制的方法开始执行, 需要向TC发送指令开启全局事务
2. TC会开启一个全局事务, 分配一个全局事务ID (XID)
3. 之后TM会调用各个分支事务RM , RM收到指令后会向TC注册各自的分支事务 , 注册到同一个全局事务中 , 跟XID进行关联
4. RM注册分支事务完毕后开始执行Try接口完成资源预留
5. RM执行完毕后向TC汇报各自的执行状态

第二阶段 :

1. TM感知到所有的分支事务执行完毕 , 通知TC进行期全局事务决议 , TC收到指令后 , 检查各个分支事务的状态
2. 如果所有的分支事务全部执行成功 , 通知各个RM提交事务 , 如果有任何一个分支事物执行失败 , 通知各个RM回滚事务
3. RM收到提交/回滚的请求后 , 利用confirm和cancel实现数据的确认和回滚
   • 提交操作 : 执行confirm方法完成数据确认提交
   • 回滚操作 : 执行cancel方法完成数据恢复

因为他在第一阶段业务SQL执行完毕之后直接提交, 没有使用全局锁 , 也不需要生成数据快照 , 所以性能比较好 , 而且不需要依赖数据库事务所以可以用于非关系型数据库 , 但是需要手动编写 try .confirm和cancel方法 , 实现比较复杂

什么是TCC模式的 业务悬挂 和 空回滚 ? 如何解决业务悬挂 和 空回滚 ?

空回滚 : 当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
解决方案就是 : 执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。空回滚的解决方案就是保存一条空的回滚记录
业务悬挂 : 对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。
业务悬挂应该避免 , 执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂