本地事务的天花板：跨库跨服务为什么失灵

Corey2026/8/22大约 2 分钟

分布式事务系列 · 阶段 0 · 事务地基 · 第 5/49 篇 · 🚧 占位待学
上一篇：《Spring 事务：传播行为与失效场景》
下一篇：《分布式的物理现实：分区、部分失败与时钟》
学习大纲：《分布式事务学习总纲》

状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 0 · 单元 0.5

一、本文要解决的问题

单机事务的边界到底画在哪？为什么换两个数据源、加一次 RPC，ACID 就集体罢工了？本篇亲手制造一次数据不一致，把「为什么需要分布式事务」变成亲眼所见，随后进入阶段 1 的理论标尺。

二、知识点清单

事务边界的本质：一个连接 + 一个事务管理器的作用域
跨库场景：两个 DataSource 各自独立提交，没有全局协调者
跨服务场景：RPC 调用在本地事务边界之外，网络调用不可回滚
两种典型不一致时序：先提交后失败、先扣款后加款中间崩溃

三、动手实验（学习时必须真跑）

Spring Boot 双 DataSource 小项目：库 A 扣款成功、库 B 加款前抛异常，验证两库状态不一致
记录不一致现场（两库各查一次余额），标注崩溃点在第几步

四、验收标准（全部通过才进入下一篇）

能画出不一致窗口发生的具体步骤，并由此推导出「全局协调者」的必要性

五、阶段验收（本篇是阶段 0收尾篇）

脱稿画出一条 UPDATE 在 InnoDB 中的完整路径（解析 → 行锁 → undo → redo → binlog）
说出 undo log 将来在 Seata AT 里扮演的角色

六、写作提示（补正文时遵守）

开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
版本口径以总纲环境清单为准（Apache Seata 2.6.0 / MySQL 8.0 / RocketMQ 5.x / Spring Boot 3.x）
涉及版本敏感结论时标注出处与时间

本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。