分布式事务面试手册讲解 ACID、CAP、BASE 理论，详解 2PC/TCC/Saga/Seata AT 等事务方案，

一、基础理论面试题

1. 什么是事务的 ACID 四大特性？

标准答题：ACID是单机数据库事务的四大刚性约束，分别为原子性、一致性、隔离性、持久性，保障单库事务数据绝对可靠。分布式架构无法完全满足完整ACID，需要根据业务取舍一致性与可用性。

高频拓展追问

追问1：详细解释四大特性？答：原子性指事务不可拆分，要么全成功、要么全回滚；一致性指事务前后业务数据约束合法、状态正常；隔离性指并发事务互相隔离，互不干扰；持久性指事务提交后数据永久落地，宕机不丢失。
追问2：为什么分布式无法严格满足 ACID？答：ACID依赖单机单库锁机制与本地事务管控，分布式多服务、多数据库独立运行，加上网络超时、分区、节点宕机等问题，无法统一事务状态，因此无法实现强ACID，只能采用最终一致柔性方案。

核心知识点总结：ACID是单机强一致基石，分布式事务本质是对ACID特性的工程折中，牺牲部分实时一致性换取高可用与高并发能力。

2. 分布式事务为什么会产生？数据不一致的根源是什么？

标准答题：单体项目单库可依靠本地事务保证数据一致；微服务架构下，一个完整业务横跨多个服务、多个独立数据库，本地事务无法跨库跨服务生效，加上网络不可靠、节点故障等问题，最终产生分布式数据不一致问题，因此需要分布式事务解决跨服务数据一致性。

高频拓展追问

追问1：查询业务需要分布式事务吗？答：不需要。分布式事务仅针对写操作、数据变更业务，纯查询无数据变更，无需事务管控。
追问2：分布式数据不一致的三大核心诱因？答：多库多服务数据割裂、网络超时/重传、节点宕机导致事务状态不统一。

核心知识点总结：微服务多库拆分是分布式事务产生的根本原因，网络不确定性是数据不一致的直接诱因。

3. 分布式 CAP 理论是什么？业务如何取舍？

标准答题：CAP是分布式系统核心理论，包含一致性(C)、可用性(A)、分区容错性(P)，三者无法同时满足。分布式网络分区不可避免，P必选，因此业务只能在CP与AP之间二选一。

高频拓展追问

追问1：CP、AP 分别适配什么业务？答：金融支付、账务清算、库存扣减选CP，牺牲可用性保数据强一致；互联网高并发业务、资讯、社交、日志业务选AP，牺牲实时一致，保障高可用，依靠最终一致兜底。
追问2：为什么 P 必须保留？答：分布式系统由多节点、多网络组成，网络分区、断连是常态，放弃P意味着系统无法容忍网络异常，生产完全不可用。

核心知识点总结：CAP核心取舍：金融核心选CP、互联网业务选AP，是分布式事务方案选型的顶层依据。

4. BASE 理论是什么？和 ACID 有什么区别？

标准答题：BASE是CAP理论的工程落地模型，包含基本可用、软状态、最终一致性，是互联网分布式事务的核心指导思想，采用柔性事务，放弃实时强一致，保障高可用、高并发。

高频拓展追问

追问1：什么是软状态？答：允许系统数据存在短暂中间不一致状态，无需实时强一致，等待异步补偿后自动恢复统一。
追问2：ACID 和 BASE 核心差异？答：ACID是刚性实时强一致，优先一致性；BASE是柔性最终一致，优先可用性与并发性能。

核心知识点总结：绝大多数分布式事务（TCC、Saga、MQ事务）均基于BASE最终一致性思想实现。

5. 数据一致性分为哪三级？各自适用场景？

标准答题：分布式数据一致性分为强一致性、单调一致性、最终一致性三级。强一致性写入实时全局统一；单调一致性保障单客户端数据不回退；最终一致性允许短暂不一致，异步修复统一。

高频拓展追问

追问1：秒杀、支付属于哪种一致性？答：必须强一致性，零数据偏差容忍度。
追问2：日常业务为什么大多用最终一致性？答：兼顾高并发、高可用，性能远强于强一致方案，适配绝大多数互联网业务。

