6 事务：ACID、隔离级别、MVCC

第 5 章的共识解决的是「多个副本对同一条日志的顺序达成一致」。但用户不关心日志，用户关心的是「我这次转账，要么扣款和入账都生效，要么都不生效」。这是另一个问题：一组读写如何组成一个不可分割的边界。共识保证副本之间不打架，事务保证一组操作对外表现为一个整体；两者经常一起出现，但不是同一件事。

先看一个每天都在发生的场景。账户 A 向账户 B 转 100 元，服务端执行两条 UPDATE 和一条 INSERT，然后提交。数据库说提交成功，客户端却因为网关超时没收到响应。客户端重试，服务端又执行了一遍。数据库的每个事务都是原子的：第一次扣了 100，第二次又扣了 100，每次都不违反任何约束。用户看到一次成功，账上少了 200。

这个事故里没有哪个事务「写错」。错的是事务边界画在了数据库里，而逻辑请求的边界在数据库外。数据库只能保证「这一个事务全做或全不做」，它不知道「这是同一个用户意图的第二次尝试」。本章要做的，就是把「事务」这个词拆成三层：单机数据库的 ACID、并发事务之间的隔离、跨服务/跨库的提交协议。三层各有各的保证，也各有各的裂缝。

路线是这样：6.1 先把 ACID 四个字母在单机和分布式里的真实含义拆开；6.2 用五类异常说明隔离级别到底在防什么；6.3 讲 MVCC 的版本链、快照和可见性；6.4 对比 InnoDB 与 PostgreSQL 的实现差异；6.5 讲锁、死锁和「什么错误才值得重试」；6.6 讲 2PC、TCC、Saga 的失败窗口；6.7 讲 Outbox 与幂等消费。后半程是四件必须单独成节的事：重试如何把一次转账做成两次（6.8）、用什么命令观测长事务和锁（6.9）、Spanner 如何用 TrueTime 把 2PC 做成全球外部一致（6.10），以及非幂等 INSERT 被重放时会发生什么（6.11）。

一句话先放在这里：事务不是数据库送的免费午餐，而是一份边界声明。边界画错，ACID 也救不了你。

6.1 ACID 在单机与分布式中的含义

先看一条具体的转账语句。它看起来平平无奇，但四个字母都能在这几行里找到落点，也能找到裂缝。

BEGIN;
UPDATE accounts
   SET balance = balance - 100
 WHERE id = 'A' AND balance >= 100;
UPDATE accounts
   SET balance = balance + 100
 WHERE id = 'B';
INSERT INTO transfers (id, from_acct, to_acct, amount)
VALUES ('t-20261019-001', 'A', 'B', 100);
COMMIT;

A（原子性） 说的是：这四条语句要么全部生效，要么全部不生效。第二条 UPDATE 如果因为 B 账户不存在而报错，数据库会把第一条的扣款回滚掉。实现上靠 undo/rollback 段和 WAL：先记「要改成什么」，再改内存页，提交时把日志刷盘；崩溃后用日志重放或回滚。

但原子性有一个容易被忽略的前提：应用程序得让数据库知道「这个事务失败了」。如果第一条 UPDATE 因为 balance >= 100 不满足而影响了 0 行，数据库不会报错，事务会继续执行并提交。余额不足时，扣款语句「什么都没做」，入账语句却加了 100。原子性没有失效，它是被「0 行更新不是错误」这个 SQL 语义绕过去了。应用必须检查受影响行数，或者把条件写成会抛错的约束。

C（一致性） 是最容易被误解的一个字母。教科书说「事务把数据库从一个一致状态带到另一个一致状态」，但「一致」不是数据库自己能定义的。数据库能检查的是它认识的约束：主键、外键、唯一索引、CHECK、NOT NULL。至于「所有账户余额之和不变」「库存不能超卖」「一个用户只能有一个生效的订阅」，数据库不知道，也不会替你检查。

上面那条 SQL 里，balance >= 100 是一个应用层不变量；它只保护了 A 账户不透支，没有保护「转账前后总额不变」。如果第二条 UPDATE 写错了账户，或者金额单位从元变成分，数据库都会欣然提交。C 是应用的不变量，不是数据库的赠品。在分布式系统里，这条不变量往往跨多个库、多个服务，更不可能由某一个数据库的约束来保证。

I（隔离） 管的是并发事务之间「谁能看到谁」。两个人同时转账，会不会读到对方的中间状态？会不会两个人都基于同一个旧余额做决定？这是 6.2 和 6.3 的主题。

D（持久性） 说的是：COMMIT 返回之后，即使进程崩溃、机器断电，已提交的数据也不应该丢。单机上靠 WAL 刷盘（PostgreSQL 的 fsync、MySQL 的 redo log）；分布式里还要靠复制。这里有一个非常常见的错觉：提交成功不等于数据已经到了多数派。

6.1.1 分布式里的 A：不是一个布尔值

单机事务的原子性是二值的：提交了就是全做，回滚了就是全不做。跨服务之后，「全做」需要所有参与者一起提交，「全不做」需要所有参与者一起回滚；而参与者可能在不同机器、不同数据库、不同可用区，任何一方都可能在关键时刻失联。

工程上有三种做法，它们对 A 的保证强度依次递减：

1. 2PC（两阶段提交）：协调者先问所有参与者「能不能提交」，全部同意后再统一提交。它提供原子提交，但参与者在投票后要一直持有锁，直到收到最终决定；协调者崩溃时，参与者会卡在 in-doubt 状态。2PC 的细节和失败窗口在 6.6。
2. TCC（Try-Confirm-Cancel）：每个服务提供「预留 / 确认 / 取消」三个动作，Try 先冻结资源，Confirm 真正扣减，Cancel 释放。它把原子性换成了「业务层的预留 + 补偿」，需要处理空回滚、悬挂和幂等。
3. Saga：每个服务做本地事务，失败时按相反顺序执行补偿。它没有原子性，只有「最终补偿」；中间状态对外可见，补偿也可能失败。

所以「分布式事务」不是一个东西，而是一个谱：左边是强原子、长锁、低可用；右边是最终一致、短锁、要补偿和对账。选型的第一问不是「哪个最强」，而是「这个业务能不能接受中间状态被看到，能不能接受补偿失败后人工介入」。

6.1.2 分布式里的 D：提交、刷盘、复制是三件事

很多人把「事务提交成功」理解为「数据已经安全」。在单机上，这大致成立（前提是 fsync 真的落了盘）；在分布式里，至少要区分三个位置：

• 本机页缓存：数据在内存里，崩溃可能丢；
• 本机 WAL/redo 落盘：单机崩溃可恢复，但机器整机损毁可能丢；
• 多数派副本落盘：才能扛住单机/单 AZ 故障。

