MySQL 事务 → 分布式事务 → CAP 追问链

追问路径

Q: MySQL事务的ACID怎么保证的？
→ redo log/undo log/MVCC/锁
  Q: 分布式场景下ACID还能保证吗？
  → 不能，CAP定理限制
    Q: 那分布式事务怎么做？
    → 2PC/TCC/SAGA/消息表
      Q: 你们项目用的哪种？为什么？
      → 根据一致性要求选择（强一致2PC vs 最终一致消息表）

涉及知识点

• 事务隔离级别 / MVCC实现原理 — 单机事务保证
• redo-log与binlog — 崩溃恢复与持久性
• CAP定理 — 分布式系统的根本约束
• 分布式事务方案 — 各方案对比
• RocketMQ事务消息 — 最终一致性实现

核心串联逻辑

1. 单机 ACID：MySQL 靠 redo log(D) + undo log(A) + MVCC+锁(I) + 约束(C)
2. 跨库困境：网络分区下无法同时保证一致性和可用性（CAP）
3. 权衡选择：
   • 强一致：2PC（性能差/Seata AT模式）
   • 最终一致：TCC（侵入性大）/ 本地消息表 / 事务消息（推荐）
4. 项目实战：订单-库存-支付 通常用 RocketMQ 事务消息

面试回答串联

"单机用 MySQL 的 redo/undo/MVCC 保证 ACID。跨服务时 CAP 限制了强一致性，我们项目中订单场景用 RocketMQ 事务消息实现最终一致——半消息+本地事务+回查，兼顾性能和可靠性。"