核心知识点总结：强一致保数据、最终一致保性能、单调一致保用户体验，业务按需选型。

6. 数据库四大隔离级别是什么？为什么分布式会失效？

标准答题：数据库四大隔离级别从低到高为：读未提交、读已提交、可重复读、串行化，逐级解决脏读、不可重复读、幻读问题。该隔离机制仅针对单机单库事务，分布式跨服务、跨库场景无统一锁管控，原生隔离级别完全失效。

高频拓展追问

追问1：MySQL 默认隔离级别？答：可重复读。
追问2：分布式如何替代数据库隔离级别？答：依靠Seata全局锁、事务快照、业务状态机、对账兜底实现分布式隔离能力。

核心知识点总结：单机隔离级别无法管控分布式并发，分布式数据异常必须依靠事务框架与业务机制兜底。

7. 分布式脏读、脏写、幻写区别与解决方案？

标准答题：脏读是读取事务未提交中间态数据；脏写是并发修改导致数据被覆盖丢失，是AT模式最大缺陷；幻写是批量更新时数据范围变动导致更新错乱。三者均为分布式特有并发问题，无法靠数据库隔离级别解决。

高频拓展追问

追问1：脏写如何彻底解决？答：开启Seata全局锁，锁定数据修改权限，杜绝并发覆盖。
追问2：幻写怎么规避？答：禁止无范围批量更新，限定主键更新、加全局行锁。

核心知识点总结：脏读偏查询异常、脏写偏数据丢失、幻写偏批量错乱，全局锁+业务规范是统一解决方案。

8. 分布式接口幂等性实现方案与生产落地？

标准答题：分布式接口幂等性指同一请求多次重复触发，不会产生多条数据、不会造成业务异常，是分布式事务、MQ消费、接口重试的基础保障。生产主流实现方案包含：唯一索引去重、全局唯一单号幂等、状态机控制、分布式锁拦截重复请求、Token防重机制。

高频拓展追问

追问1：各种幂等方案适用场景？答：唯一索引适配数据库写入场景；业务单号幂等适配支付、订单场景；状态机适配流程类业务；分布式锁适配高并发接口；Token机制适配前端提交接口。
追问2：幂等和重试的关系？答：重试必须依托幂等，无幂等的重试会造成数据重复、资金重复扣款、库存超扣等严重事故，幂等是重试机制的前置基础。
追问3：MQ消费如何保证幂等？答：以消息唯一ID作为幂等键，结合本地消息表或Redis记录消费状态，已消费请求直接拦截，不重复执行业务。

核心知识点总结：幂等性是分布式系统的底层基石，所有重试、异步消费、事务补偿场景必须实现幂等，从源头杜绝重复数据问题。

二、分布式事务六大核心方案

1. 讲讲 2PC 两阶段提交原理与优缺点？

标准答题：2PC分为准备阶段和提交阶段。准备阶段协调者通知所有参与者预执行事务、锁定资源；提交阶段所有节点准备成功则全局提交，任意节点失败则全局回滚，实现强一致性。缺点是资源长锁定、性能差、协调者单点故障会造成永久阻塞。

高频拓展追问

追问1：2PC 最大生产痛点？答：提交阶段超时、协调者宕机，参与者资源永久锁定，事务卡死。
追问2：线上2PC故障如何修复？答：查询事务日志与锁信息，人工比对状态、手动提交/回滚、释放锁资源。

核心知识点总结：2PC强一致、零侵入，但性能差、易阻塞，仅适配低并发金融账务场景，互联网业务基本淘汰。

2. 3PC 和 2PC 的区别？为什么生产不用？

标准答题：3PC在2PC基础上增加预准备阶段，拆分锁时机、增加节点超时自动提交，解决2PC永久阻塞问题。但会引发数据分裂问题，出现部分节点提交、部分节点回滚，导致全局数据不一致。

高频拓展追问

追问1：3PC 可以线上修复吗？答：无法自动修复，只能人工对账校正数据，无生产价值。

核心知识点总结：3PC仅理论优化，存在致命一致性缺陷，全线生产禁用。

3. TCC 事务原理、生产坑点与解决方案？