PostgreSQL 的 synchronous_commit 控制提交时等什么：

MySQL 对应的是 innodb_flush_log_at_trx_commit 和 sync_binlog：前者控制 redo log 刷盘，后者控制 binlog 刷盘。两个都设为 1 才是「提交即落盘」；只设一个，崩溃恢复后可能出现「数据在、binlog 不在」或反过来，影响复制和 PITR。

这张表说明：D 不是数据库的一个开关，而是一条链。链上任何一段是异步的，链的末端就可能丢数据。异步复制的主库宕机、备库提升，是生产上「已提交数据丢失」最常见的原因之一。

6.1.3 C 在分布式里：从约束变成对账

单机的不变量可以写成约束，让数据库替你在每次写入时检查。跨服务之后，不变量往往长这样：

• 「订单表里的每一笔订单，都必须有一条对应的库存扣减记录」；
• 「账户余额 = 所有流水之和」；
• 「一个支付 intent 最多对应一条成功的扣款」。

这些不变量没有一个能由单个数据库的 CHECK 表达。工程上的做法是把它们拆成三类机制：

成熟系统通常三者都用：本地唯一约束挡住大部分重复，分布式协议处理必须原子的跨库操作，对账兜住协议失败和人为错误。

6.2 隔离级别与异常：从脏读到写偏斜

隔离级别不是「数据库的一个档位」，而是「一组异常，你允许哪些发生」。要理解它，先得认识五类异常。它们不是教科书里的名词，每一种都能对应到一条真实的业务 bug。

6.2.1 五类异常

前三个是「读」的异常，后两个是「写」的异常。丢失更新和写偏斜的区别值得单独记：丢失更新是两个事务写同一行，写偏斜是两个事务写不同的行、但读取的集合有重叠。前者可以被行锁或「第一次更新者获胜」挡住，后者不会产生任何行级写冲突，所以快照隔离也挡不住。

6.2.2 写偏斜：没有写冲突，也能破坏约束

假设医院有一条规则：任何时候至少有一名医生在岗。当前有两名医生 Alice 和 Bob 在岗。两人同时想下班，各自执行：

-- 会话 1（Alice）
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) FROM doctors WHERE on_call;          -- 2
-- 会话 2（Bob），在会话 1 的 SELECT 之后开始
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) FROM doctors WHERE on_call;          -- 2
UPDATE doctors SET on_call = false WHERE name = 'Bob';
COMMIT;
-- 回到会话 1
UPDATE doctors SET on_call = false WHERE name = 'Alice';
COMMIT;

（上面是 PostgreSQL 语法；MySQL 要在 BEGIN 之前执行 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ。）

两个事务读到的都是 2，都认为「还有一个人在」，于是都把自己改成下班。它们写的是不同的行，没有写写冲突；在快照隔离（PostgreSQL 的 REPEATABLE READ、InnoDB 的 REPEATABLE READ 一致读）下，两个都能提交。提交之后 count(*) = 0，规则被破坏。

这不是数据库的 bug，而是快照隔离的语义：它保证「你看到的是一个一致的快照」，不保证「你的写和别人的写合起来像一个接一个执行」。要阻止写偏斜，需要可串行化，或者手工加锁（例如先 SELECT ... FOR UPDATE 锁住所有在岗医生），或者把不变量变成数据库能检查的约束。

6.2.3 隔离级别：标准说的和数据库做的

SQL 标准定义了四个级别，用三个「读异常」来区分。但标准只规定「不允许什么」，没规定「怎么实现」；同一个级别在不同数据库上的行为可能不同。

这张表有三个容易踩的坑：

1. PostgreSQL 的 READ UNCOMMITTED 不是「真的允许脏读」，它被静默提升为 READ COMMITTED。想复现脏读，在 PG 上做不到。
2. PostgreSQL 的 REPEATABLE READ 是快照隔离（SI），不是标准意义上的锁式 RR。它没有幻读，但允许写偏斜；很多团队以为「RR 就安全了」，其实只是换了一类异常。
3. InnoDB 的 REPEATABLE READ 对「一致读」和「锁定读」是两套语义。普通 SELECT 读快照，SELECT ... FOR UPDATE 读最新版本并加 next-key lock。同一个事务里混用两者，容易出现「读到的和锁到的不是同一版」。

6.2.4 丢失更新：绝对值写入与增量写入

丢失更新经常被和写偏斜混为一谈。看一个最小例子：

T1: SELECT balance FROM accounts WHERE id='A';   -- 100
T2: SELECT balance FROM accounts WHERE id='A';   -- 100
T1: UPDATE accounts SET balance = 110 WHERE id='A';  -- 应用算好的绝对值
T2: UPDATE accounts SET balance = 120 WHERE id='A';  -- 覆盖，T1 的 +10 消失

在 PostgreSQL 的 REPEATABLE READ 下，T2 的 UPDATE 会发现这行已经被 T1 改过，返回 40001 could not serialize access due to concurrent update，应用必须重试。在 InnoDB 的 REPEATABLE READ 下，T2 的 UPDATE 会等待 T1 提交，然后基于最新版本执行；如果 SQL 写的是 SET balance = 120（绝对值），T1 的更新仍然会被覆盖；如果写的是 SET balance = balance + 20（增量），则不会丢。

所以「数据库的隔离级别能防丢失更新」这句话只在特定写法下成立。最稳的写法是让数据库做增量，或者用版本号/CAS：

UPDATE accounts
   SET balance = balance - 100, version = version + 1
 WHERE id = 'A' AND version = 7 AND balance >= 100;
-- 受影响行数为 0：要么版本变了，要么余额不足；应用据此决定重试还是拒绝

这条语句把「检查」和「写入」合并成一个原子操作，不依赖隔离级别，也不依赖读到的旧值。它是第 4 章 CAS 思想在事务里的落地。

6.3 MVCC：版本、快照、可见性

如果没有 MVCC，读和写会互相阻塞：读要加共享锁，写要加排他锁，一个长查询就能把整张表的写入卡住。MVCC 的思路是：写不覆盖旧值，而是产生一个新版本；读按自己的快照选择看哪个版本。这样读不阻塞写、写不阻塞读，代价是旧版本要保留、要回收。

图里有一条 x 的版本链：v0(x=0) → v1(x=1) → v2(x=2)。T1 在 T2 提交之后仍然读到 x=1，因为 T1 的快照是在 T2 提交之前拿的。这不是 bug，是快照隔离的承诺：一个事务看到的世界，在它开始（或第一次读）的那一刻被冻结了。

6.3.1 三个词：版本、快照、可见性

