2. PostgreSQL事务基础

事务（Transaction）是数据库系统中保证数据一致性与完整性的核心机制。在支付订单场景中，每一笔资金流转都必须严格遵循事务的 ACID 特性，否则将导致账务不平、重复扣款或数据丢失等严重事故。本节将深入剖析 ACID 的四个维度，并详细讲解 PostgreSQL 中事务控制的基本语法。

2.1 ACID 特性详解

ACID 是数据库事务正确执行的四个基本要素的缩写，由 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性） 和 Durability（持久性） 组成。下表对比了各特性的核心含义及其在支付场景中的典型体现：

特性 定义 支付订单场景示例
原子性 (Atomicity) 事务中的所有操作要么全部成功提交，要么全部失败回滚，不存在中间状态。 扣减用户余额与创建支付订单必须同时成功或同时失败；不允许出现扣款成功但订单未生成的情况。
一致性 (Consistency) 事务执行前后，数据库必须从一个一致状态转换到另一个一致状态，所有数据约束（主键、外键、唯一索引、检查约束）均被满足。 支付完成后，账户余额 + 冻结金额 = 总资产；订单状态只能从“待支付”变为“已支付”或“已取消”，不能出现非法状态。
隔离性 (Isolation) 并发执行的事务之间互不干扰，每个事务都感觉不到其他事务的并发执行。 用户 A 同时发起两笔支付，两笔事务的余额扣减操作必须通过隔离级别（如可重复读）防止相互覆盖或读取到未提交的脏数据。
持久性 (Durability) 一旦事务提交成功，其对数据库的修改就是永久性的，即使系统崩溃也不会丢失。 支付成功的确认记录必须写入 WAL（Write-Ahead Log）并落盘，确保断电后订单状态和余额数据不丢失。
关键认知： 在支付中间件设计中，原子性和持久性通常由数据库底层 WAL 机制保障；一致性依赖业务逻辑中的约束与触发器；隔离性则通过选择合适的隔离级别（如 READ COMMITTED 或 REPEATABLE READ）来控制并发冲突。

2.2 事务控制语法：BEGIN / COMMIT / ROLLBACK

PostgreSQL 使用 BEGIN 显式开启一个事务块，使用 COMMIT 提交事务使更改永久生效，使用 ROLLBACK 回滚事务撤销所有未提交的更改。以下为基本语法结构：

-- 开启事务
BEGIN;

-- 执行一系列 DML 操作
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1001;
INSERT INTO payment_orders (order_id, user_id, amount, status)
VALUES ('PO20250301001', 1001, 100, 'SUCCESS');

-- 判断业务逻辑：如果上述操作成功，则提交
COMMIT;

-- 如果出现异常（如余额不足），则回滚
-- ROLLBACK;

2.3 事务生命周期与状态转换

一个事务从开始到结束会经历多个状态。下面的 SVG 图展示了 PostgreSQL 事务的完整生命周期，包括显式控制与隐式自动提交的路径：

PostgreSQL 事务生命周期与状态转换 空闲（隐式自动提交） 显式事务块 执行 DML 操作 COMMIT（持久化） ROLLBACK（撤销） 异常终止（自动回滚） BEGIN 操作成功 业务判断回滚 系统异常/约束冲突 返回空闲 返回空闲 自动回滚
实践要点： 在支付订单接入中，建议始终使用 显式事务块（BEGIN + COMMIT/ROLLBACK），避免依赖 PostgreSQL 默认的隐式自动提交模式。显式事务可以让你精确控制回滚点，防止部分更新导致的数据不一致。

2.4 事务嵌套与保存点（SAVEPOINT）

PostgreSQL 支持在事务块内部设置保存点（SAVEPOINT），允许部分回滚而不影响整个事务。这在复杂的支付对账或分步扣款场景中非常有用：

BEGIN;

-- 第一步：预扣冻结金额
UPDATE accounts SET frozen = frozen + 200 WHERE user_id = 1001;
SAVEPOINT after_freeze;

-- 第二步：尝试扣减余额（可能失败）
UPDATE accounts SET balance = balance - 200 WHERE user_id = 1001;
-- 假设余额不足，回滚到保存点，保留冻结状态
ROLLBACK TO SAVEPOINT after_freeze;

-- 第三步：改为部分扣款
UPDATE accounts SET balance = balance - 50 WHERE user_id = 1001;
COMMIT;
注意： 保存点虽然提供了灵活的回滚粒度，但过度使用会增加事务的复杂性和锁持有时间。在支付核心链路中，建议保持事务逻辑简洁，避免嵌套超过 3 层。如果业务需要复杂的补偿机制，应优先考虑应用层的 Saga 模式或 TCC 模式。

2.5 事务与锁的初步关联

事务的隔离性依赖于锁机制。当执行 BEGIN 后，后续的 UPDATE、DELETE、SELECT ... FOR UPDATE 语句会自动对涉及的行施加行级锁。下表总结了常见操作在事务中的锁行为：

操作类型 锁模式 对并发事务的影响
SELECT（普通查询） 无锁（MVCC 快照读） 不阻塞任何操作，读取的是事务开始时的快照
UPDATE / DELETE 行级排他锁（Row Exclusive Lock） 阻塞其他事务对同一行的 UPDATE/DELETE/SELECT FOR UPDATE，直到当前事务提交或回滚
SELECT ... FOR UPDATE 行级排他锁（Row Exclusive Lock） 与 UPDATE/DELETE 行为一致，用于显式锁定行以防止并发修改
INSERT 行级排他锁（新插入的行） 唯一索引冲突时会阻塞其他插入；普通插入不影响其他事务的读操作
← 上一章 📖 返回目录 下一章 →