标准答题：TCC是业务层手动柔性事务，分为Try、Confirm、Cancel三段。Try做资源校验与冻结、不落地业务数据；Confirm全部成功后正式执行业务；Cancel任意失败则解冻资源、补偿回滚。无数据库长锁、并发性能高、无脏数据。

高频拓展追问

追问1：什么是TCC空回滚？如何解决？答：未执行Try直接触发Cancel导致报错；通过事务状态表判断有无Try记录，无记录直接空返回。
追问2：什么是超时悬挂？如何根治？答：网络超时导致滞后Try请求占用已完结事务资源；通过全局事务状态拦截过期请求彻底解决。
追问3：TCC状态表核心字段和作用？答：包含全局XID、分支ID、事务状态、重试次数、超时时间，用于兜底幂等、空回滚、防悬挂。
追问4：TCC幂等重试编码规范？答：所有接口基于XID+业务单号幂等，禁止重试Try，仅阶梯重试Confirm/Cancel，超限标记死信。

核心知识点总结：TCC高性能、近强一致，适配核心交易场景，生产必须配套状态表、幂等、防悬挂、空回滚规范。

4. 本地消息表方案原理与适用场景？

标准答题：本地消息表依靠本地事务，将业务执行与消息入库原子绑定，通过定时任务轮询推送MQ，消费成功更新完成状态，失败自动重试、超限标记死信，实现最终一致性。实现简单、稳定性高。

高频拓展追问

追问1：如何保证消息不丢不重？答：状态机单向流转、定时重试、消费幂等去重。
追问2：为什么不能用于资金库存？答：仅最终一致，存在短暂数据偏差，无法满足核心业务零容错要求。

核心知识点总结：本地消息表是轻量最终一致方案，适配异步通知、积分、日志等非核心业务。

5. RocketMQ 事务消息原理与生产问题解决？

标准答题：RocketMQ事务消息是本地消息表优化方案，无需自建消息表。流程：发送半消息→执行本地事务→事务成功提交消息、失败回滚消息→MQ定时梯度回查未知状态消息，实现最终一致。

高频拓展追问

追问1：重复消费、漏消费怎么解决？答：重复消费靠接口幂等；漏消费靠定时巡检、离线对账兜底。
追问2：消息堆积、回查失败如何处理？答：优化业务耗时、调整回查间隔、清理超时无效消息、异常实时告警。
追问3：半消息丢失如何兜底？答：生产者本地事务日志+MQ轨迹追踪+定时补录三重兜底。
追问4：什么场景禁止使用？答：支付、库存、扣款等核心强一致场景严格禁用。

核心知识点总结：RocketMQ事务消息轻量化、低侵入，仅适配异步非核心业务，无法保障实时强一致。

6. Saga 事务原理、优缺点与生产规范？

标准答题：Saga将长流程大事务拆分为多个独立子事务，串行执行，后置事务失败则反向执行前置补偿逻辑，实现最终一致。无数据库锁、无阻塞，适配超长耗时业务。

高频拓展追问

追问1：Saga 最大缺陷？答：存在中间态脏数据，补偿失败会造成永久数据不一致。
追问2：断点续跑原理？答：持久化每一步事务状态，故障重启后从断点继续执行，无需全局重试。
追问3：生产落地规范？答：正反接口幂等、状态机持久化、超限告警、人工兜底。

核心知识点总结：Saga专为长流程业务设计，适配审批、物流、工单，严禁用于金融核心交易。

7. 分布式事务悬挂完整原理与根治方案？

标准答题：事务悬挂是分布式事务高频异常，特指前置请求网络超时滞后，在当前事务完结后到达服务端，滞后的过期请求重新占用资源、触发异常逻辑，导致事务错乱、数据异常、资源占用卡死。AT、TCC模式均会出现悬挂问题，属于网络时序问题，非框架bug。

高频拓展追问

追问1：悬挂和空回滚的区别？答：空回滚是无Try先触发Cancel，仅单次报错；悬挂是过期滞后请求干扰已完结事务，会引发资源常驻、数据错乱、持续异常。
追问2：为什么超时配置不当会加重悬挂？答：锁超时、事务超时配置不匹配，过期请求未及时拦截，长期占用锁资源，造成事务悬挂堆积。
追问3：生产根治悬挂的方案？答：全局事务状态表校验、过期请求时间戳拦截、事务超时自动失效、请求唯一标识去重四重机制彻底根治。

