2023年（Q3财年）技术部门CTO线技术人员晋升考核机试题
分布式篇-B 分布式事务
*参考答案*
出题人：湖北TL田超凡
答案制定：湖北TL田超凡
*****试卷启用前绝密****
1 什么是事务？事务的特性有哪些？
答：事务的定义：事务是最小的数据处理单元，主要作用是保证数据库数据状态的一致性。
事物的特性：ACID特性，指的是：
A 原子性：每个事务都是最小的事务处理单元，不可再分
B 一致性：事务提交和回滚前后数据库数据状态是一致的
C 隔离性：事务和事务之间相互独立，互不干涉
D 持久性：事务提交和回滚后，对数据库数据造成的影响是持久的。
2 分布式事务产生的背景？
答：
- 单体项目单数据源：只有一个事务管理器管理事务
- 单体项目多数据源：多个事务管理器管理事务，每个数据源都对应一个事务管理器，多数据源情况下基于JTA+Atomics实现事务管理
- 分布式/微服务项目：每个服务都有一个本地的事务管理器，当需要多个服务之间相互组合调用实现同一个业务逻辑时，就需要基于分布式事务来解决事务问题。
常见的分布式事务解决方案有两种：基于LCN解决分布式事务和基于Seata解决分布式事务。
3 简述CAP定律和BASE理论？
答：
CAP定律是分布式系统的核心概念，它指的是在分布式系统中，系统的数据一致性、可用性、分区容忍性，三者不能兼得，要么保证强一致性，损失可用性（CP模式），要么保证强可用性，损失强一致性（AP模式），P分区容忍性指的是网络抖动等问题对分布式系统的影响，是不可避免的，所以典型的CAP定律约束分布式系统要么实现CP模式，要么实现AP模式，不可避免P网络抖动的问题。
Base理论是数据一致性的概念，它指的是基本可用、软状态和最终一致。他的主要设计思想是在分布式集群环境下允许出现短暂的不可用或数据不一致，但一定要保证每个节点最终数据状态是一致的。
4 2PC和3PC的作用？
答：2PC和3PC可以保证分布式集群环境下每个节点的数据一致性。
5 2PC实现原理和缺点？
答：
2PC实现原理：2PC指的是两阶段提交协议，主要有两类角色组成：协调者、参与方。协调者负责收集和统计所有参与方的意见。两阶段提交指的是准备阶段（投票阶段）和提交阶段。
2PC的缺点：
- 同步阻塞：因为协调者需要接受和统计所有参与方的意见才能进入提交阶段，如果这时候参与方宕机了，协调者就会因为长时间接收不到宕机参与方的消息而一直阻塞等待。
- 单点故障：当协调者宕机，参与方因为长时间接收不到协调者的通知消息而一直阻塞等待。
- 数据一致性问题：当部分参与方commit成功之后，协调者宕机了，此时就会导致出现部分参与方commit成功，部分参与方commit失败的问题，造成在最终提交阶段之前出现数据不一致的问题。
6 3PC实现原理？
答：3PC指的是三阶段提交协议，它的设计思想是：在2PC的基础上引入超时机制并且多加了一层询问，保证数据传输的可靠性。
3PC实现原理：
- 引入超时机制，对协调者和参与方同时引入超时机制
- 将第一阶段准备阶段再次一分为二，最终形成CanCommit、PreCommit、DoCommit三个阶段，保证在最终提交阶段之前每个节点数据状态是一致的。
7 分布式事务的解决方案有哪些？
答：
- 单体项目多数据源：基于JTA+Atomics实现
- 基于RabbitMQ实现，核心思想是最终一致性。
- 基于RocketMQ实现，核心思想是事务消息机制。
- 基于LCN假关闭连接实现分布式事务。
- 基于SpringCloudAlibaba-Seata实现分布式事务。
注意：以上几种分布式事务的常用解决方案仅适用于分布式或微服务项目中服务和服务之间的分布式事务管理，不适用于调用外部三方接口的情况
（6）跨语言解决分布式事务问题，比如支付宝支付接口回调的分布式事务实现策略。
8 LCN解决分布式事务的设计思想和组成部分？
答：LCN解决分布式事务的设计思想是：基于代理数据源假关闭连接的方式实现，参与方在执行完自己的业务逻辑之后，不会立即提交本地事务，而是采用代理数据源假关闭连接的方式实现数据库连接的假关闭，只有最终接收到协调者的事务提交和回滚通知之后才会真正执行相应操作。
LCN解决分布式事务的组成部分：
- 协调者：全局事务管理者
- 发起方：负责调用接口，发起分布式事务。
- 参与方：接受发起方的调用接口请求，接收协调者最终事务处理通知进行事务的真正提交或回滚。
9 LCN解决分布式事务的实现原理？
答：
- 发起方和参与方一直同LCN管理器保持长连接。
- 发起方在调用接口之前，会基于AOP切面创建代理，生成全局事务分组id
- 发起方在调用接口时，会将全局事务分组id作为请求参数封装到请求头中发送给参与方
- 参与方接收到发起方传递的全局事务分组id后，开始执行自己的业务逻辑，执行完毕之后不会立即提交自己的本地事务，而是基于代理数据源实现假关闭数据库连接
- 发起方发送最终的消息通知给协调者，协调者通知参与方进行事务的提交或回滚
10 LCN解决分布式事务的缺点？
答：LCN解决分布式事务的缺点主要体现在以下几点：
- LCN源码官方已经停止维护，使用过程中存在很多不确定性。
- 可能会引发数据库行锁问题：当协调者或者发起方突然宕机了，就会导致事务一直处于开启状态，迟迟不回提交和回滚，从而引发数据库行锁问题，其他线程无法修改该上了行锁的数据。
11 LCN解决分布式事务的源码流程？
答：LCN解决分布式事务的源码流程主要分为两部分：发起方生成全局事务分组ID和传递全局事务ID的实现原理、参与方接收全局事务ID实现假关闭连接的实现原理。
发起方生成全局事务分组ID和传递全局事务ID的实现原理：
- 发起方基于Spring AOP代理技术，基于TransactionAspect#invoke 拦截发起方方法的执行，基于反射获取发起方方法是否标注了@LcnTransactional注解，如果标注了，就会创建一个全局唯一的事务ID存放到ThreadLocal中
- 发起方基于RequestInterceptor拦截器拦截请求，在请求头中加入从ThreadLocal中获取的全局事务分组id
参与方接收全局事务ID实现假关闭连接的实现原理：
- 参与方基于SpringTracingApplier拦截器拦截到发起方的请求之后，获取请求头中的全局事务ID，执行自己的业务逻辑
- 基于代理数据源，重写DataSourceProxy，注释掉commit()、connection.close()方法实现数据源连接的假关闭。
12 Seata的基本概念？
答：Seata是SpringCloudAlibaba微服务框架推出的简易可扩展的自治式分布式事务管理框架，提供了简易版解决分布式事务的解决方案，底层封装好了分布式事务相关解决方案的API，开发者只需将seata包引入到项目中，按需引用相关API即可轻松实现分布式事务一站式管理。
13 LCN和Seata解决分布式事务的区别？
答：LCN提供了协调者管理界面，Seata暂时没有。
两者实现原理基本一致，唯一的区别在于回滚的实现方式不同：
- LCN基于代理数据源假关闭连接的方式实现回滚，可能会存在数据库行锁的问题。
- Seata基于undo_log日志逆向生成SQL回滚的方式实现，不会有数据库行锁的问题，但是多线程环境下可能出现数据脏读的问题。
14 简述Seata的组成部分？
答：Seata主要有三类角色组成：TC事务协调器、TM事务管理器、RM资源管理器
TC事务协调器：类似于LCN中的协调者角色，负责维护全局事务的运行。
TM事务管理器：类似于LCN中的发起方角色，负责控制全局事务的边界，开始一个全局事务。
RM资源管理器：类似于LCN中的参与方角色，负责控制分支事务，实现分支事务的注册和状态上报，接收TC事务协调器的命令实现事务的提交和回滚。
XID：全局唯一的全局事务ID
15 Seata解决分布式事务的实现原理？
答：Seata解决分布式事务的实现原理：
- 构建TC事务协调器，建立TM事务管理器、RM资源管理器和TC事务协调器之间的联系并一直保持长连接。
- 建立TM事务管理器和TC事务协调器之间的联系，创建全局唯一的事务ID(XID)，缓存到TM事务管理器本地的ThreadLocal中。
- TM事务管理器和RM资源管理器同时被Seata代理数据源代理，在原生sql执行前后记录原来和修改后的日志到undo_log日志表中，方便后续根据xid和分支事务id查询日志进行回滚。
- TM事务管理器基于feign调用接口时，会从本地ThreadLocal中获取全局事务id并存放到请求头中，传递给RM资源管理器
- RM资源管理器接收到TM事务管理器传递的全局事务id后，会缓存到本地ThreadLocal中，通知seata-server注册该分支事务
- TM事务管理器发送最终的消息通知（本地事务的执行情况）给TC事务协调器，TC事务协调器接收到最终消息后，通知每个RM资源管理器立即提交或回滚各自的分支事务，此时分两种情况：
- TM事务管理器调用接口执行成功抛出了异常，通知事务回滚消息给TC事务协调器，事务协调器TC通知所有RM资源管理器立即回滚各自的分支事务，实现方式是：根据全局事务id xid和各自的分支事务id查询undo_log日志表，逆向生成sql语句实现回滚，并删除对应的undo_log日志。
- TM事务管理器调用接口执行成功没有抛出异常，通知事务提交消息给TC事务协调器，事务协调器TC通知所有RM资源管理器立即提交各自的分支事务，并根据全局事务id xid和各自的分支事务id删除对应的undo_log日志。
16 Seata解决分布式事务的源码流程？
答：Seata解决分布式事务的源码流程：
- 项目引入了spring-cloud-alibaba-seata.jar包，在项目启动时会解析该jar包，在解析时会读取该jar包根目录下的spring.factories文件中的启动类配置，加载分布式事务解决的核心类GlobalTransactionAutoConfiguration，在解析GlobalTransactionAutoConfiguration时会加载GlobalTransactionScanner核心类。
- GlobalTransactionScanner类实现了AbstractAutoProxyCreator和InitializeBean，用来基于Spring AOP创建代理和初始化完成之后执行附加操作：
GlobalTransactionScanner初始化之后，会创建并注册TM事务管理器和TC事务协调器
GlobalTransactionScanner创建代理类，在代理方法中实现GlobalTransactionInterceptor拦截器的创建，用于后面拦截TM事务管理器发起方方法的执行。
- TM事务管理器方法执行前会被GlobalTransactionInterceptor#invoke拦截，在代理方法中会先基于反射获取TM事务管理器发起方方法上面标注的@GlobalTransactional注解，如果获取到了（表示当前方法启用了分布式事务，是发起方），则会调用transactionTemplate.execute()实现两个重要的操作：
- beginTransaction 调用该方法创建全局唯一的事务id xid
- transactionManager.begin 调用该方法发送请求，申请全局事务id xid，存放到本地ThreadLocal中，然后发送请求，底层是基于netty封装的。
17 源码角度Seata如何生成xid?
答：GlobalTransactionInterceptor#invoke拦截到TM事务管理器发起方方法执行时，会先基于反射获取方法上标注的@GlobalTransactional注解，如果获取到了，表示该方法需要开启一个全局事务，此时会调用transactionTemplate.execute方法：
- beginTransaction 调用该方法创建全局唯一的事务id xid
- transactionManager.begin 调用该方法发送请求，申请全局事务id xid，缓存到本地ThreadLocal中，发送请求。底层是基于netty封装的。
18 源码角度Seata如何生成前置和后置镜像？
答：TM事务管理器调用接口执行成功之后如果抛出了异常，会对原生sql插入undo_log日志，生成前置和后置镜像：
AbstractUndoLogManager#flushUndoLogs 调用该方法生成前置和后置镜像。
ConnectionProxy#processGlobalTransactionCommit 插入一条前置和后置镜像的实现。
19 源码角度Seata发起方如何传递xid的？
答：SeataFeignClient重写了Feign客户端，TM事务管理器基于Feign调用接口时会被该类拦截，从TM事务管理器本地的ThreadLocal中获取全局事务id xid，封装到请求头中传递给RM资源管理器。
20 源码角度Seata参与方如何接收xid的？
答：RM资源管理器重写了TransactionPropagationInterceptor拦截器，用来拦截TM事务管理器发送的请求，从请求头中获取全局事务id xid，并缓存到本地的ThreadLocal中。
21 源码角度Seata如何实现逆向回滚？
答：TM事务管理器调用接口成功之后抛出了异常，会通知TC事务协调器进行事务回滚，TC事务协调器会通知每个RM资源管理器立即回滚各自的分支事务，基于全局事务id xid和分支事务id获取undo_log日志，逆向生成sql实现回滚，并删除对应的undo_log日志，逆向生成sql并实现回滚的实现在：DataSourceManager#branchRollBack方法中。
22 Seata发起方宕机，事务是提交还是回滚？
答：回滚。因为TM事务管理器（发起方）宕机之后，TC事务协调器就会因为长时间接收不到TM事务管理器发送的最终消息通知而自动超时熔断，默认其已经宕机，立即通知所有RM资源管理器回滚各自的分支事务（根据全局事务id xid和分支事务id获取undo_log日志，逆向生成sql实现回滚，并删除对应的undo_log日志）。
23 Seata协调者宕机，事务是提交还是回滚？
答：回滚。基于TCC三阶段补偿机制实现（try/confirm/cancel）。