• 版本（version）：某一行的某一个历史状态，带有「谁创建的」「谁删除/替换了它」的元数据。
• 快照（snapshot / read view）：一个事务在某一时刻看到的「事务 ID 边界」，通常包括「哪些事务还活跃」「下一个未分配的事务 ID」。
• 可见性（visibility）：给定一个版本和一个快照，判断这个版本对当前事务是否可见。可见性规则是 MVCC 的核心，也是不同数据库实现差异最大的地方。

三者合起来回答一个问题：「我现在读这一行，应该读哪个版本？」 答案不是「最新的」，而是「我的快照允许我看到的最新版本」。

6.3.2 PostgreSQL：元组头的 xmin/xmax

PostgreSQL 把版本信息放在每个堆元组的头部：

• xmin：创建这个元组的事务 ID；
• xmax：删除（或锁定）这个元组的事务 ID；0 表示没被删除；
• cid：命令 ID，用于同一事务内的语句顺序。

快照由三部分组成：

xmin  = 快照时刻仍活跃的最小事务 ID（更早的事务一定已结束）
xmax  = 快照时刻下一个尚未分配的事务 ID（更大的事务一定还没开始）
xip   = 快照时刻仍在进行中的事务 ID 列表

在 psql 里可以直接看：

SELECT pg_current_snapshot();
-- 100:105:101,102

100:105:101,102 的意思是：小于 100 的事务都已结束，大于等于 105 的事务都还没开始，101 和 102 两个事务在快照时刻仍然活跃。一个元组的 xmin 如果落在 xip 里，或者 >= xmax，对当前快照就不可见。

可见性判断可以写成下面这段伪代码（省略了命令 ID、子事务、冻结、行锁的 LOCK_ONLY 等细节）：

def visible(xmin, xmax, snap, self_xid, committed):
    if xmax == self_xid:  # 自己删掉的版本，对自己不可见
        return False
    # 自己写的东西，自己一定看得见
    if xmin == self_xid:
        return True
    # 插入者没提交，或者快照建立时它还没开始/还在活跃
    if not committed(xmin) or xmin >= snap.xmax or xmin in snap.xip:
        return False
    # 没有被删除
    if xmax == 0:
        return True
    # 删除者已提交，且对快照可见，才算真的被删了
    deleted = committed(xmax) and xmax < snap.xmax and xmax not in snap.xip
    return not deleted

注意最后一行：xmax 有值不代表元组已经不可见。如果删除它的事务在快照之后才提交，或者当时还在活跃，那么这个删除对当前快照「还没发生」，元组仍然可见。「已删除」是一个相对于快照的事实，不是一个全局事实。

6.3.3 InnoDB：undo log 里的旧版本

InnoDB 的行里没有把每个版本都摊在表上，而是只保留最新版本，旧版本放在 undo log 里，通过行头的 DB_ROLL_PTR 串成一条版本链：

聚簇索引行（最新）
  DB_TRX_ID = 900
  DB_ROLL_PTR ──▶ undo record（x=2, trx=900, roll_ptr=...）
                     └──▶ undo record（x=1, trx=800, roll_ptr=...）
                              └──▶ undo record（x=0, trx=700）

一致读（普通 SELECT）拿一个 read view，从最新版本沿 ROLL_PTR 往回走，直到找到第一个「对 read view 可见」的版本。read view 的四个字段是：

判断规则比 PostgreSQL 更直接：

trx_id == creator_trx_id        → 可见（自己的修改）
trx_id <  min_trx_id            → 可见（在 read view 之前已提交）
trx_id >= max_trx_id            → 不可见（read view 之后才开始）
trx_id in m_ids                 → 不可见（read view 时还活跃）
否则                             → 可见

再叠加「删除标记」：版本带 delete_flag 时，还要看删除它的事务对 read view 是否可见；可见才继续往回找，不可见则这个版本仍然有效。

6.3.4 长事务为什么危险

MVCC 的旧版本不是免费的。只要还有一个快照需要某个旧版本，数据库就不能回收它。于是一个「忘了提交」的事务会带来连锁反应：

• PostgreSQL：VACUUM 无法清理比最老快照更旧的死元组，表会膨胀；索引也会膨胀；查询变慢；极端情况下事务 ID 回卷（wraparound）风险上升。
• InnoDB：purge 线程无法清理 undo，History list length 持续增长；回滚段变大；磁盘占用上升；崩溃恢复变慢。

这两种症状在 6.9 都有对应的观测命令。这里先记住一个可执行的规则：OLTP 事务应该以毫秒到秒计，不要以分钟计。批量任务要分批提交，报表要用只读事务/快照导出，不要让一个 BEGIN 跨越用户思考时间。

6.3.5 一个可复现的快照实验

开两个 psql 会话，按下面的顺序执行，可以直接看到「T1 在 T2 提交后仍然读到旧值」：

-- 会话 1
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT balance FROM accounts WHERE id = 'A';   -- 100

-- 会话 2
BEGIN;
UPDATE accounts SET balance = 50 WHERE id = 'A';
COMMIT;

-- 会话 1，再次查询
SELECT balance FROM accounts WHERE id = 'A';   -- 仍然是 100
COMMIT;

6.4 InnoDB 与 PostgreSQL 的实现差异

两个数据库都支持 MVCC，都用「快照 + 版本」实现读不阻塞写，但存放版本的位置、回收方式、锁的粒度完全不同。理解差异不是为了站队，而是为了在出问题时知道该看什么指标。

6.4.1 更新为什么在两边长得不一样

InnoDB 的聚簇索引就是表：主键决定行的物理位置。更新一行时，它尽量在原地改，把旧值写进 undo，回滚指针指向旧版本。这样主键查询很快，但二级索引里存的是主键值，二级索引本身不携带事务 ID；当二级索引扫描命中一行时，可能需要回到聚簇索引做可见性判断。覆盖索引能减少回表，但不一定完全消除这种检查。

PostgreSQL 的堆表不按主键排序，更新一行会写一个新元组，旧元组留在原地，索引条目指向具体的元组位置（TID）。这带来两个后果：

• 更新频繁的表会积累死元组，必须靠 VACUUM 回收；回收跟不上就膨胀。
• 如果更新没有改索引列，并且新元组能放在同一页的空闲空间里，PG 可以做 HOT 更新，不新增索引条目；否则每个索引都要新增一条指向新元组的记录。

这解释了一个常见现象：同样的更新量，MySQL 的表大小可能很稳定，PostgreSQL 的表却在涨。不是 PG「更差」，而是它的版本存放策略把回收的责任明确交给了 vacuum；只要 autovacuum 跟得上，空间会复用，表大小会趋于稳定。跟不上的时候，VACUUM FULL 能立刻收缩，但会持锁重写整表，生产上要谨慎。

