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

追问路径#

Q: MySQL事务的ACID怎么保证的？
→ A(undo log回滚) C(约束+应用逻辑) I(MVCC+锁) D(redo log+WAL刷盘)
  Q: 分布式场景下ACID还能保证吗？
  → 不能完全保证，CAP定理限制了一致性和可用性不可兼得(在网络分区时)
    Q: 那分布式事务怎么做？
    → 根据一致性要求选方案
      ├─ Q: 强一致性方案有哪些？
      │  → 2PC(XA协议，协调者单点+阻塞性能差) / Seata AT(自动生成undo log补偿，2-5x延迟开销)
      │    Q: Seata AT模式具体怎么工作？
      │    → 一阶段：拦截SQL解析前后镜像存undo_log表+本地提交；二阶段：成功删undo_log，失败用undo_log回滚
      │      Q: Seata AT的局限？
      │      → 全局锁影响并发(写冲突要排队) / undo log存储开销 / 不支持跨语言
      │        Q: SAGA和TCC怎么选？
      │        → TCC适合短事务+资源可预留(库存冻结)；SAGA适合长事务+步骤多(旅游订单)，补偿复杂但无锁
      └─ Q: 你们项目用的哪种？为什么？
         → 订单-库存-支付场景用RocketMQ事务消息——最终一致性够用，性能好不阻塞
           Q: 事务消息具体怎么工作？
           → 半消息(对消费者不可见) → 执行本地事务 → commit/rollback → Broker定时回查未决消息
             Q: 消息表方案和事务消息对比呢？
             → 消息表更通用(不依赖特定MQ)但有扫表延迟(通常<1s)和DB耦合；事务消息更轻量但绑定RocketMQ

涉及知识点#

• 事务隔离级别 — RC/RR/Serializable与幻读
• MVCC实现原理 — ReadView + undo log版本链
• redo-log与binlog — 崩溃恢复与两阶段提交
• undo-log与事务回滚 — 多版本与回滚段
• 两阶段提交 — redo log与binlog的一致性
• CAP定理 — 分布式系统的根本约束
• BASE理论 — 最终一致性的理论基础
• 分布式事务方案 — 各方案全景对比
• 2PC与3PC — 两阶段/三阶段提交协议
• Seata框架原理 — AT/TCC/SAGA/XA四种模式
• TCC事务模式 — Try-Confirm-Cancel
• SAGA事务模式 — 长事务编排与补偿
• RocketMQ事务消息 — 半消息+回查机制
• 本地消息表方案 — 可靠消息最终一致性

核心串联逻辑#

1. 单机ACID：redo log保证D(WAL先写日志再刷数据页)，undo log保证A(回滚到修改前)，MVCC+锁保证I
2. CAP约束：网络分区(P)不可避免，CP牺牲可用性(超时拒绝服务)，AP牺牲一致性(返回旧数据)
3. 方案谱系：强一致 → 最终一致，性能和复杂度递减
   • 强一致：2PC/XA(阻塞，延迟2-5x) → Seata AT(自动补偿，有全局锁)
   • 最终一致：TCC(侵入大，需预留) → SAGA(长事务) → 事务消息(推荐，解耦)
4. 事务消息优势：天然异步解耦，性能接近普通MQ消息，端到端延迟通常<100ms
5. 代码示例：

   // RocketMQ事务消息生产者
   TransactionSendResult result = producer.sendMessageInTransaction(msg, null);
   // 本地事务监听器
   public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
       try { orderService.createOrder(); return COMMIT_MESSAGE; }
       catch (Exception e) { return ROLLBACK_MESSAGE; }
   }

   java

面试回答串联#

30秒速答#

“单机用MySQL的redo/undo/MVCC保证ACID。跨服务受CAP限制，强一致用Seata AT(有全局锁开销)，最终一致推荐RocketMQ事务消息——半消息+本地事务+回查，兼顾性能和可靠性。“

2分钟展开答#

“MySQL单机事务的ACID通过四个机制保证：redo log用WAL策略保证持久性(先写日志再刷盘)，undo log支持回滚保证原子性，MVCC通过ReadView+undo log版本链实现快照读保证隔离性，约束保证一致性。分布式场景下CAP定理限制了一致性和可用性不可兼得——网络分区不可避免，只能在CP和AP间选择。强一致方案有2PC(XA协议，但协调者单点+阻塞导致延迟增加2-5倍)和Seata AT(自动生成undo log，一阶段本地提交+二阶段异步清理，但全局锁影响并发)。最终一致方案中TCC适合短事务有明确预留资源的场景(如库存冻结)，SAGA适合长事务流程多的场景(如旅游订单多步骤)。我们项目中订单-库存-支付场景用RocketMQ事务消息：先发半消息(消费者不可见)，再执行本地事务，成功commit消息，失败rollback，Broker还会定时回查未决消息。相比本地消息表方案(需要额外建表+扫表延迟)，事务消息更轻量，端到端延迟通常不到100ms。“

相关追问链#

• 分布式锁-事务-一致性方案追问链 — 分布式事务方案的深入对比
• MQ可靠性-顺序-积压-事务消息追问链 — 事务消息的可靠性保障
• MySQL索引-慢SQL-优化实战追问链 — 索引与锁的交互(行锁通过索引实现)