核心知识点总结：悬挂是网络时序导致的分布式通病，无法完全避免，只能通过状态校验、过期拦截、超时机制兜底根治。

8. MQ消息丢失、重复、堆积深层原理与生产解决方案？

标准答题：MQ事务消息三大核心问题为消息丢失、重复消费、消息堆积，是异步最终一致方案的主要风险点。消息丢失由生产者投递失败、Broker落盘失败、消费者消费宕机导致；重复消费由网络重试、集群重试导致；消息堆积由消费能力不足、业务阻塞、消息异常卡死导致。

高频拓展追问

追问1：如何彻底杜绝消息丢失？答：生产者确认机制+Broker持久化落盘+消费者手动ACK+定时巡检补录四重兜底。
追问2：消息堆积严重如何紧急处理？答：临时提升消费并发、拆分消息队列、过滤无效消息、异步异步化消费逻辑，事后优化业务代码、扩容集群。
追问3：死信消息生产如何处理？答：设置最大重试次数，超限转入死信队列，记录日志告警，人工核对数据修复，禁止死信消息无限重试。

核心知识点总结：MQ异步方案无法规避网络异常，只能通过多重兜底机制，实现消息不丢、不重、不堆积的生产稳定效果。

9. 分布式事务补偿机制分类与生产落地？

标准答题：最终一致性事务无法做到实时强一致，必须依靠补偿机制修复异常数据。生产补偿机制分为三类：定时自动补偿、业务重试补偿、人工对账补偿，层层兜底修复事务异常、网络异常导致的数据不一致问题。

高频拓展追问

追问1：三种补偿的优先级？答：自动重试优先、定时补偿兜底、人工补偿最后防线。
追问2：什么场景需要人工补偿？答：补偿失败、数据错乱、极端故障场景，自动机制无法修复，依靠离线对账人工校正。
追问3：补偿机制为什么要做幂等？答：补偿任务会多次重试，无幂等会导致数据重复修复、二次错乱。

核心知识点总结：补偿机制是最终一致性事务的核心兜底，没有补偿机制的柔性事务，生产无法稳定运行。

10. 详细讲讲 RocketMQ 事务消息完整执行流程与异常分支？

标准答题：RocketMQ事务消息是基于半消息机制+定时回查实现的最终一致性事务方案，无需业务自建消息表，完美解决「业务执行和消息发送原子性」问题，整体分为半消息发送、本地事务执行、消息提交/回滚、定时事务回查、消费者消费五大核心阶段，全程保障消息和本地事务状态一致。

完整详细执行流程：

1. 发送半消息（预发送）：生产者不直接发送正式消息，而是向Broker发送「半事务消息」。该消息对消费者不可见、不会被消费，仅在Broker端临时存储，标记为待确认状态，此时不会触发任何业务消费逻辑。

2. 执行本地事务：Broker收到半消息并持久化成功后，回调生产者本地事务执行方法，生产者执行业务数据库操作（如创建订单、扣减积分），本地事务执行完毕后，会产出三种事务状态：COMMIT、ROLLBACK、UNKNOWN。

3. 消息状态响应处理：本地事务执行完成后，生产者向Broker返回事务执行结果：返回COMMIT，Broker将半消息转为正式可消费消息，推送给消费者；返回ROLLBACK，Broker直接删除半消息，终止整条事务链路，无消息发出；返回UNKNOWN，代表本地事务状态未知、执行异常或超时，Broker保留半消息，等待后续回查。

4. 定时事务回查（核心兜底）：针对UNKNOWN状态、生产者宕机、网络超时导致未响应的事务，RocketMQ Broker会开启定时回查机制，默认每隔一段时间主动回调生产者事务状态查询接口，核实本地事务最终结果，循环重试直至拿到明确的COMMIT/ROLLBACK状态，杜绝事务状态悬挂。

5. 消费者消费消息：消息正式提交后，消费者正常消费执行业务逻辑，生产必须配合手动ACK+接口幂等，解决重复消费问题，消费成功后链路完结。

高频拓展追问

