面试的时候分布式事务是后端绕不开的硬茬子。很多人聊到2PC能背出流程但一问“协调者挂了怎么办”就卡壳也有人能把TCC三个字母报出来却分不清Try阶段该锁什么资源。这两年面试官也学精了不再直接问概念而是上来就扔一个“订单服务调用库存服务怎么保证两边不超卖”的场景题。我利用DeepSeek把这些高频考点系统整理了一遍又把答案一条条咀嚼、校准沉淀成下面这100道题。不要试图死记硬背先把每类题背后的“为什么”想透面试才能应对追问。这份题集按逻辑分为七个部分从基础概念、一致性理论到2PC/3PC、TCC/Saga再到消息事务、框架落地和最后的压轴扩展题。前3类适合验证基础中间3类是方案层重点最后1类属于区分“背题的人”和“真做过项目的人”的题。你可以按目录挑薄弱环节刷。1. 定义题不是白给分事务的边界没搞清楚后面全崩了这类题经常放在一面开场。面试官不是真想听你背书而是想快速判断你有没有把“本地事务”和“分布式事务”的本质边界想清楚。很多候选人一上来就背2PC流程但问他“本地事务为什么在微服务下失效”就答不透了。下面这12道题每一道都是后续所有方案的基础值得逐字推敲。题1什么是本地事务答本地事务指在单一数据库实例内完成的事务。它由数据库自身保障原子性和持久性典型实现是以事务日志和锁机制为基础比如MySQL的InnoDB通过undo日志回滚、redo日志持久化。应用里用Begin Transaction和Commit/Rollback包裹一个业务操作。题2数据库事务的ACID是什么答A是原子性事务里的操作要么全做要么全不做C是一致性事务执行前后数据都要满足业务规则I是隔离性并发事务之间不能随便看到未提交的数据D是持久性事务提交后数据不能丢。这四点是事务可靠性的基石。题3什么是分布式事务答分布式事务是跨越多个独立资源管理器数据库、消息队列、微服务的事务。它需要协调各参与者使整个跨节点操作最终达到一致状态。与本地事务不同分布式事务没有一个数据库单点来统一控制提交和回滚。题4本地事务和分布式事务的核心区别是什么答核心区别是资源边界和决策方式。本地事务只控1个数据库由本库的日志和锁直接决定是否提交分布式事务要协调多个节点的独立事务需要引入额外的协调机制如协议、消息、状态表并且无法依赖单一的本地锁或undo日志完成回滚。题5哪些业务场景最容易引出分布式事务答典型的有三类第一是订单创建并扣减库存第二是账户转账跨多个子账户或跨用户第三是下单后发积分、发优惠券。这些场景共同点是同一业务动作要修改多个独立存储任何一个失败都会造成数据不一致。题6分布式事务里的“参与者”和“协调者”分别指什么答协调者是发起全局事务并决定最终提交或回滚的角色比如Seata的Transaction Manager参与者是被纳入事务并实际执行本地操作的节点比如订单库、库存库各自执行的本地事务。两阶段提交中协调者发指令参与者执行并上报结果。题7为什么同步RPC会放大分布式事务难度答因为同步调用会长时间占用连接、线程和数据库锁。分布事务里如果一边执行成功另一边调用超时谁来回滚、怎么通知对方回滚都变得复杂。长事务还会拉高死锁概率导致数据库连接池被拖垮。题8Redis的事务算分布式事务吗答不算。Redis的MULTI/EXEC只保证单节点上多个命令不被打断但不支持传统意义的事务回滚也没有跨节点协调。它解决的是命令的批量原子执行不是ACID意义上的事务更不是跨库的分布式事务。题9数据库主从复制场景是不是分布式事务答不是主从复制是数据冗余和可用性方案。主库写入后异步同步到从库可能短时间读不到最新数据这是复制延迟不是事务一致性。如果主从同步过程中主库宕机还可能丢数据这和跨库事务要解决的是两码事。题10强一致性、最终一致性、弱一致性怎么区分答强一致性指数据更新后任何后续读取立刻能看到最新值最终一致性指数据更新后经过一段时间所有副本会收敛到一致但期间允许读到旧值弱一致性介于两者之间对读取延迟和时间窗口没有严格保证。分布式事务的不同方案对应不同一致性强度。题11分布式事务中的“一致性”到底指什么答指全局业务状态的一致性即各个参与者在事务结束或最终收敛时看到或保存的数据状态反映同一个业务结果。比如订单已支付库存必须已扣减账户积分必须已发放不能出现订单成功但库存未扣。题12分布式事务处理的核心目标是什么答在跨节点、跨资源的情况下要么让所有本地操作都成功提交并对外可见要么都回滚且不留下脏数据。如果不能做到强一致则要保证数据最终能收敛为一致状态并尽量避免中间态对业务造成不可控影响。2. 一致性理论与CAP面试官真正想听的推导逻辑CAP题不是单纯让背“选两个”面试官更想听你能不能把“为什么不能兼顾”的逻辑说清楚以及落到项目里怎么取舍。BASE和隔离级别在这个环节经常一起考容易混淆。建议把这组题和后面的方案题关联起来每个方案都是对某一对CAP属性的选择。题13CAP理论里的C、A、P分别是什么答C是强一致性所有节点在同一时刻读到相同数据A是可用性每个请求都能在合理时间内得到响应不保证数据最新P是分区容错性网络分区发生时系统仍能继续运行。分布式系统必须面对网络分区所以P必须满足。题14为什么CAP三者最多只能同时满足两个答当网络分区发生时节点间消息无法互通。如果你保证强一致性某些节点就必须拒绝请求于是损了可用性如果你保证所有请求都有响应不同节点可能返回不同数据于是损了一致性。因此同一时刻只能取舍C和A。题15实际分布式事务里怎么取舍CAP答绝大多数互联网业务选择AP最终一致性因为不能因为某个节点故障就让整站不可用。强一致场景只用在资金、账本、库存超卖等有限地方用“短时间锁或串行化”换取一致性。没有一概而论按业务容忍度选。题16BASE理论是什么为什么它比ACID更契合分布式答BASE是Basically Available基本可用、Soft State软状态、Eventually Consistent最终一致的缩写。它允许系统在分区期间保持可用数据暂时不一致但在最终会收敛。因为分布式环境下网络开销和故障无法避免牺牲强一致能换取更好的可用性和性能。题17ACID和BASE最大的区别是什么答ACID强调的是事务提交那一刻的强一致执行期间的状态外界看不到BASE则接受执行期间存在中间状态、允许数据不同步只要最终收敛即可。ACID靠库锁和日志BASE靠业务补偿和异步对账。题18最终一致性怎么实现答常见实现包括本地消息表定时任务、MQ事务消息、事件回溯、以及定期对账补偿。核心思路是先把主业务落库再可靠地发出事件或消息消费方执行后续动作然后借助重试、对账把可能出现的不一致修正。题19数据库隔离级别和分布式事务一致性有什么关系答数据库隔离级别解决的是本地事务并发之间能看到什么数据分布式事务的一致性解决跨节点业务状态收敛结果。但两者会互相影响比如Saga的本地操作如果隔离级别太低中间态被外部读到容易造成业务脏读和重复处理。题20READ COMMITTED和REPEATABLE READ有什么区别答READ COMMITTED只防止脏读同一事务里两次查询可能结果不同REPEATABLE READ保证事务内多次读相同行结果相同但可能遇到幻读。MySQL InnoDB默认REPEATABLE READ通过MVCC和间隙锁处理了部分幻读。分布式事务场景要关注锁范围和性能。题21读未提交有什么危险答读未提交允许读到事务未提交的数据事务一旦回滚读到数据就是脏数据会导致后续库存、订单逻辑基于错误数据继续处理。生产环境几乎不会用这个级别只有在个别想让数据“尽快可见”的分析场景偶尔使用。题22可串行化是什么分布式事务里需要吗答可串行化是最高隔离级别相当于所有事务串行执行结果与某个顺序执行完全一致。分布式事务如果全部要求可串行化性能会非常差。实际中一般只对核心资源做等价串行化比如数据库行锁、Redis分布式锁或唯一约束。题23幻读和分布式事务有什么关系答幻读指事务内两次范围查询返回了不同行数通常由其他事务插入数据导致。在分布式事务里如果多个服务操作同一批数据且没有统一隔离设计会出现类似“先查库存可扣再次确认时库存变了”的问题本质上是并发隔离失效。题24为什么没有隔离级别的事务是有风险的答没有隔离级别多个并发事务会直接读到未提交数据造成脏读、不可重复读和幻读账目会乱库存会超卖。事务隔离级别是保障单库一致性的基础如果分布式事务的本地子事务不给足隔离即使全局协调成功业务数据还是会出错。题25分布式事务里如何实现隔离性TCC和Saga能保证吗答TCC通过资源预留Try加锁降低并发冲突Saga通常不做全局锁靠乐观控制和补偿。两者都不能像数据库2PL一样保证完整的全局隔离所以必须在业务层加幂等、防悬挂和对账机制。分布式事务和隔离级别是设计中各自独立的维度。题26什么是全局事务ID它有什么作用答全局事务ID是贯穿整个分布式事务的唯一编号用来串联所有参与者的本地操作、日志和消息。作用有三个关联各分支事务、去重和幂等判断、故障恢复时定位整条事务链路。题27什么是事务上下文传递主要方式有哪些答事务上下文就是全局事务ID、分支事务ID、锁模式等信息要在服务调用链路里传递。常见传递方式是RPC隐式参数透传、MQ消息头附加、ThreadLocal跨线程传递。只有上下文传到位后续节点才能知道自己属于哪个全局事务。题28跨线程传递事务上下文有什么坑答ThreadLocal只在当前线程内共享如果业务用异步线程池执行子任务上下文会丢如果线程复用旧上下文还可能污染新任务。解决办法是用包装器显式传值并清理线程变量或者用全链路Trace框架统一透传。3. 两阶段提交的磁盘文件与三阶段的超时优化2PC是最经典的分布式事务协议但很多面试者以为它只是“两个阶段发消息”。其实面试官真正关心的是它在协调者宕机、网络超时、参与者失联时会不会卡死以及3PC为什么没能彻底解决这些问题。这组题建议配合“故障脑图”来记。题29两阶段提交2PC的过程是什么答第一阶段是准备阶段协调者向所有参与者发送prepare请求参与者执行本地事务并写日志然后返回yes/no第二阶段是提交或回滚阶段协调者根据所有返回值决定全局提交或回滚并通知各参与者执行commit/rollback。题302PC的两个阶段分别做了什么答准备阶段主要做资源锁定和预提交事务已执行但未持久化提交只记录undo/redo日志提交阶段根据所有参与者是否可提交决定一次性全员commit或全员rollback。核心目的是让所有节点决策一致。题312PC的协调者需要具备什么能力答协调者需要具备事务状态持久化能力记录每个参与者的准备结果需要超时机制和故障恢复逻辑还要有完整的网络交互能力。生产级协调者往往要维持在事务表中的状态机以便宕机重启后按状态继续提交或回滚。题322PC有哪些致命缺点答最大缺点是同步阻塞事务中每个参与者都持有数据库资源锁等待其他参与者响应其次协调者单点故障如果它宕机参与者只能一直阻塞再就是脑裂风险协调者恢复后难以统一决策可能导致部分参与者提交、部分回滚。题33什么是2PC的阻塞问题给个真实例子。答比如订单服务、库存服务、积分服务都收到了prepare指令前两个返回yes积分服务一直网络超时。订单库里已扣的库存会被锁住后续其他订单无法使用同一库存行直到协调者超时回滚才能释放。这时候用户付款下单也可能跟着阻塞。题34如果2PC协调者宕机了怎么办答协调者宕机后参与者无法收到最终提交/回滚指令只能等待。解决办法是协调者把事务状态写本地持久化存储重启后读取状态恢复指令也可用协调者集群或高可用方案。但仅靠2PC协议本身并没有优雅的解决办法。题35什么是3PC它解决了2PC的哪些问题答3PC在2PC基础上增加了预处理阶段CanCommit和超时机制同时参与者在超时后可以主动释放资源或按照既定策略提交。它减少了阻塞时间解决了一部分协调者故障单点问题但增加了协议复杂度并没有从根上解决脑裂。题363PC的CanCommit、PreCommit、DoCommit各做什么答CanCommit先询问参与者“能不能执行”尽量提前发现不可执行的情况避免浪费资源PreCommit让参与者真正执行事务并写日志DoCommit通知大家统一提交。如果参与者超时未收到DoCommit它可能自行提交或回滚视实现而定。题373PC为什么仍然不完美答3PC引入了超时但如果网络分区导致部分节点收到提交消息、部分节点超时自行回滚就会产生部分提交。也就是说3PC把阻塞变短了但没有实现完美的一致性。实际生产中用纯3PC的例子不多大家更倾向于用真实状态机或消息事务替代。题382PC和3PC在实际生产中用得多吗答原生2PC/3PC用得少因为它们太重、数据库锁持续时间长在微服务规模下很难受。很多中间件只是借用了2PC的思想比如Seata AT模式借鉴两阶段思想但不要求全程锁资源XA协议也基于2PC模型但通常用于单库多分支场景。题39数据库XA协议和2PC有什么关系答XA是数据库参与2PC的标准接口规范。事务管理器TM通过XA接口协调多个资源管理器RM做prepare和commit/rollback。Java里JTA事务基于XA。但它跨数据库网络通信时性能损失明显且容易出现全局锁等待问题。题40XA事务模型是什么Spring的JTA事务怎么理解答XA模型就是全局TM多个RM的模型。Spring的JTA事务JtaTransactionManager把多个数据源纳入同一全局事务底层调用数据库XA驱动。实际项目里要配置XA数据源、事务管理器并且处理两阶段提交的prepare阶段。题412PC中的“两阶段”和消息事务的“两阶段”有什么区别答2PC的两阶段是针对多个数据库资源的prepare和commit消息事务的两阶段通常指“发送半消息”和“本地执行后确认提交消息”。消息事务不需要所有参与者同时锁住数据库资源而是通过消息回查达到最终一致阻塞性小得多。题42面试官问“你用过2PC吗”应该怎么答答先承认原生2PC在生产中很少裸用再说理解2PC具备强一致模型但阻塞严重然后结合经验说在订单与库存场景里我用Seata AT或事务消息替代如果真在低并发内部系统用过XA可以说当前量的上限在哪里。这样能展示专业知识不只会背书。4. TCC和Saga不是二选一是场景二选一TCC和Saga是柔性事务里面最常考的两种模式。很多候选人只把TCC的Try/Confirm/Cancel背得滚瓜烂熟但问他“Try阶段是不是必须加资源锁”就答不上来。Saga则总有人把“反向操作”和“回滚”混为一谈。这组题是方案设计的关键也是面试官最愿意深挖的地方。题43TCC是什么Try、Confirm、Cancel各做什么答TCC把事务拆成三个阶段Try做资源预留或检查业务状态临时冻结Confirm真正执行业务提交并释放预留Cancel回滚预留并恢复资源。比如库存服务在Try阶段预占库存Confirm阶段扣减Cancel阶段释放。题44TCC为什么要分三步不能一步锁住资源吗答一步锁资源就是2PC思路整个事务期间资源都不可用导致阻塞。TCC先用Try做短时间预留把可判定结果放到Confirm时再执行这样锁持有的窗口变短业务并发能力更高。代价是需要业务操作天然支持“预留/确认/取消”三个动作。题45TCC的Try阶段一般做什么答Try阶段做业务检查和资源预留。比如转账里检查余额并冻结转账金额订单里检查库存并预占库存。Try阶段若失败就触发Cancel各参与者回滚本地的预留。注意Try不能真正把业务数据改完成态否则Cancel会很难做。题46Confirm阶段如何保证最终一致答只要Try阶段成功Confirm就默认必须成功。Confirm阶段要幂等重复调用不能产生额外扣减补做真正的业务变更把冻结状态变成完成状态。如果Confirm失败一般依赖重试机制而不是走Cancel因为不能两边都变。题47Cancel阶段如果失败会怎么样答Cancel失败会导致已预留资源无法释放业务数据卡在中间态。通常需要记录Cancel状态并提供重试同时要人工告警排查补充方案是定时对账清理。Cancel也要幂等否则重复取消可能把已恢复的数据再扣一次。题48TCC如何解决空回滚、幂等、悬挂答空回滚指Try还没执行就做了Cancel要识别事务状态不执行反向操作幂等是Confirm和Cancel重复调用要安全常用唯一事务ID判断悬挂指Try在Cancel以后才到达需要拒绝或丢弃迟到Try请求。三种问题都要靠事务状态表在业务侧控制。题49什么叫TCC的空回滚怎么避免答空回滚是指Try阶段因为网络超时或未执行协调者直接发起了Cancel而Cancel里没有可回滚的数据。避免方法是在Cancel收到后先查事务记录如果Try未执行就不做任何操作如果Try已执行再执行取消逻辑。这笔状态记录要持久化。题50TCC的悬挂问题为什么会出现答悬挂指Cancel先执行完Try请求才慢悠悠到达这时候Try又会重新预留资源造成资源一直被占用却不被Cancel。解决方法是幂等控制和请求时效校验收到Try时先检查是否已Cancel如果已有Cancel记录就直接忽略Try。题51TCC里怎么设计幂等控制答常见做法是给每个事务生成唯一分支ID在事务状态表里记录主键Try/Confirm/Cancel执行前先查状态表如果状态已存在就返回成功。也可以利用数据库唯一约束确保同一分支事务的请求只处理一次。题52TCC的事务状态是否需要独立存储为什么答需要因为靠内存记录无法保证宕机后恢复。状态表里至少要记录全局事务ID、分支ID、当前阶段Try/Confirm/Cancel、更新时间。独立存储可以是独立的数据库表也可以是Redis加持久化重点是不能在故障时丢状态。题53TCC和2PC的本质区别是什么答2PC是资源层协议事务期间占用数据库写锁等待全局决定TCC是业务层拆分通过三个业务动作减少锁的持有时间。TCC把冲突和补偿逻辑上移到业务所以实现复杂但可用性和并发能力显著优于2PC。题54Saga是什么核心思想是什么答Saga是一种长事务解决方案把一个全局事务拆成多个本地事务每个本地事务都有对应的补偿动作。执行过程中如果某一步失败就反向执行之前所有步骤的补偿。它不要求各阶段立刻对外隔离经常配合异步消息编排。题55Saga的正向操作和反向操作怎么设计答正向操作就是正常的业务动作比如订单创建、扣库存反向操作是业务层的补偿动作比如取消订单、回补库存。反向操作必须能察觉到正向操作是否完成并且最好幂等。补偿里的数据往往是业务状态变更而不是数据库行锁回滚。题56Saga的补偿顺序是串行还是并行为什么答通常串行执行按照正向执行的逆序逐个补偿。串行能避免依赖关系的困扰比如先回补库存再释放支付预授权再取消订单。并行虽然快但多步正向操作之间有数据依赖并行补偿很容易出现资源还没释放就去补充新的数据的情况。题57什么场景适合TCC什么场景适合Saga答TCC适合需要强一点隔离性、资源可冻结的业务比如资金账户冻结、库存预占Saga适合流程长、中间步骤多、最终一致允许的业务比如订票、下单后多个服务协作。核心判断标准是业务允不允许中间状态被别人看到以及有没有轻量的撤销方式。题58Saga没有全局状态管理谁负责协调补偿答两种方式一是编排式Saga由一个中心协调器按顺序调用各参与者失败时中心负责不断重试补偿二是协同式Saga每个服务监听上一个服务发出的事件自己决定下一步和补偿动作。面试里建议说编排式更适合可控性。5. 本地消息表/MQ事务消息订单与库存不丢单的套路工作中最常用、最容易实现落地的一致性方案其实是“消息幂等”。面试官也很爱考这块因为这类问题能看出你是否真正理解异步和最终一致。本地消息表和RocketMQ事务消息本质都是在回答同一个问题本地业务执行和发消息这两个动作怎么保证不丢、不重、顺序可控。题59什么是本地消息表核心思路是什么答本地消息表是在消息发送方所在的数据库里建一张消息表业务数据和消息数据放在同一个本地事务里提交然后通过后台任务扫描消息表发送消息收到消费确认后更新消息状态。核心是利用本地事务保证“业务成功消息一定写入”。题60本地消息表为什么先写业务数据再写消息表答两者必须在同一个数据库事务里提交无所谓谁先谁后但必须在事务内。如果业务数据成功、消息写入失败事务回滚业务不会生效如果业务失败但消息发出去消费端就会处理一个不存在的数据。同库同事务是本地消息表的关键。题61本地消息表为什么能保证最终一致答因为业务数据和消息表同库原子写入后消息投递即使失败后台扫描任务也会不断重试消费端在处理消息时再配合幂等控制最终上下游的数据状态会收敛一致。即使中间有延迟也不会出现业务成功但消息丢失的情况。题62本地消息表频繁扫表有什么问题怎么优化答频繁扫表会产生大量无效查询尤其消息表数据涨上去后索引也会拖慢业务库。常见优化是给状态字段加索引并批量捞取把即将投递的消息先加载到内存队列用定时任务分批处理更彻底的方案是直接用RocketMQ事务消息把扫描这个动作交给MQ组件完成。题63什么是MQ事务消息答事务消息是消息队列对“本地业务和发消息原子性”问题的封装。发送方先发送半消息不上消费者可见在本地事务执行完成后再确认提交或回滚消息如果本地事务状态不明确MQ端会主动回查发送方要求反馈事务结果。题64RocketMQ事务消息的半消息是什么答半消息是已被MQ接收但暂不可被消费者消费的状态消息。它主要用来探测发送方本地事务是否已准备完成。半消息有两种后续发送方明确提交消息转为可消费发送方明确回滚消息被删除不会被消费者看到。题65RocketMQ事务消息的本地检查是什么答本地检查是指当MQ长时间没有得到事务二次确认时MQ会通过回调机制回查发送方询问该条本地事务到底提交了没有。发送方需要能根据业务事务状态表回答“已提交”或“未提交”然后MQ据此提交还是回滚消息。题66RocketMQ事务消息回查解决了什么答回查解决了“本地事务提交成功但消息确认请求丢失”或“发送方在确认前宕机”的问题。通过回查MQ能在故障恢复后重新确定事务结果避免消息漏发或错发。这正是事务消息比普通消息可靠的核心原因。题67Kafka支持事务消息吗和RocketMQ有什么差异答Kafka支持事务性写入和跨分区的原子提交也支持类似事务消息的机制但它的强项在吞吐事务流程配置和回调模型比RocketMQ复杂。RocketMQ的事务消息更贴近“业务回查”模型用起来更直观。面试里不必争论好坏要说清各自适用场景。题68什么是“最大努力通知”答最大努力通知是指发送方发出业务处理结果后通过多次重试把消息传递给接收方并配合接收方主动查询和对账机制尽可能保证对方收到通知。它只保证尽量通知不保证严格的事务一致性比如支付回调后通知商家系统。题69最大努力通知和可靠消息最终一致的区别是什么答最大努力通知没有强依赖“业务本地事务”和“消息写入”的原子性它更强调发送方的尽力投递和接收方主动查询可靠消息最终一致则通过半消息或本地消息表严格保证业务成功必然产生可投递消息。后者更适合核心资金、库存链路。题70订单创建和库存扣减先扣库存还是先锁订单答没有标准答案但要避免超卖和空订单。很多团队选择先创建订单再扣减库存失败则取消订单也有团队先预占库存后再创建订单。关键是必要时加一个库存预占状态防止两个请求同时扣到同一件库存。面试时主动给出你选择的理由更重要。题71事务消息和本地消息表有什么区别答本地消息表要自己在业务库里建表、写定时任务扫描逻辑完全可控但维护成本高事务消息由MQ负责半消息和回查写起来更省心但依赖中间件能力。两者核心一致都是“业务和消息同事务”最终都要靠消费端幂等接收。题72消息重发会导致什么问题如何应对答消息重发最典型的问题是重复扣库存、重复发券、重复转账。应对必须在消费端做幂等写入唯一消息ID、用业务主键做唯一约束、状态机校验前置状态。生产环境里不能依赖“MQ不会重发”一定要默认消息可能重复。题73消费端如何保证幂等列出三种方案答第一用数据库唯一约束比如订单号或消息ID做唯一键第二用Redis分布式锁加状态位先处理再置为已处理第三用业务状态机判断例如只有“待支付”能变成“已支付”重复消息到达时就跳过。这三种可以组合用。题74为什么消息队列不是分布式事务而是解决分布式事务的手段答消息队列不提供事务ACID它提供的是可靠异步通信和重复消费控制。用它解决分布式事务需要配合事务消息、幂等表、状态机和对账等额外机制。MQ只是“可靠消息”的载体事务一致性依然要靠业务设计。题75消息发送成功但消费失败怎么修复答先看消费失败原因如果是数据校验问题通常要人工补数据或用重试队列如果是依赖的下游服务故障则让消息进入重试队列延迟消费多次重试仍失败要转人工或发告警。修复时要保证手动补偿操作也记录到状态表里避免二次修复。题76消息堆积会影响事务一致性吗答会影响“时间窗口”而不是“最终一致性”。比如订单已支付但库存扣减消息在堆积短时间内用户会看到库存没减少业务中间态延长。如果MQ堆积超过容灾时间还可能触发消费者降级所以堆积监控必须纳入分布式事务治理体系。6. Seata/RocketMQ/最大努力通知工程落地避坑题前面那些题偏理论到了这里面试官就会问“你到底用过什么组件”。Seata是目前国内最主流的分布式事务框架RocketMQ则是最常见的消息事务载体。这部分题把你从“懂概念”拉到“有工程经验”的档位。如果没有真实生产经验至少要把每个组件的定位和坑点说清楚。题77Seata是什么答Seata是开源分布式事务中间件支持AT、TCC、Saga、XA四种事务模式。它提供全局事务协调、分支事务注册、事务状态记录和恢复能力让业务代码通过注解即可接入最常用的是AT模式和TCC模式。题78Seata的AT模式核心是什么利用了什么机制答AT模式的核心是“两阶段自动补偿”。一阶段业务SQL正常执行并生成undo日志二阶段如果是提交则清理undo日志如果是回滚则根据undo日志还原数据。它不需要业务写TCC的三段代码因此接入成本低。题79Seata AT模式的一阶段、二阶段是怎么做的答一阶段业务SQL在本地库执行Seata拦截SQL并生成镜像before image和after image记录到undo_log表并注册分支事务二阶段全局提交时删除undo_log全局回滚时根据镜像反向生成补偿SQL把数据恢复原样。整个过程依赖数据库和代理机制。题80Seata AT模式为什么能“无侵入”答因为它通过数据源代理和SQL解析器拦截应用发的SQL自动生成回滚镜像。开发者不需要像TCC那样自己写Try/Cancel逻辑。代价是要求数据库支持事务隔离、表必须有主键且SQL复杂度高时解析可能不够完善。题81Seata TCC模式与AT模式相比有什么优劣势答TCC模式需要业务方实现Try/Confirm/Cancel三个方法开发量大但能精确控制资源锁和补偿逻辑AT模式不用写补偿但依赖数据库undo机制且对复杂SQL和跨表操作支持有限。并发场景下AT的锁冲突可能比TCC更严重。题82Seata Saga模式在Seata中如何使用答Seata Saga通常通过JSON状态机定义步骤和补偿动作由状态机引擎按序执行。每一步可以是Dubbo/RPC调用、HTTP调用或本地方法失败后根据定义反向执行补偿。它适合长链路、无法提前冻结资源的业务。题83Seata与ShardingSphere、MyBatis-Plus整合要注意什么答注意数据源代理顺序Seata要拿到业务数据源做增强MyBatis-Plus的SQL生成要和Seata的SQL解析器兼容ShardingSphere分库分表会改变SQL路由undo_log表必须在每个库都有还要关注多数据源下的事务边界定义。题84微服务中如何让Feign调用和Seata事务绑定同一全局事务答通过Seata的上下文传播机制全局事务发起方把XID放入RPC请求头Feign拦截器或Seata自带适配器从请求头取出XID带到下一个服务。下一个服务的本地事务会被注册为同一全局事务的分支。要确保拦截器顺序不会被业务拦截器覆盖。题85事务分组和配置中心对Seata的重要性答Seata服务端通过事务分组识别不同业务集群的注册和路由配置中心Nacos/ZooKeeper负责push事务配置、服务发现和启动参数。不配置事务分组或配置中心选错会导致客户端连不上TC这时报错很隐蔽会表现为“全局事务未注册”。题86RocketMQ在分布式事务中扮演什么角色答RocketMQ主要承担可靠事件消息通道典型是事务消息半消息回查和普通可靠消息。它负责把业务事件可靠地送达消费者并配合发送端事务状态表实现最终一致性。它本身不解决多个数据库资源的强一致真正的一致靠消费端的幂等和业务校验。题87电商下单链路下单、减库存、清购物车你会选哪种方案答先说结论我一般选“本地消息表或RocketMQ事务消息配合消费幂等”。理由购物车可以延迟清库存建议在支付成功后扣减而不是下单时扣这样能降低超卖和无效占用核心是订单状态更新与消息发送同事务库存消费失败就重试同时定期对账。题88银行转账场景为什么用TCC而不是最终一致性答转账涉及资金中间状态不能被外部可见也不能出现“转出已扣、转入未到”的长期不一致。TCC通过冻结和确认能做到较短时间隔离比异步消息更接近强一致而且资金账户支持冻结、解冻、扣减天然适合Try/Confirm/Cancel模型。题89怎么区分“柔性事务”和“刚性事务”答刚性事务通常指基于数据库ACID的分布式强一致方案比如2PC/XA所有操作要么一起成功要么一起失败适合低并发、强一致柔性事务允许暂时不一致通过重试、补偿、状态机逐步收敛如TCC、Saga、最终消息适合高并发、可容忍短暂中间态。题90框架选型时要重点对比哪些指标答看几点一是事务模式支持AT/TCC/Saga二是侵入性是需要改业务代码还是代理数据源三是性能损耗尤其锁持有时间和额外SQL四是运维复杂度是否需要额外部署组件五是扩展和生态能否和公司现有RPC、MQ、配置中心打通。题91有没有不需要中间件的分布式事务方案答有比如数据库原生XA但要数据源支持、本地消息表自研定时任务、基于事件驱动的Saga、以及业务数据幂等重试表。不用中间件的好处是运维简单坏处是很多底层逻辑要自己写而且调试时容易漏状态不适合复杂链路。题92分布式事务压测主要关注哪些指标答主要看吞吐量、事务成功率、接口延迟、资源锁等待时间、中间件CPU/内存和数据库连接池占用。还要观察到“有故障比无故障时多耗多久”例如模拟一个库存服务超时看整个链路是否能及时回滚会不会拖垮全局线程池。7. 压轴烧脑题幂等、隔离、死锁与恢复面试官把综合题放最后一般是想看你有没有真实碰见过生产事故。这里没有标准答案更重要的是你的排查思路和取舍逻辑。下面这些题不仅是考点也是你在分布式事务方案设计里绕不开的隐患点。题93全局唯一ID和分布式事务有什么关系答全局唯一ID用来关联整个事务链路同时也是幂等键、状态表主键和消息去重依据。没有全局唯一ID事务恢复时没法判断哪一步已经执行、哪一步还没执行异常重试也会造成重复操作。所以很多分布式事务框架的第一个数据项就是全局事务ID。题94分布式事务中怎么设计重试机制答重试必须生成独立任务记录记录重试次数、下一次执行时间重试时执行幂等逻辑要给重试设置最大次数和退避策略超过上限进人工或对账列表。同时注意不能用同步调用线程直接重试否则会拖挂核心接口线程池。题95为什么说幂等是分布式事务的基石答因为分布式环境下网络超时、消息重发、协调者重复决策都是常态。如果不做幂等一次Cancel被重复执行就会多扣一次款一次Confirm被重复执行就会多发一次积分。幂等保证“同一操作执行一次和执行多次结果一致”是各种一致性方案的底层前提。题96分布式锁和分布式事务是什么关系会不会冲突答分布式锁通常解决并发抢资源问题分布式事务解决跨节点一致性问题。如果先加锁再开事务锁可能覆盖多个分支导致长事务持锁如果锁和事务不在一层又可能出现事务还没提交锁已释放的情况。要明确锁的粒度最好锁内只做短操作把耗时的业务计算放到事务外。题97如何排查分布式事务卡住、转账超时答第一看协调者事务状态表找到卡在准备态或提交态的事务第二看各参与者本地undo_log和事务表确认哪个分支没有返回完成第三看网络和数据库连接池是否有大量锁等待最后根据事务ID查log链路定位到具体服务和SQL。大多数“卡住”都源于数据库行锁等待和协调者失联。题98分布式事务里死锁一般怎么处理答从设计上尽量避免死锁比如所有服务按统一顺序访问资源都是库存后积分设置数据库锁等待超时参数让超时事务先回滚在TCC/AT模式下全局事务重复竞争同一行数据很容易触发死锁通常靠让一个事务快速失败并重试来化解。发现死锁后要保留现场日志不能简单重启。题99分布式事务是否可以用最终一致性替代什么情况下不能替代答大部分业务场景可以只要接受短暂中间态并做好对账。但有些场景不能涉及资金清算要求实时的强一致且中间状态不能泄露业务规则要求“同一秒内不能出现两边状态不一致”的合规场景以及并发量极低的内部系统直接XA/2PC反而更保险。题100你如何向面试官总结分布式事务的方案选型答我会说先看业务的一致性容忍度账务类强一致优先选TCC或XA跨服务订单中长链路用Saga可靠异步事件用本地消息表或RocketMQ事务消息如果团队能够接受AT的自动化补偿Seata AT是最低侵入的选择。最后一定要强调幂等、状态表和对账是整个方案的底座缺了它们任何方案都会在故障时露馅。整理完这100道题我自己有个明显感受分布式事务其实没有“银弹”每种方案都是在一致性、可用性、性能和实现复杂度之间做取舍。面试时与其死背每个协议的步骤不如把“什么场景选什么方案、为什么”想透。如果你能用上面这些思路把一个订单链路讲清楚再抛出一个你踩过的坑面试效果会比背完100道题好得多。希望这份清单能成为你准备面试的工具箱而不是又一个收藏夹里的压箱底列表。