📚 课程目录第4章分布式事务与最终一致性面试题

第4章分布式事务与最终一致性

面试痛点：支付系统事务选型与幂等设计是必考能力项。面试官常要求“结合实际场景讲清楚TCC、SAGA、本地消息表的选型逻辑”，并追问回滚与补偿细节。

Q1：请对比 TCC、SAGA、本地消息表三种分布式事务方案的适用场景与优缺点。

🎯 面试官考察点	选型决策能力、对事务隔离级别与性能取舍的理解、实际落地经验。
🧠 回答框架	1️⃣ 先分场景（短事务/长事务/异步）→ 2️⃣ 对比三者的隔离性与回滚机制 → 3️⃣ 给出选型结论 + 幂等设计要点。
✏️ 简短示例回答	“TCC 适用于强一致、高并发场景，如账户扣款+积分增减，需业务方提供 Try/Confirm/Cancel 接口；SAGA 适用于长事务，如订单+物流+支付，通过补偿事务实现最终一致；本地消息表适合异步解耦且允许短暂不一致的场景，如下单后发 MQ 通知出库。三种方案都必须配合全局唯一 ID 做幂等，并设计重试与回滚策略。”
❓ 可能追问	“如果 TCC 的 Confirm 阶段失败了怎么办？SAGA 的补偿事务是同步还是异步？”
⚠️ 避坑提醒	不要只背定义！强调真实场景下的选型权衡，比如 TCC 空回滚问题、SAGA 查询补偿状态、本地消息表消息积压处理。

Q2：请详细说明幂等设计的实现方案，并举一个支付回滚的案例。

🎯 面试官考察点	是否理解幂等对最终一致性的关键作用，能否结合具体回滚场景讲清“去重-补偿-对账”链条。
🧠 回答框架	幂等实现四步法：① 全局唯一请求 ID ② 去重表/Redis 锁 ③ 状态机+乐观锁 ④ 补偿任务定时扫描。
✏️ 简短示例回答	“以转账回滚为例：A→B 扣款成功但加钱失败。我们使用全局 ID 记录转账单，扣款时更新状态为‘已扣’，加钱操作通过 MQ 异步执行；若加钱失败，定时任务扫描到‘已扣’超时未完成，触发补偿：增加一条冲正记录将金额退还给 A，同时更新状态为‘已回滚’。所有操作以数据库唯一索引保证幂等。”
❓ 可能追问	“如何去重表与本地消息表配合使用？幂等 ID 生成策略如何选？”
⚠️ 避坑提醒	不能只说“用唯一索引”，要说明业务幂等不同于接口幂等，比如多次退款请求需按原金额+原订单去重，而非简单拦截。

Q3：TCC 事务出现空回滚或悬挂问题时，你如何解决？

🎯 面试官考察点	对 TCC 异常场景的深入理解、方案容错设计、是否具备生产级兜底思路。
🧠 回答框架	① 定义空回滚：Try 未执行却调了 Cancel → ② 用事务日志+状态机保证未 Try 的不回滚 → ③ 悬挂问题：Try 超时后 Cancel 先到，Try 后到 → ④ 用防悬挂表记录 Cancel 已执行，Try 到达后直接拒绝并返回成功。
✏️ 简短示例回答	“空回滚：在 Cancel 接口先查询 Try 是否成功，若未成功则直接返回成功。悬挂：在 Try 入口判断该事务 ID 是否已被 Cancel，若是则直接返回成功；同时借助事务协调器的超时重试打幂等防重复。我们还在数据库增加‘已取消标志’位来兜底。”
❓ 可能追问	“如果事务协调器宕机导致状态丢失怎么办？你们用什么 TCC 框架（如 Seata）？它的全局锁怎么实现的？”
⚠️ 避坑提醒	不要只说理论，必须结合框架实现细节（如 Seata 的 TC 日志机制）或自研方案的状态表设计 SQL。

📁 项目名称：电商支付平台 - 混合事务引擎

业务背景	支撑亿级用户，订单、支付、履约、营销积分四大核心域需跨系统数据一致，业务容忍秒级最终一致。
规模指标	日均订单 500 万，峰值 TPS 8000，事务平均耗时 200ms，设计 RTO < 10 秒。
技术栈	Seata（TCC + AT）+ RocketMQ（本地消息表）+ Redis（幂等去重）+ MySQL + XXL-Job（补偿调度）。
核心难点	① 高并发下本地消息表与 MQ 的一致性问题 ② TCC 空回滚/悬挂在业务中复现频繁 ③ 幂等去重表与乐观锁配合时死锁风险。
面试高频追问	“为什么选用 Seata 而非自研？AT 模式与 TCC 模式怎么混合使用的？补偿定时任务如何保证不丢单？”
可迁移回答话术	“在做事务选型时，我遵循‘场景驱动’原则：对核心账务用 TCC 保证强一致，对非核心履约用 SAGA 或本地消息表。幂等和补偿是所有方案的通用底座，我主导设计了基于事务日志+状态机的补偿框架，支持动态扩展能力。” 这套话术可套用到任何分布式系统面试中。

💡 复习提示： 面试时关于分布式事务的建议回答顺序 —— 先定性场景（强一致/最终一致），再定量性能指标（TPS 与延迟要求），最后给出选型方案并补充幂等与回滚细节。切忌上来就背“TCC 有三个阶段”这种课本知识。

第4章 分布式事务与最终一致性