追问1：半消息的核心作用是什么？答：核心是锁定消息链路、隔离未确认消息，保证本地事务未完成前，消费者绝对无法消费消息，彻底避免「业务没执行、消息先消费」的数据错乱问题。
追问2：事务回查的次数和间隔可以配置吗？答：可以，生产支持自定义回查间隔、最大回查次数，超过最大次数仍未拿到状态，会标记事务异常、日志告警，人工介入排查。
追问3：为什么RocketMQ事务消息无法实现强一致？答：回查阶段存在时间窗口，极端场景下会出现本地事务已成功、消息未提交的短暂不一致，且无锁机制兜底，仅能保障最终一致，不支持资金、库存等强一致核心场景。
追问4：生产者宕机在哪个阶段会触发回查？答：本地事务执行后未返回状态、执行过程中宕机、网络超时断连，都会被Broker判定为UNKNOWN状态，触发定时回查兜底。

核心知识点总结：RocketMQ事务消息依靠半消息隔离+定时回查闭环，极简实现业务与消息原子性，是轻量级最终一致首选方案，核心短板是不支持实时强一致。

三、Seata 框架核心面试题

1. Seata 三大核心角色？

标准答题：Seata包含TM、TC、RM三大角色。TM是事务发起者，负责开启、提交、回滚全局事务；TC是中心协调者，统一调度、管控全局事务状态；RM是资源执行者，负责分支事务执行、快照生成与回滚。

高频拓展追问

追问1：全局事务XID如何传递？答：TM生成XID，跨服务链路自动透传，子服务RM自动加入全局事务。

核心知识点总结：TM发起、TC调度、RM执行，三者配合完成分布式事务全流程管控。

2. Seata 四大模式全方位对比与选型？

标准答题：AT模式零侵入、高性能、最终一致，适配通用业务；TCC高侵入、高并发、无脏数据，适配核心交易；Saga适配长流程非核心业务；XA零侵入、强一致、性能极差，适配低并发账务。

高频拓展追问

追问1：90%业务为什么用AT？答：无代码侵入、接入简单、性能优秀，满足绝大多数微服务场景。
追问2：核心交易为什么弃AT用TCC？答：AT存在脏写风险，无法满足零容错核心业务。

核心知识点总结：通用选AT、核心选TCC、长流程选Saga、低并发强一致选XA。

3. Seata AT 模式核心原理与缺陷？

标准答题：AT是改良版2PC。一阶段RM拦截SQL，生成undo_log前后快照，执行本地事务并提交、释放本地锁；二阶段收到TC指令，提交则异步清理快照，回滚则依托前置快照自动还原数据。

高频拓展追问

追问1：AT最大漏洞是什么？答：一阶段释放本地锁、二阶段未决议空窗期存在并发脏写风险。
追问2：脏写如何解决？答：开启Seata全局锁，锁定数据修改权限。

核心知识点总结：AT靠快照实现无侵入回滚，全局锁弥补脏写缺陷，是生产最常用方案。

4. Seata AT全局锁底层原理与读隔离实现方案？

标准答题：Seata全局锁是解决AT模式脏写问题的核心机制，属于分布式行级排他锁。AT一阶段提交本地事务后释放本地数据库锁，但会向TC注册全局锁标记，锁定对应业务数据，其他分支事务修改该数据时，会先校验全局锁，锁占用则阻塞或失败，彻底杜绝空窗期并发脏写问题。原生AT无读隔离能力，需通过全局锁+业务读写规范实现分布式隔离。

高频拓展追问

追问1：全局锁和本地锁的区别？答：本地锁是单机数据库锁，事务提交即释放，管控单库并发；全局锁是Seata分布式锁，贯穿全局事务生命周期，管控跨服务、跨库全局并发，解决分布式锁失效问题。
追问2：开启全局锁后会影响性能吗？答：会轻微降低并发性能，但杜绝了脏写数据故障，核心交易场景收益远大于性能损耗，生产核心业务必须开启。
追问3：AT模式如何实现读已提交隔离效果？答：关闭脏读查询、事务强制读主库、配合全局锁锁定写权限，规避未提交事务数据读取，模拟实现分布式读隔离能力。

核心知识点总结：全局锁是AT模式生产可用的核心保障，专门弥补原生AT脏写漏洞，是分布式读写隔离的关键实现方案。

5. Seata 三层超时机制与优先级？

