股海求生MySQL 的事务，我最早入行那会儿觉得它就是个 BEGIN/COMMIT 的问题，后来被线上一个死锁搞得焦头烂额，才意识到事务背后的东西远比想象中深。很多工作了三五年的开发，聊起事务能脱口而出 ACID 四个字母，可真问一句“InnoDB 靠什么机制保证原子性和持久性”，或者“可重复读到底解决了什么问题、还残留什么问题”，就卡壳了。这篇文章就结合我自己的实践，把 MySQL 的事务机制、隔离级别、MVCC、锁、Spring 事务传播和分布式事务这些事串起来讲一遍，希望能给准备面试或者正在调线上问题的朋友一些参考。
1. 事务的 ACID 不只是四个字母：InnoDB 的实现细节
1.1 原子性和持久性靠的是 undo log 和 redo log
很多人以为 InnoDB 的原子性靠的是“先把所有 SQL 都执行完，成功了再一起提交”，这个理解在概念上没错，但底层实现并不是这么简单。InnoDB 是用 undo log（回滚日志） 来实现原子性的：事务执行过程中，每修改一行数据，都会在 undo log 里记录一条“修改前”的镜像。如果事务中途失败或主动 ROLLBACK，InnoDB 就根据 undo log 把数据恢复到事务开始前的状态。所以，原子性说白了就是“我能把你改过的东西原样还回去”。
持久性则靠 redo log（重做日志）。这里有个关键机制叫 WAL（Write-Ahead Logging），也就是先写日志、再写数据文件。事务提交的时候，InnoDB 并不保证数据页已经刷到磁盘，而是先把 redo log 刷到磁盘。只要 redo log 落盘了，事务就算提交成功。万一 MySQL 在数据页落盘之前崩溃了，重启时用 redo log 重放一遍，就能把没来得及写进数据文件的修改补回去。
提示：
innodb_flush_log_at_trx_commit这个参数决定 redo log 的刷盘策略。设为 1 是每次提交都刷盘，最安全但最慢；设为 2 是提交时只写 OS 缓存、每秒刷一次盘，性能好一些但数据库宕机会丢 1 秒左右数据；设为 0 则是交给系统刷，崩溃时丢的数据更多。生产环境如果对数据安全要求高，还是建议保持 1，别为了那点性能去赌。
1.2 一致性不是数据库单独保证的
ACID 里的 C（Consistency），准确地说不是数据库某个独立机制直接保证的，它更像一个“综合结果”：约束（主键、唯一键、外键、非空、CHECK）+ 事务的原子性/隔离性 + 应用自身的业务逻辑，共同保证数据从一个合法状态变到另一个合法状态。
举个例子：转账场景里，A 扣 100、B 加 100，这两个操作必须在同一个事务里。数据库能保证这两个操作“要么都成、要么都不成”，但“A 扣 100、B 加 100”这个业务规则本身，得靠应用代码写对。如果代码写成了只有扣款没有入账，数据库照样提交。所以我在面试里一般会这样回答一致性：数据库提供的是约束和原子性保障，业务一致性必须由开发者通过事务边界和业务规则来定义。
1.3 隔离性与并发控制：先建立整体认知
隔离性（Isolation）是事务里最复杂的一块，也是本文后面几章要展开的重点。它的本质问题是：多个事务并发操作同一批数据时，如何避免互相干扰。InnoDB 用了两套工具配合：
- 锁（Lock）：用来控制“写”与“写”之间、以及某些“读”与“写”之间的冲突；
- MVCC（多版本并发控制）：用来让“读”操作尽可能不阻塞，同时读到一个一致的快照。
单纯靠锁也能实现隔离，但那样读和写会互相阻塞，并发度极低。MVCC 的存在，就是让普通的快照读（SELECT）不需要加锁，而是走版本链，读到某个时间点的数据快照。隔离级别的差异，本质上就是“锁的使用范围”和“MVCC 快照的生成时机”之间的组合差异。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 隔离级别不是选择题：四种隔离级别背后的并发问题
2.1 未提交读（READ UNCOMMITTED）为什么没人用
READ UNCOMMITTED 是最低级别的隔离：一个事务能读到另一个事务还没提交的数据。这就是 脏读（Dirty Read）。
举个例子：事务 A 给商品价格从 100 改成 80，还没提交；事务 B 这个时候去查价格，读到了 80。结果事务 A 回滚了，价格实际还是 100。B 却拿着 80 去做了后续计算，这个结果就是错的。
实际业务里我能想到唯一可能用它的场景，是某些对实时性要求极高、但允许数据短暂不准确的统计查询（比如无关紧要的在线人数），而且这个查询不参与任何后续写业务。绝大多数系统里，这个隔离级别就是坑，我从来没在正式项目里用过。
2.2 提交读（READ COMMITTED）：解决了脏读，迎来不可重复读
READ COMMITTED 保证一个事务只能读到其他事务已经提交的数据，脏读问题解决了。它也是 Oracle 数据库的默认隔离级别。
但它带来一个新问题：不可重复读（Non-Repeatable Read）。意思是同一个事务里，执行两次相同的 SELECT，读到的结果可能不一样。
场景是这样的：事务 A 先 SELECT 查余额，得到 100；事务 B 此时提交了一笔转账，把余额改成 50；事务 A 再执行一次同样的 SELECT，读到的是 50。A 在同一个事务里看到前后两个不同的值，这就是不可重复读。
在 READ COMMITTED 下，MVCC 的做法是：每条 SELECT 语句执行时生成一个新的 Read View（读视图），所以每次读到的都是“此刻最新已提交”的快照，自然前后可能不一致。
2.3 可重复读（REPEATABLE READ）：MySQL 的默认选择
REPEATABLE READ 解决的就是不可重复读：同一个事务里，快照读的结果始终保持一致。InnoDB 的实现方式是：事务第一次执行快照读时生成 Read View，之后整个事务内都复用这个视图，不管执行多少次 SELECT，读到的都是同一个快照。
这也是 MySQL 默认选 RR 而不是 RC 的原因之一。早期的 binlog 只有 statement 格式（记录 SQL 语句），如果隔离级别是 RC，会出现主从数据不一致的边界情况。RR 下由于快照读固定 + 当前读加锁，配合 statement 格式的 binlog 能更好地保证一致性。当然 MySQL 5.1.5 之后有了 row 格式的 binlog，RC 也安全了，但默认值一直保留至今。
这里要特别强调一个容易混淆的点：RR 并不能彻底解决幻读（Phantom Read）。快照读下，RR 确实能保证两次 SELECT 返回的行数一致；但如果是“当前读” SELECT ... FOR UPDATE、UPDATE、DELETE 这类操作，走的是另一套逻辑，必须配合 next-key lock（临键锁） 才能阻止新插入的数据。这部分在第三章细讲。
2.4 串行化（SERIALIZABLE）：牺牲并发换绝对一致
SERIALIZABLE 是最严的隔离级别，事务完全串行执行，相当于所有读操作也都是当前读，自动加共享锁，写操作加排他锁。它彻底杜绝了脏读、不可重复读和幻读，但并发度也降到最低。
生产环境里几乎没人会把业务库整体设为 SERIALIZABLE，因为性能损耗太大。它的真正价值更多是用来理解“隔离性的上限”，或者在某些特定场景（比如对数据一致性极其敏感的小规模系统）兜底。日常开发中，如果发现某个业务必须靠 SERIALIZABLE 才能保证正确，那大概率不是隔离级别的问题，而是业务设计有问题。
下面这张表是我整理的一个速查：
| 隔离级别 | 解决脏读 | 解决不可重复读 | 解决幻读 | 实现方式 |
|---|---|---|---|---|
| READ UNCOMMITTED | 否 | 否 | 否 | 读不加锁，可能读到未提交数据 |
| READ COMMITTED | 是 | 否 | 否 | 每条 SELECT 新生成 Read View |
| REPEATABLE READ | 是 | 是 | 快照读解决，当前读靠 next-key lock | 事务内复用首个 Read View + 间隙锁 |
| SERIALIZABLE | 是 | 是 | 是 | 所有读都自动加锁 |
2.5 隔离级别的查询与设置
实际工作中，排查问题第一步往往就是确认当前会话的隔离级别：
sql复制-- 8.0 之前的版本
SELECT @@tx_isolation;
-- 8.0 之后
SELECT @@transaction_isolation;
-- 查看全局配置
SELECT @@global.transaction_isolation;
-- 临时修改当前会话
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 修改全局默认，需要 SUPER 权限
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
注意：
SET GLOBAL只对之后新建的连接生效，已经存在的连接不会变。另外 MySQL 8.0 里还可以用SET PERSIST把配置写进 mysqld-auto.cnf，重启后依然有效，比改 my.cnf 方便很多，也更适合在线变更。
3. MVCC 与锁：InnoDB 并发控制的底层路面
3.1 隐藏列、undo log 版本链和 Read View
MVCC 是理解 MySQL 事务的核心，但很多人只听过概念，不知道具体的实现。InnoDB 的每行记录里其实有三个隐藏字段：
DB_TRX_ID：最近一次修改（插入或更新）这行数据的事务 ID；DB_ROLL_PTR：回滚指针，指向 undo log 中该行的前一个版本；DB_ROW_ID：如果没有显式主键，InnoDB 会用它生成隐藏主键（有主键的话该字段没有实际意义）。
当一行数据被多次修改，每次修改都会往 undo log 里写入一个旧版本，并通过 DB_ROLL_PTR 串成一个版本链，越往链表头越新。
Read View（读视图） 是快照读的核心对象，它里面记录了几个关键信息：
m_ids：生成 Read View 时，当前未提交的事务 ID 列表；min_trx_id：未提交事务中的最小事务 ID；max_trx_id：下一个将被分配的事务 ID；creator_trx_id：当前创建这个 Read View 的事务 ID。
判断某个版本的可见性时，InnoDB 拿这行数据的 DB_TRX_ID 去和 Read View 的四个值做判断：
- 如果
DB_TRX_ID < min_trx_id，说明这个版本在 Read View 生成前就已经提交了，可见； - 如果
DB_TRX_ID >= max_trx_id，说明这个版本是由 Read View 生成之后才开始的事务改的，不可见； - 如果
min_trx_id <= DB_TRX_ID < max_trx_id，还要看这个事务 ID 在不在m_ids里：不在，说明已提交，可见；在，说明未提交，不可见； - 如果
DB_TRX_ID == creator_trx_id，说明是当前事务自己改的，可见。
如果当前版本不可见，就顺着 DB_ROLL_PTR 往 undo log 链上下一个版本继续找，直到找到可见版本或链表结束。
这里也解释了一个很多新手困惑的点：为什么 RC 和 RR 的 Read View 生成时机不同？ RC 每次 SELECT 都生成新的 Read View，所以能读到别的事务最新已提交的数据；RR 只在事务里第一次 SELECT 时生成 Read View，之后的 SELECT 全部复用，所以读到的永远是最初那个快照。
3.2 快照读与当前读
把“读”分成两类，是理解 InnoDB 锁行为的关键：
- 快照读（Snapshot Read）：普通的
SELECT ...，不加锁，走 MVCC 读版本链； - 当前读（Current Read）：
SELECT ... FOR UPDATE、SELECT ... FOR SHARE、UPDATE、DELETE、INSERT等，读取的是最新已提交版本，并且对命中的记录加锁。
为什么 UPDATE 必须先“当前读”？因为事务要修改的是最新数据，如果基于旧快照去做更新，就会产生丢失更新问题。所以 InnoDB 在更新前必须先拿到行上的排他锁（X 锁），读最新版本，再加锁，然后修改。
这个机制也引出了很多并发问题的根源：快照读之间不冲突，快照读和当前读也不冲突，但当前读之间会冲突（加锁）。比如两个事务同时执行 SELECT ... FOR UPDATE 更新同一行，后到的那个就只能等锁。
3.3 从间隙锁到 next-key lock：RR 下幻读怎么防
先说说什么是幻读。一个很经典的场景：
事务 A 执行 SELECT * FROM product WHERE price > 100 FOR UPDATE，此时符合条件的记录有 5 条；事务 B 插入了一条新的 price=200 的记录并提交；事务 A 再执行同样的查询，发现多了一条。这就叫幻读。
为什么 RC 下有这个问题？因为在 RC 下 InnoDB 只加记录锁（Record Lock），锁的是索引上已有的记录，不锁“记录之间的空隙”，所以事务 B 可以在间隙里插入新记录。
RR 下，InnoDB 引入了 间隙锁（Gap Lock）：锁住一个开区间，比如 (100, 200] 之间不存在的记录，阻止其他事务在这个范围内插入数据。next-key lock（临键锁） 则是记录锁 + 间隙锁的结合，锁住的是“左开右闭区间”，比如 (100, 200]，既锁住 200 这条记录，又锁住 100 到 200 之间的间隙。
所以 RR 下，事务 A 对某个范围的查询加的是 next-key lock，事务 B 想往这个范围里插入数据时，会被间隙锁挡住，从而避免了幻读。但这也带来了另一个副作用：锁的范围变大了，并发度下降，死锁概率上升。
这里我补一句：如果业务可以在 RC 下保证正确性，建议把隔离级别改成 RC。RC 下 InnoDB 只做**半一致性读（semi-consistent read）**和更窄的锁，并发性能会好很多，死锁概率也低。很多大厂内部默认就是 RC。
3.4 一次死锁排查：从锁的兼容性说起
死锁在我工作中碰到最典型的一次是：两个事务都在做“先查后改”，但加锁顺序相反。
事务 A：
sql复制BEGIN;
SELECT * FROM orders WHERE order_id = 1001 FOR UPDATE; -- 锁 order 1001
UPDATE inventory SET stock = stock - 1 WHERE product_id = 88; -- 锁 inventory 88
COMMIT;
事务 B：
sql复制BEGIN;
SELECT * FROM inventory WHERE product_id = 88 FOR UPDATE; -- 锁 inventory 88
UPDATE orders SET status = 1 WHERE order_id = 1001; -- 锁 order 1001
COMMIT;
A 先持有 order 1001 的锁，想拿 inventory 88 的锁；B 先持有 inventory 88 的锁，想拿 order 1001 的锁。两边互不相让，死锁就发生了。InnoDB 检测到死锁会立刻回滚其中一个事务（回滚代价较小的那个），另一个继续执行。所以 MySQL 并不会因为死锁挂掉，但应用层会不断收到死锁异常。
排查死锁最直接的方法是：
sql复制SHOW ENGINE INNODB STATUS;
重点看 LATEST DETECTED DEADLOCK 这一段，里面会列出两个事务持有什么锁、等待什么锁，以及对应的 SQL 语句。另一个更精细的查询方式是直接查数据字典表：
sql复制SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;
这两张表能告诉你每个事务当前持有和等待的锁，比碰运气看日志高效得多。
经验之谈：降低死锁概率最有效的办法不是调参数，而是让所有事务按固定的顺序访问资源。比如所有更新都先更新 order 再更新 inventory，死锁基本就不会发生。另外，缩短事务执行时间、避免在事务中做远程调用或大查询，也能显著降低锁冲突。
4. 事务的开启与边界：最容易踩坑的细节
4.1 隐式事务、显式事务和 autocommit
MySQL 默认 autocommit = 1，意思是每条 SQL 自身就是一个事务，执行完自动提交。这也是为什么很多人对事务没什么体感——一条 UPDATE 不会有“提交失败”的问题。
写事务时我们通常会用 BEGIN 或 START TRANSACTION 来显式开启。这两者在使用上基本等价，细微差别在于 START TRANSACTION 后面可以跟修饰符，比如：
sql复制START TRANSACTION WITH CONSISTENT SNAPSHOT;
这句话的意思是：立即为当前事务生成一个一致性快照，而不是等到第一条 SELECT 才生成。在做一致性备份或需要跨多表保证读取快照一致时很实用。
还有一个不可忽视的细节：DDL 语句会造成隐式提交。CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE 这些操作，无论在不在事务里，执行前都会自动提交当前事务。所以千万别在一个长事务里混着写 DML 和 DDL，否则事务边界会被悄悄打断。
4.2 长事务的危害：不是慢，而是拖垮系统
长事务指的是执行时间长、一直没提交的事务。它的危害常常是慢慢显现的：
- undo log 膨胀：RR 下如果事务迟迟不提交，它持有的 Read View 会让那些已修改数据的旧版本一直不能被清理，undo log 越积越大，最终撑爆 undo 表空间；
- 锁持有时间长：一个没提交的 UPDATE，会让其他所有想改这条记录的事务全部卡住，直到等锁超时（
innodb_lock_wait_timeout默认 50 秒）； - binlog 体积变大：长事务会导致 binlog 里积累大量未提交事务的数据，影响主从同步延迟。
我见过一个线上事故：一个定时任务在循环里逐条更新数据，每条都放在同一个事务里处理，处理完几十万条才 COMMIT，结果那个事务把一张大表的 undo 撑到几十 GB，磁盘直接告警。所以开发规范里我都会强调：事务尽量短小，大批量操作要分批提交，事务内不要做耗时的外部调用。
4.3 SAVEPOINT：部分回滚的正确姿势
有时候一个事务里有多个步骤，我们希望前面几步不要回滚，只回滚某一步之后的操作。这时候可以用 SAVEPOINT：
sql复制BEGIN;
INSERT INTO orders (...) VALUES (...);
SAVEPOINT sp1;
UPDATE inventory SET stock = stock - 1 WHERE product_id = 88;
-- 这里发现库存不足，回滚到 sp1
ROLLBACK TO SAVEPOINT sp1;
COMMIT;
这样事务会保留 INSERT 的结果，只回滚 UPDATE。SAVEPOINT 在复杂批处理、嵌套流程里很好用，但别滥用——如果业务逻辑依赖它能“跳过失败步骤继续走”，那大概率是业务设计有问题，事务本来就应该严格保证要么全有要么全无。
另外注意：在显式事务里执行 ROLLBACK 时，所有 SAVEPOINT 都会被清除；SAVEPOINT 的数量也有上限（max_savepoints 参数可调，默认比较宽松），但不能无限创建。
5. Spring 事务的传播行为与失效场景
5.1 事务传播行为：从 README 到实践
Spring 是 Java 生态里最常用的事务框架，它定义了 7 种事务传播行为。很多人背概念背得熟，但真正用对的不多。我一个个过一遍，重点说说容易混淆的三种：
| 传播行为 | 含义 | 常用场景 |
|---|---|---|
| REQUIRED | 有事务就加入，没有就新建 | 默认值，绝大多数业务 |
| REQUIRES_NEW | 无论当前有无事务，都新开一个，挂起当前事务 | 日志记录、审计、发送通知 |
| NESTED | 有事务时创建 savepoint，可以局部回滚 | 批量处理中的子任务 |
| MANDATORY | 必须有事务，否则抛异常 | 强制要求调用方在事务内执行 |
| SUPPORTS | 有事务就加入，没有就按非事务执行 | 查询类方法 |
| NOT_SUPPORTED | 强制以非事务方式执行，挂起当前事务 | 大查询，避免长时间持锁 |
| NEVER | 强制要求当前没有事务，否则抛异常 | 基本用不到 |
最容易搞混的是 REQUIRES_NEW 和 NESTED。REQUIRES_NEW 是彻底新开一个物理事务，外层事务回滚不影响内层事务已提交的结果；NESTED 则是在外层事务里建一个 savepoint，如果内层回滚，只回滚到 savepoint 位置，外层事务可以继续。用通俗的话说：REQUIRES_NEW 是“两个人各记各的账，互不相欠”，NESTED 是“一张纸上记两笔账，可以涂掉第二笔保留第一笔”。
我实际中的一个典型用法：订单处理主流程里要写操作日志，日志写失败了不能让主流程回滚，我就会把写日志的方法标注为 @Transactional(propagation = Propagation.REQUIRES_NEW)。但这里有个隐藏坑：如果内层事务自己抛异常被外层捕获了，REQUIRES_NEW 的事务其实已经提交了，日志数据不会丢；但如果异常没有被捕获，外层事务一样会回滚，日志却留下来了，主从数据对账时就会多出一条日志。所以要注意，REQUIRES_NEW 不是“日志绝对不回滚”的万能方案，它只是让内层事务独立于外层事务。
5.2 那些让 @Transactional 悄悄失效的写法
Spring 事务基于 AOP 动态代理实现，所以一切让代理失效的写法，都会让事务失效。我列几个最常见的，全是实际踩坑踩出来的：
1. 方法自调用
同一个类里，方法 A 调方法 B，B 上面标了 @Transactional，B 的事务不会生效。因为 Spring 的代理是外层调用进的，this.xxx() 这种自调用绕过代理，直接执行原始方法。
解决方式是把 B 放到另一个 Bean 里，或者用 AopContext.currentProxy() 获取代理对象后调用。也可以直接注入 ApplicationContext 然后 getBean，但最推荐的是拆分 Bean，职责也更清晰。
2. 异常被 catch 吞掉
@Transactional 默认只对 RuntimeException 回滚。如果方法内部 catch 了异常然后正常 return，Spring 根本不知道事务出错了，照样提交。
java复制@Transactional
public void update() {
try {
orderMapper.update(...);
} catch (Exception e) {
log.error("update failed", e);
// 异常被吞掉，事务不会回滚
}
}
如果业务确实需要捕获异常再抛，一定要保证抛的是 RuntimeException 或设置 rollbackFor，比如：
java复制@Transactional(rollbackFor = Exception.class)
public void update() {
// ...
}
3. 方法本身不是 public
Spring 默认只对 public 方法做代理增强，private、protected、package 方法上的 @Transactional 都不会生效。
4. 数据库引擎不支持事务
MySQL 的 MyISAM 引擎不支持事务。如果表用了 MyISAM，@Transactional 配得再好也没有用。排查方法很简单：
sql复制SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';
5. 多线程环境下的事务边界
@Transactional 只对当前线程有效。如果在一个事务方法里用 new Thread() 或线程池并发执行操作，子线程里的操作不在事务管理范围内。想保证子线程逻辑也参与事务，需要手动把事务控制权传给子线程，但这基本不现实，实际遇到这种需求就该考虑消息队列或分布式事务了。
6. 分布式事务：从本地事务到全局一致性
6.1 为什么本地事务解决不了分布式问题
微服务架构里，一个订单流程往往要跨多个服务：订单服务、库存服务、支付服务。每个服务都有自己的数据库，本地事务只能保证自己库里的原子性，跨库的原子性就管不了了。
试想一下：用户下单，订单服务在自己的库里插入一条订单记录，然后调用库存服务扣库存。如果库存扣减成功但订单库事务回滚了，或者反过来订单插入成功但库存扣减失败，两边数据就对不上了。
这个问题的根源是：单个数据库的锁和事务只能协调本地资源，无法协调多个服务之间的网络调用和分布式资源。
6.2 一致性方案对比：从强一致到最终一致
分布式事务没有银弹，各种方案是在一致性和可用性之间做取舍。我简单梳理一下主流的四条路线：
1. 2PC/XA（两阶段提交）
协调者先问所有参与者“能不能提交”，大家都说能，再统一提交。强一致，但性能差、协调者单点风险高、实现复杂，现在互联网业务已经很少直接用 XA 了。
2. TCC（Try-Confirm-Cancel）
把业务拆成 Try、Confirm、Cancel 三个阶段。Try 阶段预留资源，Confirm 阶段确认执行，Cancel 阶段回滚。例如库存服务 Try 阶段冻结库存，Confirm 阶段真正扣减，Cancel 阶段解冻。这种方案不用数据库事务，靠业务代码保证一致性，可控性强，但每个服务都要实现三段逻辑，开发成本高。
3. 本地消息表/事务消息
核心思路是“最终一致”。以订单和库存为例：订单服务在本地事务里，先写订单表，再往本地消息表插入一条“扣减库存”的消息，一起提交；然后有一个异步任务把消息发到 MQ；库存服务消费消息去扣库存，扣完回调消息状态；如果消费失败就重试，直到成功。这个方案的优点是实现简单，缺点是消息表和生产者在同一个库里，如果消息表数据量大需要清理。
4. 最大努力通知
适用于对实时性要求不高的场景，比如支付结果通知、退款状态同步。调用方不断重试，直到接收方确认收到，或者人工介入。典型例子是支付回调：支付宝回调商户系统，商户系统没收到就周期性重发，直到商户确认。
下面这个表是我画给团队做选型时用的：
| 方案 | 一致性 | 数据延迟 | 开发成本 | 适用场景 |
|---|---|---|---|---|
| 2PC/XA | 强一致 | 无 | 高 | 金融核心交易，少量参与者 |
| TCC | 较强 | 无 | 高 | 对一致性要求极高的核心链路 |
| 本地消息表/事务消息 | 最终一致 | 秒级 | 中 | 订单、库存、积分等异步链路 |
| 最大努力通知 | 最终一致 | 分钟级 | 低 | 回调、对账、状态同步 |
6.3 订单与库存的经典场景，实际怎么做
我之前做过一个订单系统，最开始打算在订单服务里直接调用库存服务的 RPC 接口同步扣库存，放在同一个“假的”事务里处理。结果线上频繁出现超卖和订单状态不一致，排查下来发现根源就是：订单库和库存库是两个物理数据库，本地事务根本管不到库存那边。
后来我们改成了本地消息表 + 事务消息的方案：
- 订单服务创建订单时，在本地事务里插入订单记录和一条“待扣库存”的消息；
- 事务提交后，一个定时任务扫描消息表，把消息发到 MQ；
- 库存服务消费消息，执行扣库存；
- 扣库存成功，更新消息状态为成功；失败则重试，并配合业务兜底；
- 定期对账脚本对比订单表和库存流水，发现不一致就告警。
这样改完之后，订单创建和库存扣减不再强绑定在同一时刻，用户看到订单创建成功的瞬间，库存可能还在路上，但对一致性来说没有影响——最终库存一定扣成功，如果扣不到就转人工处理。
心得：在做这类系统时，一定要跟业务方对齐“一致性级别”。很多业务其实只需要最终一致，完全没必要为了强一致付出极大的性能和复杂度代价。真正需要强一致的核心交易场景，优先考虑 TCC 而非 XA。
说到最后，事务这个东西，语法层面的东西几天就能学会，真正难的是边界意识：事务什么时候开始、什么时候结束、哪些操作放在事务里、哪些必须拿出来、隔离级别怎么选、锁怎么避免冲突。我见过不少线上事故，根因都不是不会写事务，而是对事务的边界和并发行为没有预见性。平时写代码的时候多想想“我这个事务会不会被别的事务堵住”“提交前有没有可能已经死锁了”，比任何面试题都更能训练功底。另外，推荐大家遇到问题先翻 performance_schema 和 SHOW ENGINE INNODB STATUS，把锁和事务的状态看明白，问题往往就解了一半。