PostgreSQL并发控制：为何金融系统必须用悲观锁

在高并发金融系统中，数据库并发控制是最关键的工程挑战之一。当数千个请求同时修改账户余额、执行账本分录或转账时，数据库必须保证绝对的 consistency、isolation 和 durability。缺少健壮的并发控制，并行事务直接导致数据损坏、双重支付漏洞和无法对账的财务审计。

本文基于一份深度技术分析，探讨 PostgreSQL 如何处理事务隔离级别，为什么乐观方法在高容量金融管道中频繁失败，以及 SELECT ... FOR UPDATE 如何成为金融系统的非可选方案。

金融系统中的并发异常剖析

在单线程环境中，状态转换严格顺序执行：事务 A 完全完成后事务 B 才开始。但现代金融后端高度并行，运行在连接池、微服务和多核数据库引擎之上。这种并行性引入了 ANSI SQL-92 标准定义的异常：脏读、不可重复读、幻读和丢失更新。

对金融账本而言，最灾难性的异常是丢失更新。假设账户 1001 余额为 1,000.00 美元，两个独立支付请求并发到达：

1. 事务 A 尝试入账 200.00 美元
2. 事务 B 尝试借记 50.00 美元

理论上，无论哪个事务先提交，最终余额都应为 1,150.00 美元。然而，如果在宽松隔离级别下两个事务并发执行且无显式并发控制，事务会相互覆盖计算结果，最终余额被错误记录。事务 A 的 200.00 美元入账被事务 B 完全覆盖而丢失。在金融系统中，这意味着资金丢失——违反价值守恒，必然导致日终对账失败并触发监管处罚。

PostgreSQL 默认的 Read Committed 隔离级别只能防止脏读，不能防止多个并发事务读取同一行并基于该读取发出非原子更新时发生的丢失更新或不可重复读。

ANSI SQL-92 隔离级别标准定义了四个层级：Read Uncommitted、Read Committed、Repeatable Read 和 Serializable，分别对应可容忍的并发异常范围。PostgreSQL 实现了其中四级，但默认使用 Read Committed，其语义是每个语句只能看到该语句开始前已提交的数据。PostgreSQL 的 Repeatable Read 实际提供的是快照隔离（Snapshot Isolation），能防止不可重复读和幻读，但标准并未要求它检测所有写偏斜（Write Skew）模式。真正的 Serializable 级别通过 SSI（Serializable Snapshot Isolation）实现，会主动检测可能导致非串行化结果的读写依赖环并中止事务。金融系统选择隔离级别时，需要在安全性与重试成本之间权衡：Serializable 最安全但失败率最高，而 Read Committed 若不配合显式行锁，在账本场景下几乎必然产生丢失更新。

从Web开发视角理解数据库并发

将 PostgreSQL 并发控制映射到现代 Web 开发中的状态同步问题，有助于建立直观理解。想象一个协作文档编辑应用，多个用户同时编辑共享配置文件。

在**乐观并发控制（OCC）**模型中，每个客户端读取当前版本（版本 1），本地编辑而不锁定服务器资源。点击保存时，客户端发送更新及期望的基础版本号。若其他用户稍早保存，数据库版本变为 2，更新语句匹配零行，事务回滚，应用抛出冲突错误："其他人已更新此文档，请刷新重试。"

OCC 对内容管理系统、Wiki 和社交媒体信息流效果极佳，因为写冲突罕见且可由人类用户轻松重试。但对高频金融支付管道却是灾难性的：如果每秒处理数千笔交易的支付网关纯粹依赖 OCC，争用率将飙升。数百个并发支付线程尝试更新同一商户余额行，版本检查失败，抛出并发异常，触发级联重试，饱和 CPU 和数据库连接池。

相反，悲观并发控制（PCC）——以 PostgreSQL 的 SELECT ... FOR UPDATE 为代表——更像异步 Node.js 应用关键区上的排他写锁或同步的 Server-Sent Events 广播通道。PostgreSQL 在存储引擎内通过行级锁实现互斥。当事务对特定账户行发出 SELECT ... FOR UPDATE 查询时，数据库引擎在缓冲池内获取该物理元组的排他锁。任何其他并发事务尝试以冲突锁读取同一行（或尝试更新它）都会被强制暂停，挂起执行直到第一个事务提交或回滚释放锁。