标准答题：Seata存在全局事务超时、分支事务超时、全局锁超时三层机制，优先级：全局事务超时 > 分支事务超时 > 全局锁超时。生产规范配置：锁超时 < 分支超时 < 全局超时，防止锁提前释放、事务悬挂。

高频拓展追问

追问1：全局超时作用？答：强制终止卡死事务、释放资源，避免长期悬挂。
追问2：锁超时作用？答：自动释放死锁资源，防止服务卡死。

核心知识点总结：三层超时分层兜底，解决事务阻塞、死锁、悬挂问题。

6. Seata 事务失效高频场景与解决方案？

标准答题：常见失效场景：内部同类方法调用注解失效、数据库自动提交未关闭、异步线程XID上下文丢失、多数据源未手动注册、undo_log表缺失、超时配置过小。

高频拓展追问

追问1：异步线程为什么事务失效？答：异步线程无法继承主线程XID，事务传播断裂。
追问2：多数据源为什么失效？答：Seata默认只接管默认数据源，其他数据源无法生成快照、无法回滚。

核心知识点总结：绝大多数Seata事务失效均为编码、配置不规范导致，非框架bug。

7. 跨服务事务上下文丢失（XID传递失效）解决方案？

标准答题：微服务跨调用、异步线程、多线程场景容易出现XID上下文丢失，导致分支事务无法加入全局事务，事务失效、数据不一致。核心原因是Seata上下文基于ThreadLocal存储，跨线程、跨调用无法自动传递。

高频拓展追问

追问1：哪些场景会丢失XID？答：异步线程、线程池任务、Feign自定义调用、内部方法异步调用、跨网关转发。
追问2：线程池如何透传XID？答：自定义线程池包装类，任务提交前捕获主线程XID，子线程执行前绑定上下文，执行后清空。
追问3：Feign调用需要手动传XID吗？答：高版本Seata自动透传，低版本需手动拦截请求头，手动传递XID保证事务联动。

核心知识点总结：XID上下文断裂是微服务事务失效高频坑点，所有跨线程、跨服务调用必须手动透传上下文。

8. undo_log 膨胀问题与生产清理策略？

标准答题：undo_log存储事务快照，长期不清理会导致数据表膨胀、查询变慢、性能退化。生产通过定时任务清理已完结事务快照、冷热数据分区存储、超期数据归档，保障性能稳定。

高频拓展追问

追问1：哪些快照不能删？答：未完结、异常回滚事务快照必须保留，用于故障复盘与手动修复。

核心知识点总结：undo_log定时清理、冷热分离是Seata生产性能优化刚需。

9. Seata TC 集群高可用与防脑裂机制？

标准答题：生产TC必须集群部署，共享数据库持久化事务数据。通过数据库锁实现主节点选举，同一时间仅一个主节点调度事务，杜绝集群脑裂；主节点宕机后自动触发故障转移，备用节点接管服务，无数据丢失。

高频拓展追问

追问1：为什么不用文件持久化？答：文件无法集群共享，极易数据不一致，生产强制数据库持久化。

核心知识点总结：TC集群+数据库持久化是Seata生产高可用的核心保障。

10. Seata锁降级、防击穿、防穿透生产机制？

标准答题：Seata全局锁集群压力过大、锁竞争激烈时，需配置锁防护机制保障服务高可用。锁降级指高并发拥堵、锁等待超时频繁时，临时关闭全局锁、降级为普通事务，保障服务不雪崩；锁防击穿防止大量空请求竞争同一不存在数据锁；锁防穿透防止非法越权请求穿透锁校验。

高频拓展追问

追问1：锁降级的触发条件？答：锁等待超时率过高、TC集群负载爆满、大量事务阻塞堆积，触发自动降级保护。
追问2：降级后如何保障数据一致？答：降级仅限非核心业务，配合短时对账补偿兜底，核心交易业务禁止锁降级。
追问3：防穿透核心逻辑？答：前置校验业务参数、数据合法性，无效请求直接拦截，不进入锁竞争逻辑，减轻TC压力。

核心知识点总结：锁防护机制是Seata生产高可用关键，平衡数据一致性与服务可用性，避免锁竞争导致服务雪崩。

四、生产实战与压轴综合题