6.4.2 回收：purge 与 vacuum 的对照

一个可执行的检查顺序是：先找最老的事务/查询，再看回收指标，最后才考虑调参数。大多数「回收不动」不是参数问题，而是一个忘了提交的连接或一个跑了几小时的查询。

backend_xmin 越小，说明这个连接持有的快照越老，阻挡的回收范围越大。一个 idle in transaction 状态、xact_age 几小时的连接，通常就是膨胀的元凶。

6.5 锁、死锁与重试

MVCC 让读不阻塞写，但写和写之间仍然要排队。两个事务改同一行，数据库必须用锁保证「后一个不会基于过期的版本做决定」。锁用得好是并发控制，用不好就是死锁和超时；而死锁之后怎么重试，决定了系统是「短暂抖动」还是「雪崩」。

6.5.1 锁的层次

PostgreSQL 的行锁有一个容易忽略的细节：普通 SELECT 不加锁，所以它不会阻塞 UPDATE；SELECT ... FOR UPDATE 才会。InnoDB 的普通 SELECT 也不加锁（一致读），但 SELECT ... FOR UPDATE 在 RR 下会加 next-key lock，锁住的范围可能比你想象的大。

6.5.2 死锁：两个事务的加锁顺序相反

死锁的最小例子是两条转账语句以相反顺序更新两个账户：

-- 会话 1
BEGIN;
UPDATE accounts SET balance = balance - 10 WHERE id = 'A';
UPDATE accounts SET balance = balance + 10 WHERE id = 'B';
COMMIT;

-- 会话 2（几乎同时）
BEGIN;
UPDATE accounts SET balance = balance - 10 WHERE id = 'B';
UPDATE accounts SET balance = balance + 10 WHERE id = 'A';
COMMIT;

会话 1 持有 A 的行锁，等 B；会话 2 持有 B 的行锁，等 A。两边都不肯放手，形成环。数据库的处理方式不一样：

• InnoDB 默认开启死锁检测（innodb_deadlock_detect=ON），发现环后立刻回滚「代价较小」的那个事务，客户端收到 ERROR 1213 (40001): Deadlock found when trying to get lock。
• PostgreSQL 在 deadlock_timeout（默认 1 s）后检测等待图，发现环就中止其中一个事务，返回 40P01 deadlock_detected。

两者都会牺牲一个事务来打破环。死锁不是异常，而是并发系统的正常现象；应用必须能识别并重试，而不是把它当成 bug 报给用户。

6.5.3 哪些错误值得重试

不是所有数据库错误都能重试。把「唯一键冲突」重试一百次，只会得到一百次冲突；把「语法错误」重试，只会浪费连接。大致分三类：可重试、不可重试、结果未知。

最容易犯的错是「在同一个事务里重试一条语句」。PostgreSQL 里，一条语句失败后整个事务进入 aborted 状态，后续语句全部返回 25P02，必须先 ROLLBACK。重试的单位是整个事务，不是单条 SQL。

6.5.4 一个可用的重试封装

下面这段代码只重试「可重试」的 SQLSTATE，并且重试的是整个事务：

import random
import time

import psycopg

RETRYABLE = {"40001", "40P01", "55P03"}


def run_tx(dsn: str, work, attempts: int = 5):
    """work(conn) 在一个事务里执行；失败时整体回滚并重试。"""
    with psycopg.connect(dsn) as conn:
        for i in range(attempts):
            try:
                with conn.transaction():
                    return work(conn)
            except psycopg.Error as exc:
                if exc.sqlstate not in RETRYABLE or i == attempts - 1:
                    raise
                # 指数退避 + 抖动：避免所有客户端同时重试
                delay = min(0.05 * (2 ** i), 1.0)
                time.sleep(delay * (0.5 + random.random()))

这段代码有四个刻意的选择：

1. 只捕获 psycopg.Error 并检查 sqlstate，不靠错误消息文本匹配；消息会随版本/语言变化。
2. 重试整个 conn.transaction() 块，而不是块里的某条语句；这样每次重试都是一个干净的事务。
3. 退避带抖动，否则一批同时死锁的请求会在同一时刻再次相撞。
4. 最多 5 次，并且没有无限循环；重试耗尽后把错误抛给上层，由上层决定降级还是返回用户。

如果连接本身断了（08006），上面的 with psycopg.connect(...) 不会自动重连；生产代码需要在外层重建连接，并且用幂等键保证「断线前的提交可能已经生效」不会变成重复副作用。这一点在 6.8 和 6.11 会展开。

6.5.5 减少死锁的四条规则

1. 统一加锁顺序：所有事务按主键/账户 ID 排序后依次加锁；不要一个按 A→B、一个按 B→A。
2. 缩短事务：把网络调用、文件 IO、用户交互挪到事务外；事务里只留必要的读写。
3. 一次锁够：能一条 UPDATE ... WHERE 完成的，不要先 SELECT 再 UPDATE；能批量更新的，不要逐行循环。
4. 设置超时：SET lock_timeout = '2s'、SET statement_timeout = '5s'，让慢事务快速失败，而不是无限等待拖垮连接池。

6.6 分布式事务：2PC、TCC、Saga

单库事务的边界是 BEGIN ... COMMIT，跨库之后没有这样一个语句能包住两个数据库。你要么引入一个协调者，让所有参与者按同一个决定提交或回滚（2PC）；要么把「原子性」降级成「预留 + 确认/取消」（TCC）；要么承认中间状态存在，用补偿把系统拉回一致（Saga）。三条路都有失败窗口，区别在于窗口里谁被阻塞、谁能自救。

6.6.1 2PC：两个阶段，一个决定

协调者 C                    参与者 A                参与者 B
   │ ① prepare ─────────────▶│                        │
   │ ◀───────────── vote yes │                        │
   │ ① prepare ──────────────────────────────────────▶│
   │ ◀────────────────────────────────────── vote yes │
   │
   │ ② 把 commit 决定写入日志（必须先落盘）
   │ ② commit ──────────────▶│                        │
   │ ② commit ───────────────────────────────────────▶│
   │ ◀─────────────── ack    │                        │
   │ ◀─────────────────────────────────────── ack    │

第一阶段（prepare/vote）：协调者问每个参与者「这个事务能不能提交」。参与者在本地执行事务的所有写，把 undo/redo 和 prepared 状态写入日志，锁住相关资源，然后投票 yes 或 no。投 yes 意味着「我能提交，但我现在不能单独决定」。

第二阶段（commit/abort）：如果所有参与者都投 yes，协调者把「commit」决定写入自己的日志（必须先落盘），再给所有参与者发 commit；只要有一个投 no，就发 abort。参与者按决定执行，释放锁，回 ack。

