# 1. 两阶段提交（2PC）的阻塞问题，协调者故障导致参与者持锁悬挂？ A 2PC 无需协调者 B 2PC 完全不会阻塞 C 协调者故障时参与者可自行决定提交 D 协调者故障会让参与者处于"已准备未决"状态，持锁悬挂等待，这是 2PC 的固有缺陷 ✓ 正确答案
# 2. TCC（Try-Confirm-Cancel）模式的三个阶段与幂等、悬挂、空回滚防御？ A TCC 不需要业务补偿逻辑 B TCC 只有两个阶段 C TCC 的 Confirm 无需幂等 D TCC 分 Try/Confirm/Cancel 三阶段，需业务实现补偿，并防御幂等、悬挂、空回滚 ✓ 正确答案
# 3. Saga 长事务模式，正向服务与补偿服务的编排（Choreography）vs 编排（Orchestration）？ A Orchestration 无需补偿服务 B Choreography 有中央调度器 C Orchestration 用中央调度器统一编排，Choreography 用事件驱动去中心化，两者都需补偿机制 ✓ 正确答案 D Saga 只能用编排方式实现
# 4. Seata AT 模式的实现原理，全局锁 + undo_log 镜像 + 反向 SQL 补偿？ A AT 模式需要业务手写大量补偿代码 B AT 模式通过 undo_log 记录前后镜像、全局锁保证写隔离，失败时用反向 SQL 补偿 ✓ 正确答案 C AT 模式不依赖全局锁 D AT 模式回滚不依赖 undo_log
# 5. Seata AT 模式的隔离性，全局读锁缺失导致的脏读问题与业务侧约束 A AT 模式仅做写隔离、无全局读锁，可能产生脏读，业务需容忍或加业务约束 ✓ 正确答案 B AT 模式提供可重复读隔离 C AT 模式有完整的全局读锁 D AT 模式不会产生脏读
# 6. 数据库原生 XA 如何实现 2PC？协调者崩溃后如何用 xa_recover 与悬空事务处理恢复，MySQL 与 PostgreSQL 的差异是什么？ A XA 通过 XA START/PREPARE/COMMIT 实现 2PC，协调者崩溃后用 xa_recover 查询未决事务并决定提交或回滚 ✓ 正确答案 B XA 崩溃后参与者可自动决定提交 C MySQL 与 PostgreSQL 的 XA 支持完全相同 D XA 不需要协调者
# 7. 2PC 与 3PC 的本质差异是什么？3PC 的超时与预备提交为何能缓解阻塞但仍无法彻底解决脑裂？ A 3PC 增加预备提交阶段并用超时缓解阻塞，但脑裂时参与者决策可能不一致，无法彻底解决 ✓ 正确答案 B 3PC 能完全消除阻塞且无脑裂 C 2PC 与 3PC 阶段完全相同 D 3PC 比 2PC 更常用且更可靠
# 8. Seata 四种模式（AT、TCC、SAGA、XA）的适用场景与性能对比？ A XA 模式性能最好 B AT 自动补偿易用、隔离弱；TCC 业务三阶段灵活；SAGA 适合长流程；XA 强一致但性能最差 ✓ 正确答案 C AT 模式隔离性最强 D SAGA 天然强一致
# 9. 分布式事务的一致性强弱，强一致（2PC/AT）vs 最终一致（Saga/TCC）的业务取舍？ A 强一致一定性能最高 B 最终一致永远比强一致好 C 强一致读立即可见但性能低，最终一致允许短暂不一致并通过补偿收敛，业务需按实时性与性能取舍 ✓ 正确答案 D 最终一致无需补偿机制
# 10. 消息最终一致性，本地消息表（Local Message Table）与事务消息（RocketMQ Half Message）？ A 事务消息不需要回查机制 B 本地消息表无需数据库 C 本地消息表把业务与消息放同一本地事务，事务消息用 Half Message 加回查保证业务与消息一致 ✓ 正确答案 D 消费方无需幂等
# 11. 分布式事务的监控与治理，悬挂事务检测、幂等去重与对账补偿？ A 分布式事务无需监控 B 通过悬挂事务检测、幂等去重与对账补偿构成监控-防重-兜底闭环，保障最终一致 ✓ 正确答案 C 幂等去重与分布式事务无关 D 对账补偿只用于强一致事务
# 12. 分布式事务在高并发互联网场景的替代方案，业务拆分、异步解耦与最终一致？ A 业务拆分无法减少分布式事务需求 B 高并发场景应优先使用 2PC 保证强一致 C 异步解耦会降低可用性 D 通过业务拆分、异步解耦与最终一致（消息、Saga/TCC）优先避免分布式事务，保留强一致给资金等刚需 ✓ 正确答案
# 13. Seata Server 的 TC（Transaction Coordinator）高可用部署？ A TC 状态无需持久化 B TC 单点部署即可保证高可用 C TC 集群多节点部署，事务状态共享存储，通过注册中心发现与故障切换，避免单点 ✓ 正确答案 D 客户端无需故障转移
# 14. 分布式事务的补偿与对账双通道（即时补偿 + 定时对账）设计 A 只需即时补偿即可，无需对账 B 即时补偿处理正常失败，定时对账兜底遗漏与异常，两者协同保证最终一致 ✓ 正确答案 C 对账只用于首次失败 D 对账无需幂等
# 15. Saga 执行失败后如何选择前进（正向重试）还是后退（反向补偿）？无补偿能力的服务如何避免进入不可恢复状态？ A 后退补偿不需要幂等 B 所有失败都应前进重试 C 无补偿服务失败后可以直接丢弃 D 可重试错误用前进重试，不可恢复则后退补偿；无补偿服务应设计成幂等可重试或放最后并留人工兜底 ✓ 正确答案
# 16. 分布式事务选型决策树，业务一致性要求、性能容忍度与技术栈？ A 性能容忍度不影响选型 B 所有业务都应使用分布式事务 C 先判断能否避免，再按一致性要求、性能容忍度与技术栈选择最轻量方案，强一致刚需才用分布式事务 ✓ 正确答案 D 技术栈与选型无关
# 17. Percolator 模型与 Google Spanner 外部一致性的工程实现？ A Percolator 用主键 + 2PC 加 Bigtable 锁实现分布式事务，Spanner 用 TrueTime 全局时间戳实现外部一致性 ✓ 正确答案 B Spanner 不使用全局时间 C Percolator 不需要主键 D 两者都用集中式协调实现一致性
# 18. 分布式事务的测试与故障演练（注入协调者故障、参与者超时、补偿失败） A 补偿失败无需测试 B 分布式事务无需故障演练 C 只测正常提交路径即可 D 通过注入协调者故障、参与者超时、补偿失败等场景，验证悬挂恢复、幂等、补偿与对账兜底 ✓ 正确答案
# 19. 分布式事务的额外延迟与吞吐开销如何测量？对比消息最终一致方案时，什么业务量级下分布式事务成本不可接受？ A 分布式事务对吞吐没有影响 B 分布式事务带来额外延迟与吞吐下降，高并发且非强一致场景下其成本不可接受，应改用消息最终一致 ✓ 正确答案 C 消息最终一致方案延迟更高 D 任何业务都适合分布式事务
