分布式事务面试高频问题汇总
分布式事务是面试中的高频考点。
大多数候选人能说出几种方案，但追问下去就露馅了。
以下是面试中最高频的问题和回答要点。
问题一：分布式事务的解决方案有哪些？
考察点：对分布式事务方案的全面了解
完整回答
分布式事务有五种常见解决方案：
1. XA 规范（两阶段提交）
- 基于数据库的强一致方案
- 优点：强一致
- 缺点：性能差、同步阻塞
2. Seata AT 模式
- 对业务无侵入的最终一致方案
- 优点：零侵入、性能较好
- 缺点：有全局锁
3. TCC 模式
- 业务层面的强一致方案
- 优点：高性能、无全局锁
- 缺点：侵入性大、三大问题
4. SAGA 模式
- 长事务的编排方案
- 优点：适合长事务
- 缺点：最终一致、不支持隔离
5. 可靠消息 + 最终一致性
- 异步化的最终一致方案
- 优点：性能最高
- 缺点：不保证强一致追问方向
- 每种方案的具体原理是什么？
- 每种方案的适用场景是什么？
- 你们的系统用的是什么方案？
问题二：Seata AT 模式的原理？
考察点：对 AT 模式的深度理解
完整回答
Seata AT 模式的核心是一阶段解析 SQL + 二阶段自动回滚：
一阶段：
1. 解析 SQL，识别 UPDATE/INSERT/DELETE
2. 查询并保存「前镜像」（Before Image）
3. 执行 SQL
4. 查询并保存「后镜像」（After Image）
5. 保存到 undolog 表
6. 注册分支到 TC
二阶段（提交）：
→ 异步删除 undolog
二阶段（回滚）：
→ 使用前镜像反向生成 SQL，还原数据
→ 删除 undolog追问方向
- 什么是前镜像和后镜像？
- AT 模式的全局锁是怎么工作的？
- AT 和 XA 的区别是什么？
问题三：TCC 模式的三个问题及解决方案？
考察点：对 TCC 模式细节的掌握
完整回答
TCC 有三个著名的问题：
1. 空回滚
- 定义：Try 未执行，Cancel 执行了
- 原因：网络问题导致 Try 通知没送达
- 解决：记录 Try 执行状态，Cancel 前检查
2. 幂等
- 定义：Confirm/Cancel 重复执行
- 原因：TC 没收到响应，重试调用
- 解决：唯一键 + 状态机
3. 悬挂
- 定义：Cancel 先于 Confirm 执行
- 原因：Confirm 通知丢失
- 解决：Cancel 前检查 Confirm 状态追问方向
- 空回滚的解决方案具体怎么实现？
- 幂等的唯一键怎么设计？
- 哪个问题最严重？为什么？
问题四：可靠消息最终一致性方案如何保证消息不丢失？
考察点：对可靠消息方案的深度理解
完整回答
可靠消息有两种实现方式：
方式一：本地消息表
1. 本地事务 + 消息表，在同一个事务中
2. 消息表记录消息内容
3. 定时任务轮询消息表，发送消息
4. 更新消息状态
方式二：RocketMQ 事务消息
1. 发送半消息（Half Message）
2. 执行本地事务
3. 本地事务成功 → 提交半消息 → MQ 投递
4. 本地事务失败 → 回滚半消息
5. 如果发送方崩溃 → MQ 反查本地事务状态追问方向
- 半消息是什么？为什么需要？
- 如果反查也失败了怎么办？
- 本地消息表和事务消息哪个更好？
问题五：2PC 和 TCC 的区别？
考察点：对不同分布式事务方案的理解深度
完整回答
| 维度 | 2PC | TCC |
|---|---|---|
| 协议层 | 数据库协议 | 业务协议 |
| 锁粒度 | 数据库行锁 | 无锁（Try 预留） |
| 侵入性 | 需要 XA API | 需要实现 Try/Confirm/Cancel |
| 性能 | 较差（同步阻塞） | 较高（无全局锁） |
| 适用场景 | 多数据库强一致 | 资源敏感场景 |
核心区别
2PC 是数据库层面的协议，强依赖数据库的 ACID 能力。
TCC 是业务层面的协议，把一致性责任交给业务。
追问方向
- 2PC 的同步阻塞问题怎么理解？
- TCC 的性能为什么更好？
- 什么场景下选 2PC，什么场景下选 TCC？
问题六：分布式事务与本地事务的区别？
考察点：对事务本质的理解
完整回答
本地事务：单个数据库的 ACID 事务
优点：
1. 强一致
2. 性能好
3. 实现简单
缺点：
1. 只能保证单个数据库
2. 无法跨数据库分布式事务：多个数据库/服务的 ACID 事务
挑战：
1. CAP 理论：一致性、可用性、分区容忍不可兼得
2. 网络不可靠：消息可能丢失、延迟、乱序
3. 节点可能故障：协调者、参与者都可能崩溃
解决方案：
1. 强一致方案：2PC、TCC
2. 最终一致方案：SAGA、可靠消息追问方向
- CAP 理论在分布式事务中怎么体现？
- BASE 理论是什么？
- 什么场景下可以用最终一致性？
问题七：如何选择分布式事务方案？
考察点：工程实践能力
完整回答
选型决策树：
1. 业务代码能改吗？
├─ 不能改 → AT 模式
└─ 能改 ↓
2. 资源敏感吗？（库存、资金）
├─ 是 → TCC 模式
└─ 否 ↓
3. 事务时间长吗？（> 1分钟）
├─ 是 → SAGA 模式
└─ 否 → AT 模式 / 可靠消息实际案例
案例 1：电商下单
├─ 扣库存 → TCC
├─ 扣余额 → TCC
├─ 创建订单 → AT
└─ 发货通知 → 可靠消息
案例 2：金融转账
└─ 只能用 TCC（强一致）
案例 3：订单处理流水线
└─ SAGA（长事务）追问方向
- 你们系统用的是什么方案？为什么？
- 这个方案有什么缺点？你们怎么优化的？
- 不同方案可以混用吗？
面试回答技巧
1. 先框架后细节
推荐结构：
1. 先说有哪些方案（2-3 句话）
2. 再详细讲一两个最熟悉的
3. 最后说你们系统用的哪个
❌ 错误示范：
「嗯...有 XA，有 TCC...还有...AT？好像还有个什么 Saga？」2. 结合实际项目
推荐结构：
「我们系统用 AT + TCC 混合方案：
- 普通业务用 AT，因为代码不想改
- 库存扣减用 TCC，因为并发高
- 发货通知用可靠消息，因为不需要强一致」3. 预判追问
提前准备可能被追问的点：
1. AT 模式：
- 全局锁怎么工作？
- 和 XA 的区别？
2. TCC 模式：
- 空回滚怎么解决？
- 幂等怎么保证？
3. 可靠消息：
- 半消息是什么？
- RocketMQ 事务消息原理？总结
分布式事务的面试核心：
高频问题类型：
1. 方案有哪些？
2. 原理是什么？
3. 问题怎么解决？
4. 怎么选型？
5. 怎么实践？
回答要点：
1. 全面：能说出所有方案
2. 深入：对 1-2 个方案很熟悉
3. 实战：结合项目经验
4. 思考：有自己的理解记住：能说出方案是入门，能解释原理是合格，能处理问题是优秀。