6.6.2 2PC 的失败窗口

最危险的是第四行：一部分参与者已经提交，另一部分还在等。如果等待的参与者「等不及了」，自己决定回滚（启发式回滚），系统就出现「A 库扣了钱、B 库没入账」的分裂。XA 规范允许这种启发式决定，但工程上应该把它当成事故：宁可阻塞，也不要让参与者单方面推翻协调者的决定。

2PC 的代价也很具体：

• 延迟：至少两轮网络往返，加上协调者和参与者的日志 fsync；跨可用区时，每次 fsync 都是毫秒级。
• 锁持有时间长：从 prepare 到 commit，参与者一直持有行锁；并发一高，锁等待和死锁都会上升。
• 协调者是单点：协调者崩溃时，所有 in-doubt 事务都卡住；生产上协调者本身要用 Paxos/Raft 复制。
• 吞吐有上限：每个事务都要两次持久化和多轮 RPC，不适合高并发短事务。

6.6.3 TCC：把原子性换成预留

TCC 把一次业务操作拆成三个动作：

TCC 有两个经典问题，名字听起来玄，本质都是「消息/请求乱序 + 重试」：

• 空回滚（empty rollback）：Cancel 先于 Try 到达。参与者没有对应的 Try 记录，不能报错（否则协调者会一直重试），而要记录「这个分支已取消」，返回成功。等 Try 后来到达时，看到「已取消」就拒绝执行，避免资源被预留后永远不释放。
• 悬挂（hanging）：Try 在 Cancel 之后到达。如果没有上面的「已取消」记录，Try 会成功预留资源，但 Confirm 永远不会来，资源就挂住了。解决方法是 Try 先查事务控制表：状态是 cancelled 就拒绝。

TCC 还需要一张事务控制表（tx_id、branch_id、status），记录全局事务和每个分支的状态。Try 插入 try，Confirm 更新为 confirm，Cancel 更新为 cancel；所有更新都用「状态机 + 条件更新」保证幂等和顺序。TCC 的隔离性来自「预留」：冻结的金额还在账户里，但可用余额已经减少，其他事务看到的是「可用余额」，不会把同一笔钱花两次。

6.6.4 Saga：没有原子性，只有补偿

Saga 把长事务拆成一串本地事务 T1, T2, ..., Tn，每个 Ti 都有一个补偿动作 Ci。如果 Tk 失败，就按相反顺序执行 Ck-1, ..., C1：

正向：  T1 ──▶ T2 ──▶ T3 ──▶ T4
                              │
                              └─ T4 失败
                                     │
补偿：  C1 ◀── C2 ◀── C3 ◀──────────┘
        （执行顺序：C3 → C2 → C1）

Saga 的保证是「最终一致」，不是「原子」。它有四个必须承认的事实：

1. 中间状态对外可见：T1 创建了订单、T2 还没扣款时，别的请求能看到这个订单。要用业务状态（PENDING/RESERVED）把它标出来，让其他操作知道「还没完成」。
2. 补偿不是回滚：退款不是「撤销扣款」，而是一笔新的正向交易；它可能失败、可能被风控拦截、可能产生手续费。补偿动作必须幂等，并且要能重试。
3. 没有隔离：另一个事务可能读到中间状态并据此做决定。工程上用「语义锁」（semantic lock）来处理：在业务层标记「这个实体正在事务中」，其他事务要么等待，要么拒绝。
4. 补偿也可能失败：C3 失败时，需要有重试、死信、人工介入。Saga 的尽头往往是一张对账工单，这不是耻辱，而是设计的一部分。

6.6.5 怎么选

选型时先回答三个问题：

1. 这个操作能不能接受「中间状态被看到」？ 不能，就别用 Saga；考虑 2PC 或把数据放到一个库里。
2. 参与方能不能长时间持锁？ 不能，就别用 2PC；考虑 TCC 或 Saga。
3. 补偿失败时，业务能不能人工介入？ 不能，就别把 Saga 当成「自动回滚」；要么把不变量收敛到单库，要么设计更强的预留。

6.7 Outbox 与幂等消费

很多团队第一次遇到「双写」问题时，会写这样的代码：

BEGIN;
INSERT INTO orders (...) VALUES (...);
COMMIT;
publish("order.created", order_id);   -- 进程在这里崩溃，消息永远发不出去

数据库提交了，消息没发，下游永远不知道有这个订单。把顺序反过来，又会出现另一种错误：

publish("order.created", order_id);   -- 消息先发出去
BEGIN;
INSERT INTO orders (...) VALUES (...);
ROLLBACK;                              -- 插入失败，下游看到了一个不存在的订单

问题的本质是：数据库事务和消息发送是两个系统，没有一个本地事务能同时包住它们。2PC 可以包，但代价高；更常用的做法是 Outbox：把「要发的消息」写进业务库的同一张表、同一个事务，然后由另一个进程把 outbox 里的记录搬到消息队列。

6.7.1 Outbox 表

CREATE TABLE outbox (
  id           BIGSERIAL   PRIMARY KEY,
  aggregate_id TEXT        NOT NULL,
  event_type   TEXT        NOT NULL,
  payload      JSONB       NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
  published_at TIMESTAMPTZ
);

CREATE INDEX outbox_pending ON outbox (id) WHERE published_at IS NULL;

业务事务变成：

BEGIN;
INSERT INTO orders (id, user_id, amount) VALUES ('o-1', 'u-1', 100);
INSERT INTO outbox (aggregate_id, event_type, payload)
VALUES ('o-1', 'order.created', '{"order_id":"o-1","amount":100}');
COMMIT;

两条插入在同一个本地事务里：要么都在，要么都不在。不会出现「订单在、消息不在」；也不会出现「消息在、订单不在」。Outbox 把分布式双写问题降级成了本地事务问题，这是它唯一但足够重要的价值。

6.7.2 Relay：至少一次地搬

一个最小的 relay 循环：

def relay_once(conn, publish, batch: int = 100) -> int:
    with conn.transaction():
        rows = conn.execute(
            "SELECT id, aggregate_id, event_type, payload "
            "FROM outbox WHERE published_at IS NULL "
            "ORDER BY id LIMIT %s FOR UPDATE SKIP LOCKED",
            (batch,),
        ).fetchall()
        for row in rows:
            publish(row)  # 可能成功、可能超时；下游必须能去重
            conn.execute(
                "UPDATE outbox SET published_at = now() WHERE id = %s",
                (row["id"],),
            )
        return len(rows)

这段代码有几个取舍：