SELECT ... FOR UPDATE 的工作机制

标准 SELECT 查询运行时不在读取的数据行上获取锁，它依赖多版本并发控制（MVCC）。MVCC 通过维护元组的多个物理版本，让读者不阻塞写者、写者不阻塞读者。每个行元组包含隐藏系统列，特别是 xmin（创建版本的事务 ID）和 xmax（删除或取代版本的事务 ID）。读者读取其事务开始时间有效的快照，忽略未提交或更新的版本。

然而，MVCC 快照是只读视图。如果事务 A 通过标准 SELECT 读取一行，它捕获快照；如果事务 B 随后修改并提交该行，事务 A 的快照保持不变。若事务 A 基于早先读取的数据尝试 UPDATE，除非调用显式锁定机制，否则会直接落入丢失更新异常陷阱。

当事务执行包含 FOR UPDATE 子句的查询时，PostgreSQL 做两件事：

1. 读取该行的最新已提交版本，绕过 MVCC 快照隔离规则，确保操作绝对最新的状态
2. 对查询找到的每个匹配物理行获取排他锁

PostgreSQL 在共享内存中维护锁管理器。获取行锁时，锁表中放置一个条目，标识关系、块号和特定元组偏移。如果第二个并发事务尝试对同一行运行 SELECT ... FOR UPDATE 或 UPDATE/DELETE，锁管理器检查锁表，检测冲突，将第二个事务的后端进程休眠。操作系统内核使用信号量或条件变量挂起 PostgreSQL 后端进程，等待时消耗零 CPU 周期。

支付管道中悲观事务的生命周期

考虑高可靠性支付管道处理账户 A（借记）和账户 B（贷记）之间的账本转账。为确保绝对原子性并防止竞态条件，执行流必须遵循严格序列：

1. 事务初始化：打开新数据库连接，发出 BEGIN;
2. 确定性排序（死锁预防）：为防多行死锁，始终按全局确定性顺序获取锁（如按账户主键 ID 升序排序）
3. 悲观读取：发出 SELECT id, balance, currency FROM accounts WHERE id IN (1001, 1002) ORDER BY id ASC FOR UPDATE;
4. 应用层不变量验证：在 TypeScript 运行时检查锁定行，验证账户 1001 有足够资金、货币兼容、账户状态标志
5. 账本变更：原子执行复式记账凭证创建和余额更新
6. 提交或回滚：发出 COMMIT;，将预写日志刷新到磁盘并释放事务持有的所有行锁，立即唤醒等待的后端进程

**多版本并发控制（MVCC）**是 PostgreSQL 实现读写不互相阻塞的核心机制。每当一行被更新或删除，原元组不会被原地覆盖，而是标记 xmax 为当前事务 ID 并生成一个新版本，由 xmin 标记新事务 ID。旧版本在不再被任何活跃事务快照引用之前，会被 VACUUM 进程回收。这种设计让每个事务拥有一个一致的时间点快照，读操作无需加共享锁。但代价是表膨胀与清理开销：长事务会阻止旧版本回收，导致磁盘膨胀。此外，MVCC 快照只保证读一致性，并不阻止其他事务基于旧快照做更新。这正是 FOR UPDATE 存在的原因——它强制读取最新已提交版本并加排他锁，使 MVCC 的快照隔离在写路径上被显式锁定所覆盖。

架构权衡：悲观锁 vs 乐观并发

在悲观锁（SELECT ... FOR UPDATE）和乐观并发控制之间选择，是金融系统工程师最重要的架构决策之一。两种方法都呈现严重的工程权衡，决定系统可扩展性、延迟和吞吐量。

悲观锁（SELECT ... FOR UPDATE）

优势：

• 绝对安全：通过序列化对争议行的访问，完全消除丢失更新和竞态条件
• 可预测执行：获取锁的事务继续完成，不会因并发修改冲突而失败
• 高争用热点理想选择：对经历巨大并发流量的特定金融账户至关重要

劣势：

• 吞吐量降低：序列化对特定行的并发访问，事务排队，整体延迟增加
• 连接池耗尽：后端工作进程等待锁时休眠，连接池在高负载下饱和，导致应用级超时
• 死锁脆弱性：多行操作引入持续死锁风险，需要复杂重试逻辑和严格锁排序协议

乐观并发控制（OCC）

优势：