1. 分库分表+读写分离下AT模式失效原因与解决方案？

标准答题：读写分离主从延迟导致一阶段快照不准、跨分片事务快照分散无法统一管控、从库无锁机制，最终导致AT模式回滚失败、数据错乱。核心解决方案：事务强制读主库、跨分片核心业务改用TCC、普通业务开启全局锁、业务数据尽量单分片聚合。

高频拓展追问

追问1：为什么读写分离坑最大？答：快照基于从库查询，和主库真实数据不一致，回滚必然出错。

核心知识点总结：分库分表+读写分离是AT模式最大适配难点，核心场景必须切换TCC。

2. 分布式锁+事务联合使用规范？顺序错了会怎样？

标准答题：联合使用强制规范：先加锁、后开事务；锁超时大于事务超时；锁粒度匹配业务范围；事务回滚同步释锁。顺序颠倒会导致锁延迟释放、事务阻塞、并发脏数据。

高频拓展追问

追问1：锁超时小于事务超时会怎样？答：锁提前释放，事务未执行完毕，引发并发脏写、数据覆盖。

核心知识点总结：锁事务顺序、超时匹配是高并发业务防脏数据的关键规范。

3. 分布式事务阶梯重试与超时配置规范？

标准答题：生产禁止固定频率重试，必须使用阶梯递增重试，错峰分散流量，避免重试风暴。全局超时根据业务链路适配，短链路3-5秒、长链路10-30秒，超时强制回滚释放资源，杜绝事务悬挂。

高频拓展追问

追问1：什么是重试风暴？答：大量事务同时重试，瞬间压垮数据库与服务，引发雪崩。

核心知识点总结：阶梯重试防雪崩、合理超时防悬挂，是高可用必备配置。

4. 企业级分布式事务四层兜底架构？

标准答题：生产完整兜底体系分为四层：代码层幂等防重、防悬挂；框架层事务提交回滚管控；调度层重试、巡检、超时回收；数据层实时+离线对账人工兜底，层层防护杜绝数据不一致。

高频拓展追问

追问1：最后一道防线是什么？答：离线全量对账人工校正。

核心知识点总结：单一事务方案无法杜绝异常，四层闭环架构是大厂生产标准。

5. 所有事务方案生产禁用场景汇总？

标准答题：2PC/XA禁用高并发业务；3PC全线禁用；Saga、MQ、本地消息表禁用资金库存核心场景；Seata AT禁用超高并发秒杀、复杂跨分片读写分离核心场景。

高频拓展追问

追问1：核心交易首选什么方案？答：TCC，无脏数据、高并发、强可控。

核心知识点总结：明确禁用场景比选型更重要，从源头规避线上数据事故。

6. 秒杀场景分布式事务整体设计？

标准答题：秒杀超高并发、零超卖容错，整体方案：限流削峰+Redis预扣库存+TCC分布式事务+接口幂等+定时对账兜底，规避AT脏写风险与数据库IO压力，保障高并发与数据绝对一致。

高频拓展追问

追问1：为什么不用AT？答：秒杀并发极高，AT脏写风险会导致超卖，后果严重。

核心知识点总结：超高并发零容错场景必须TCC+多级兜底架构。

7. 复杂混合业务事务方案选型（大厂压轴）？

标准答题：实际生产业务多为混合场景，无法单一套用某一种事务方案，需分层组合选型。核心交易+异步通知组合TCC+RocketMQ事务消息；长流程审批+异步日志组合Saga+本地消息表；通用高并发微服务组合AT+全局锁+限流熔断；超高并发秒杀组合Redis预扣+TCC+定时对账。

高频拓展追问

追问1：为什么混合方案优于单一方案？答：单一方案无法同时满足高并发、强一致、高可用、异步解耦多重需求，组合方案取长补短。
追问2：混合方案最大注意点？答：多事务模式嵌套必须统一XID、做好状态隔离、避免事务嵌套失效、补偿冲突。
追问3：嵌套事务如何管控？答：核心事务优先、异步事务后置、状态机统一记录全流程事务状态，方便故障回溯补偿。

核心知识点总结：生产复杂业务均采用混合事务架构，按需搭配强一致方案与异步最终一致方案，兼顾性能与数据安全。