• FOR UPDATE SKIP LOCKED 让多个 relay 实例可以并行处理，而不会互相阻塞；每个实例拿到不同的行。
• ORDER BY id 保证同一批内的顺序；跨实例的全局顺序不保证，所以消息的消费端要能处理乱序，或者按 aggregate_id 分区。
• publish 在事务里，如果 publish 成功但事务提交失败，消息会重发；如果 publish 超时但实际成功，也会重发。这就是至少一次，下游必须按事件 ID 去重。
• 生产上通常会把「claim 一批、提交、再 publish、再标记」拆开，避免网络调用把数据库事务拉长；代价是状态机多一个 locked_until 字段。

6.7.3 消费端：去重表与业务写入在同一个事务里

至少一次投递意味着消费端一定会遇到重复。去重的关键不是「记住所有见过的 ID」，而是「把去重记录和业务效果放在同一个事务里」：

CREATE TABLE processed_events (
  consumer     TEXT        NOT NULL,
  event_id     UUID        NOT NULL,
  processed_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (consumer, event_id)
);

def handle_event(conn, event) -> None:
    with conn.transaction():
        inserted = conn.execute(
            "INSERT INTO processed_events (consumer, event_id) "
            "VALUES (%s, %s) ON CONFLICT DO NOTHING RETURNING event_id",
            ("billing", event["id"]),
        ).fetchone()
        if inserted is None:
            return  # 已经处理过，直接跳过
        conn.execute(
            "UPDATE accounts SET balance = balance + %s WHERE id = %s",
            (event["amount"], event["account_id"]),
        )

如果「插入去重记录」成功、「更新余额」失败，整个事务回滚，事件会被重新投递；如果两者都成功，事务提交，重复投递会被 ON CONFLICT 挡住。这里没有「先查再插」的竞态，因为唯一约束和业务写入在同一个事务里。

去重表会一直增长，需要按时间分区或定期清理。清理的保留窗口要大于「消息的最长重投递时间」，否则一个延迟很久的重投会被当成新事件。

6.7.4 Outbox、CDC 与本地消息表

CDC 不是「没有重复」：它读的是数据库日志，日志里的每一次变更都会被投递一次；如果消费端提交 offset 失败，或者 relay 重启，仍然会重放。CDC 只是把「写 outbox 表」换成了「读数据库日志」，至少一次的语义没有变。

6.8 失败模式：重试把一次转账做成两次

把前面几节拼起来，就得到本章最重要的一个失败模式。服务端代码如下，看起来没有任何问题：

def transfer(conn, from_acct: str, to_acct: str, amount: int) -> None:
    with conn.transaction():
        conn.execute(
            "UPDATE accounts SET balance = balance - %s WHERE id = %s",
            (amount, from_acct),
        )
        conn.execute(
            "UPDATE accounts SET balance = balance + %s WHERE id = %s",
            (amount, to_acct),
        )
        conn.execute(
            "INSERT INTO transfers (from_acct, to_acct, amount) VALUES (%s, %s, %s)",
            (from_acct, to_acct, amount),
        )

事务是原子的，两条 UPDATE 和一条 INSERT 要么全做、要么全不做。数据库层面没有任何约束被违反。但客户端调用的是 POST /transfer，请求里没有幂等键；SDK 在 1 秒超时后自动重试一次。

这个事故的根因不在数据库，也不在重试策略本身，而在两个边界的错位：

• 数据库的事务边界是 BEGIN ... COMMIT，它保证「这一次尝试」内部不撕裂；
• 用户意图的边界是「A 向 B 转 100 元」，它应该只生效一次；
• 重试产生了一次新的尝试，服务端为它开了一个新事务；数据库没有任何信息能判断「这和刚才那笔是同一个意图」。

事务是幂等的敌人吗？不是。事务根本不知道「意图」存在。 它只看见语句。没有幂等键，服务端就无法把第二次尝试归并到第一次；两次尝试各自都是合法事务，合起来就是重复副作用。

6.8.1 两种更隐蔽的变体

上面是最直观的「响应丢失 + 客户端重试」。还有两种变体，往往更难发现：

变体一：服务端内部重试死锁事务。 6.5 的重试封装会把整个事务再执行一遍。如果事务里只有数据库操作，重试是安全的；但如果事务里还调用了外部服务（扣款网关、发券、发短信），回滚不会撤销外部副作用：

with conn.transaction():
    conn.execute("UPDATE accounts SET balance = balance - 100 WHERE id = 'A'")
    gateway.charge(customer_id, 100)   # 外部副作用：事务回滚不会退款
    conn.execute("INSERT INTO transfers ...")

第一次执行到 gateway.charge 后发生死锁，事务回滚，重试再次 charge。数据库里可能只有一条 transfer，网关却扣了两次。事务边界只能包住数据库，包不住网络调用。

变体二：提交成功后抛异常。 服务端 COMMIT 成功，然后在序列化响应、写日志、发消息时抛异常；上层捕获异常后重试。数据库已经提交，重试会再执行一次。这类 bug 在「提交后还有一段代码」的实现里很常见。

6.8.2 修复：让「意图」在数据库里留下痕迹

修复的核心不是「别重试」，而是「让重试可以被识别」。最小方案是客户端生成请求 ID，服务端在同一个事务里先插入这个 ID，用唯一约束做闸门：