• 零锁开销：读者从不阻塞写者，事务读取阶段无需获取锁
• 低争用数据最大吞吐：并发操作针对不同行或非共享资源时高效

劣势：

• 高争用下高失败率：应用于金融热点时，99% 事务版本检查失败，引发重试风暴
• 复杂应用逻辑：需要显式版本列、重试包装器和幂等事务设计

死锁：悲观锁的必然代价

采用悲观并发控制时，工程师不可避免遇到死锁。死锁发生在两个或更多事务各持有对方所需锁，形成无法自行解决的循环依赖。

PostgreSQL 运行后台死锁检测线程，定期检查锁等待图。检测到循环（事务 1 等待事务 2，事务 2 等待事务 1）时介入，选择其中一个事务（通常是回滚成本最低的）通过抛出 40P01（Deadlock Detected）SQLSTATE 异常中止，强制回滚释放锁，让另一事务继续。

TypeScript 金融管道中的死锁缓解

由于死锁在悲观架构规模化时是数学必然，Node.js/TypeScript 应用代码不能将死锁错误视为致命崩溃。相反，死锁必须作为瞬态操作状态处理，需要指数退避和抖动的自动重试。

此外，架构设计模式必须强制严格的全局资源排序。如果支付管道中每个服务都编程为始终按账户 ID 升序锁定，循环等待条件在结构上变得不可能。

死锁的四个必要条件由 Coffman 于 1971 年形式化：互斥、持有并等待、不可抢占和循环等待。只要这四个条件同时成立，死锁就不可避免。在数据库层面，互斥由行锁天然满足，持有并等待由事务的原子性满足，不可抢占意味着锁只能由持有者释放。唯一可由应用层影响的环节是循环等待——通过强制全局资源排序，可以让循环等待在结构上无法形成。PostgreSQL 的死锁检测线程默认每 deadlock_timeout（1 秒）唤醒一次检查锁等待图，检测到环后选择成本最小的事务中止并返回 40P01。然而检测需要时间，因此最佳实践仍是预防：对多行操作按主键排序加锁、缩短事务持锁时间、将大事务拆分为可重试的小步骤。

生产环境常见陷阱

在异步 Node.js 和 TypeScript 环境中实现悲观锁定引入几个微妙失败模式：

1. 未处理异常导致连接泄漏：错误发生在 pool.connect() 和 client.release() 之间且未正确捕获时，客户端永不返回池。修复：始终在健壮的 try...finally 块中包装事务逻辑。
2. 锁排序不一致导致死锁：两个事务以不同顺序获取多行锁时。修复：获取多锁时始终强制执行严格全局排序约定。
3. 锁争用期间 HTTP 超时耗尽：SELECT ... FOR UPDATE 等待时挂起执行，单行高争用导致请求排队。修复：避免在高争用单行计数器上悲观锁定，或实现激进队列架构。
4. 混合 pool.query() 与事务：await pool.query('BEGIN') 后跟 await pool.query('SELECT ... FOR UPDATE') 每次调用借用释放新客户端，破坏事务隔离。修复：始终用 const client = await pool.connect() 检出专用客户端实例。

连接池与事务边界的不匹配是 Node.js 生态中最隐蔽的并发陷阱。pg 库的 Pool 对象在每次 pool.query() 调用时从池中借出一个客户端，执行完立即归还。这意味着连续两次 pool.query() 很可能落在不同的物理连接上，BEGIN 和后续 SELECT ... FOR UPDATE 不在同一会话中，行锁根本不会作用于预期事务，甚至不会报错。正确做法是从池中显式检出 PoolClient，在其上执行所有事务语句，最后在 finally 中调用 release()。若客户端因异常未释放，池会逐渐耗尽并表现为应用级超时，而非显式的连接错误，排查难度显著上升。

结论：严格并发的哲学

使用悲观锁和 SELECT ... FOR UPDATE 的 PostgreSQL 并发控制不仅是数据库优化技术，更是金融软件工程的基石。通过理解 MVCC 存储引擎、锁管理器和事务隔离级别的底层物理原理，工程师可以设计承受巨大吞吐量而不牺牲一分钱账本完整性的系统。

随着金融架构跨分布式微服务和异步 Node.js 运行时扩展，掌握悲观执行边界、确定性锁排序和弹性死锁恢复，确保账本对并发异常坚不可摧。