CREATE TABLE transfers (
  id          BIGSERIAL   PRIMARY KEY,
  request_id  UUID        NOT NULL UNIQUE,
  from_acct   TEXT        NOT NULL,
  to_acct     TEXT        NOT NULL,
  amount      NUMERIC     NOT NULL,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

BEGIN;
INSERT INTO transfers (request_id, from_acct, to_acct, amount)
VALUES ('6f1c2a9e-8d1b-4f3a-9c2e-2b7d5a0c1e44', 'A', 'B', 100)
ON CONFLICT (request_id) DO NOTHING
RETURNING id;
-- 如果没有返回行，说明这个 request_id 已经处理过：
-- 查出原记录，直接返回原结果，不再扣款
-- 只有上面返回了行（首次请求）才执行下面两条：
UPDATE accounts SET balance = balance - 100 WHERE id = 'A';
UPDATE accounts SET balance = balance + 100 WHERE id = 'B';
COMMIT;

注意这里的顺序：先插入幂等记录，再做副作用。如果反过来（先扣款再插入），第二次重试会在扣款之后才撞上唯一约束，扣款已经发生，事务虽然会回滚，但如果中间还有外部调用就来不及了。

如果 INSERT ... ON CONFLICT DO NOTHING 没有返回行，应用必须查原记录并返回原结果，而不是继续执行后面的 UPDATE。这一步经常被漏掉：约束挡住了重复插入，代码却继续扣款，等于白做。

6.8.3 唯一约束挡不住的部分

唯一约束能挡住「同一张表插两条」，但挡不住下面这些：

• 外部副作用：扣款网关、发券、发短信不在数据库里，唯一约束管不到；
• 跨表/跨服务的效果：A 库的 transfers 唯一了，B 库的 ledger 可能还有一条；
• 异步链路：事务提交后通过 outbox 发消息，消息重发会让下游再执行一次。

所以完整的修复通常是三层：

6.9 观测：pg_stat_activity、pg_locks 与 InnoDB status

事务出问题时，第一现场通常不是错误日志，而是「现在谁在等谁」。PostgreSQL 的 pg_stat_activity 和 pg_locks、MySQL 的 information_schema.innodb_trx 和 SHOW ENGINE INNODB STATUS，能回答三个问题：有没有长事务？谁在等锁？回滚和死锁是不是在变多？

6.9.1 一条命令看长事务与锁等待

psql "$PGDSN" -x -c "
SELECT pid, usename, state,
       now() - xact_start AS xact_age,
       now() - query_start AS query_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blockers,
       left(query, 60) AS query
FROM pg_stat_activity
WHERE datname = current_database()
ORDER BY xact_age DESC NULLS LAST
LIMIT 8;"

一次本机测试的输出（节选）：

-[ RECORD 1 ]--+--------------------------------------------
pid            | 48213
usename        | app
state          | idle in transaction
xact_age       | 00:12:41.238
query_age      | 00:12:41.236
wait_event_type| Client
wait_event     | ClientRead
blockers       | {}
query          | UPDATE accounts SET balance = balance - 100 ...

-[ RECORD 2 ]--+--------------------------------------------
pid            | 48290
usename        | app
state          | active
xact_age       | 00:01:07.512
query_age      | 00:01:07.510
wait_event_type| Lock
wait_event     | transactionid
blockers       | {48213}
query          | UPDATE accounts SET balance = balance + 100 ...

怎么读：

最关键的一条：不要从被阻塞的 PID 开始优化，要顺着 blockers 找到根。一条 UPDATE 等了 60 秒，可能只是因为另一个连接 12 分钟前开了事务、再也没提交。

6.9.2 锁等待与回滚率

找到根之后，用 pg_locks 确认锁的类型和对象：

psql "$PGDSN" -c "
SELECT l.pid, l.locktype, l.mode, l.granted, c.relname
FROM pg_locks l
LEFT JOIN pg_class c ON c.oid = l.relation
WHERE NOT l.granted
   OR l.pid IN (SELECT pid FROM pg_stat_activity
                WHERE cardinality(pg_blocking_pids(pid)) > 0)
ORDER BY l.pid;"

再看回滚率和死锁。这两个指标是累计值，单次采样没有意义，要看趋势或增量：

psql "$PGDSN" -c "
SELECT xact_commit, xact_rollback, deadlocks,
       round(100.0 * xact_rollback
             / nullif(xact_commit + xact_rollback, 0), 2) AS rollback_pct
FROM pg_stat_database
WHERE datname = current_database();"

 xact_commit | xact_rollback | deadlocks | rollback_pct
-------------+---------------+-----------+--------------
     1842301 |         41207 |        17 |         2.19

读法：

• rollback_pct 在 OLTP 系统里通常应低于 1%。2.19% 说明每 50 个事务就有一个回滚，可能是业务校验失败、唯一键冲突，也可能是序列化失败重试。
• deadlocks 是累计值。17 次本身不可怕，可怕的是单位时间内持续增长；把采样时间点记下来，算增量。
• 回滚率高不一定是坏事：如果都是「重复请求撞唯一键」，说明幂等闸门在工作；如果都是 40001/40P01，说明并发冲突或加锁顺序有问题。

6.9.3 InnoDB：History list length 与活跃事务

MySQL 侧看两张东西：information_schema.innodb_trx 里的活跃事务，和 SHOW ENGINE INNODB STATUS 里的 History list length。

mysql -N -e "SELECT trx_id, trx_state,
  TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age_s,
  trx_rows_locked, trx_rows_modified,
  LEFT(trx_query, 60) AS query
FROM information_schema.innodb_trx
ORDER BY trx_started LIMIT 5;"

mysql -e "SHOW ENGINE INNODB STATUS\G" | sed -n '/TRANSACTIONS/,/FILE I\/O/p'

4218842  RUNNING  128  3  1  UPDATE accounts SET balance = balance - 100 ...

------------
TRANSACTIONS
------------
Trx id counter 4218850
Purge done for trx's n:o < 4218831 undo n:o < 0 state: running
History list length 1823411
---TRANSACTION 4218842, ACTIVE 128 sec
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1

读法：

6.10 真实案例：Spanner 的 TrueTime 与 2PC

2012 年，Google 在 OSDI 发表了 Spanner 的论文，描述一个全球分布、外部一致（externally consistent）的数据库。它经常被引用成「全球强一致可以做到」，但论文真正有意思的地方不是「强一致」，而是它如何把「时间不确定」变成「等一会儿」，以及 2PC 在这个架构里到底承担了什么。

6.10.1 TrueTime：把现在表示成一个区间

普通机器上的 now() 返回一个时间点，但这个点可能有几毫秒到几秒的误差。Spanner 的 TrueTime API 不返回点，而返回一个区间：

TT.now() = [earliest, latest]
ε = latest - earliest

TrueTime 由 GPS 接收器和原子钟支撑，Google 的数据中心里 ε 通常在 7 ms 以内（论文给出的典型值）。TT.after(t) 和 TT.before(t) 不是「大概」，而是「在 ε 的假设下，确定 t 已经过去/还没到」。

拿到区间之后，Spanner 给读写事务分配提交时间戳 s = TT.now().latest，然后等到 TT.after(s) 为真才真正提交。这段等待叫 commit-wait，长度大约是 2ε：

TT.now() = [e, l],  ε = l - e
             e          l
真实时间 ────┼──────────┼────────▶
             │          │
             │    选 s = l
             │          │
             │◀─────────┼────▶ 等待 TT.after(s)，约 2ε
                        │
                     commit @ s

为什么这样能保证外部一致性？因为任何在 s 之后开始的事务，拿到的时间戳一定大于 s；任何在 s 之前提交的事务，时间戳一定小于 s。commit-wait 把「时钟可能不准」换成了「等足够久，久到不确定性已经过去」。代价是每次写多等约 2ε；ε 变大，写延迟就变大。

6.10.2 2PC 在 Spanner 里的位置

Spanner 的数据按 tablet 分片，每个分片是一个 Paxos 复制组。跨分片的事务用 2PC：

这里有两级协议：组内 Paxos，组间 2PC。2PC 的协调者本身也要高可用，否则它一崩，所有 in-doubt 的跨组事务都卡住；Spanner 把协调者状态也复制起来。只读事务不参与 2PC，它们在一个选定的时间戳上读快照，因此不需要锁，也不会阻塞写。

这个组合说明：2PC 不是「分布式事务的银弹」，它只是原子提交的一层。没有 Paxos，协调者和参与者都可能丢状态；没有 TrueTime，跨地域的事务无法给出外部一致的时间顺序；有了这两者，还要付出 commit-wait 和跨地域 RTT 的代价。

6.10.3 失败链与教训

Spanner 不是「不会坏」，它的设计把失败从「数据不一致」转移到了「延迟上升/不可用」：

• ε 变大：GPS 信号受干扰、时钟漂移，TrueTime 的不确定性上升；commit-wait 变长，写延迟上升，上层超时和重试增多。
• 协调者故障：跨组 2PC 的 in-doubt 事务要等协调者恢复；协调者用 Paxos 复制来缩短这个窗口，但不能消除。
• 跨地域网络抖动：组内 Paxos 和组间 2PC 都要 RTT；跨大洋的写延迟是物理距离决定的，不是软件能优化的。
• 只读副本落后：快照读不阻塞，但读到的可能是旧时间点；需要「读最新」时，仍要选足够新的时间戳。

五条可以带走的教训：

1. 原子提交和一致性是两件事：2PC 解决「一起提交」，TrueTime 解决「时间顺序」，缺一不可。
2. 不确定性可以被等待消除：commit-wait 的本质是用延迟换确定性；这个交易在很多系统里都成立。
3. 协调者必须高可用：2PC 的单点不是理论问题，是值班时真会遇到的阻塞。
4. 只读路径可以绕过 2PC：快照读是 Spanner 性能的关键；写路径的代价不能套到读上。
5. 不是所有系统都能复制这套方案：它依赖 GPS/原子钟、受控的数据中心网络、专门的运维；普通云上多租户应用很难假设 ε 有界。

6.11 重试导致重复副作用：非幂等 INSERT 的重放

6.8 讲的是「转账服务没有幂等键」。这一节把镜头再拉近一点：即使事务本身没问题，一条非幂等的 INSERT 被重放，也会产生两条记录。它的可怕之处在于「没有任何错误」：两次插入都成功，数据库不报错，只有对账时才发现多了。

6.11.1 一条没有唯一键的流水表

CREATE TABLE ledger (
  id         BIGSERIAL   PRIMARY KEY,
  account_id TEXT        NOT NULL,
  amount     NUMERIC     NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- 每次重试都执行一次；id 是新生成的，数据库没有任何理由拒绝
INSERT INTO ledger (account_id, amount) VALUES ('A', -100);

重放可能来自四个地方：

它们的共同点是：重放的是「动作」，不是「结果」。如果动作是 INSERT，重放就多一行；如果动作是 UPDATE balance = 100（绝对值），重放可能无害；如果动作是 UPDATE balance = balance - 100（增量），重放就多扣一次。

6.11.2 修复：唯一键 + 原子 upsert

给流水表加一个客户端生成的 request_id，并让它唯一：

CREATE TABLE ledger (
  id          BIGSERIAL   PRIMARY KEY,
  request_id  UUID        NOT NULL UNIQUE,
  account_id  TEXT        NOT NULL,
  amount      NUMERIC     NOT NULL,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

写入用「原子 upsert」，保证无论重放多少次，都返回同一行的 id：

INSERT INTO ledger (request_id, account_id, amount)
VALUES ('6f1c2a9e-8d1b-4f3a-9c2e-2b7d5a0c1e44', 'A', -100)
ON CONFLICT (request_id)
DO UPDATE SET request_id = EXCLUDED.request_id
RETURNING id;

为什么用 DO UPDATE 而不是 DO NOTHING？因为 DO NOTHING 在冲突时不返回行，应用还得再查一次；而「插入」和「查询」之间可能有并发窗口。DO UPDATE SET request_id = EXCLUDED.request_id 是一个空更新，但它会锁住冲突行并 RETURNING 原 id，让「插入或取回」变成一次原子操作。代价是会多产生一个行版本（PostgreSQL）或一次 undo（InnoDB），对流水表通常可以接受；如果写入量极大，可以用 DO NOTHING + 重查，但要处理好「查不到」的竞态。

对应的 Python：

def append_ledger(conn, request_id: str, account_id: str, amount: int) -> int:
    row = conn.execute(
        "INSERT INTO ledger (request_id, account_id, amount) "
        "VALUES (%s, %s, %s) "
        "ON CONFLICT (request_id) DO UPDATE "
        "SET request_id = EXCLUDED.request_id "
        "RETURNING id",
        (request_id, account_id, amount),
    ).fetchone()
    return row["id"]

这段代码只解决「同一 request_id 不重复」。它不解决：

• 客户端换了 request_id（用户点了两次，或 SDK 每次重试都生成新键）；
• 副作用发生在另一张表/另一个服务（6.8 的三层修复）；
• 消费端重复处理同一条消息（需要 6.7 的 processed_events）。

6.11.3 对账：发现已经发生的重复

唯一约束只能防未来，不能修历史。上线修复之后，通常要跑一次对账，找出已经重复的流水：

SELECT account_id, amount,
       date_trunc('second', created_at) AS second,
       count(*) AS n
FROM ledger
GROUP BY 1, 2, 3
HAVING count(*) > 1
ORDER BY n DESC
LIMIT 50;

这个结果是候选集，不是判决书：同一秒内的同额流水可能真是两笔。确认重复后用冲正流水抵消，不要物理删除，否则审计链和「余额 = 流水之和」都会断。

6.12 事务边界设计清单

把前面所有讨论压缩成一张表。每设计一个写路径，从上到下过一遍；答不上来的那一条，就是下一次事故的入口。

这张表里最容易被跳过的是第 1 项和第 9 项。前者决定事务会不会变成「长事务 + 锁等待」，后者决定重试会不会变成「重复扣款」。先画边界，再写代码；边界画错，后面每一条都在给错误打补丁。

6.13 本章陷阱清单

6.14 本章出口检查

母本对应

这一章没有对应的母本章节：谢希仁和张彦飞都不讲事务隔离、MVCC 和 2PC。本书自编的部分集中在「机制 → 失败窗口 → 观测命令」这条链上；定义和协议事实来自数据库教材与论文，代码和事故场景是按工程实践重写的，不复制原文。

下一站：事务解决的是「一次操作要么全做、要么全不做」，但仍有很多事需要「先记下来、稍后处理」。进入 7 队列、流与事件驱动，看至少一次投递、offset 提交与消费者组如何接住本章留下的 outbox 和重复消息。