2. PostgreSQL 中间件基础：连接池、事务管理与 ACID 特性回顾
在构建支付订单幂等校验中间件之前，必须重新审视 PostgreSQL 的核心机制。中间件本质上是对数据库连接、事务边界与一致性保证的封装。本章从连接池、事务管理、ACID 三个维度展开，为后续状态机设计与幂等校验打下基础。
2.1 连接池：中间件的第一层资源管理
PostgreSQL 采用进程模型，每个客户端连接对应一个后端进程。频繁创建/销毁连接会带来显著的上下文切换与内存开销。中间件必须通过连接池复用连接，降低延迟。
| 对比维度 | 直连模式 | 连接池模式 |
|---|---|---|
| 连接建立开销 | 每次 TCP 握手 + 认证 | 预创建，复用已有连接 |
| 最大并发数 | 受限于 max_connections | 池大小可控，避免过载 |
| 事务生命周期 | 与连接绑定 | 可独立管理，归还前回滚 |
| 典型中间件 | psycopg2 直连 | PgBouncer、Pgpool-II、HikariCP |
工程要点： 支付场景下，连接池必须设置
setAutoCommit(false) 或等价模式，防止中间件自动提交未完成的事务，破坏幂等校验的原子性。
2.2 事务管理：状态机编排的原子边界
PostgreSQL 事务提供 BEGIN、COMMIT、ROLLBACK 以及 SAVEPOINT 机制。中间件在编排订单状态机时，需要精确控制事务边界：
- 显式事务：每个幂等校验步骤（查询→校验→更新）应包裹在同一个事务中。
- 子事务（SAVEPOINT）：用于部分回滚，例如校验失败时仅回滚状态更新，保留查询结果。
- 事务隔离级别：支付订单通常使用
READ COMMITTED或REPEATABLE READ，防止幻读影响幂等判断。
-- 中间件典型事务模板
BEGIN;
-- 步骤1：查询当前订单状态（带行锁）
SELECT status, version FROM orders WHERE order_id = $1 FOR UPDATE;
-- 步骤2：业务校验（幂等判断）
-- 步骤3：更新状态与版本号
UPDATE orders SET status = 'paid', version = version + 1 WHERE order_id = $1 AND version = $2;
-- 步骤4：检查受影响行数
COMMIT;
常见陷阱： 中间件在连接归还池前，必须确保事务已提交或回滚。残留的未提交事务会导致连接池中的连接持有锁，引发死锁或超时。
2.3 ACID 特性回顾：幂等校验的理论基石
ACID 是数据库事务正确执行的四个属性。在支付订单幂等校验中，每个属性都有直接映射：
| ACID 属性 | 定义 | 在幂等校验中的体现 |
|---|---|---|
| 原子性 (Atomicity) | 事务全部执行或全部不执行 | 校验与更新必须在一个事务内，要么全部成功，要么全部回滚 |
| 一致性 (Consistency) | 事务前后数据满足所有约束 | 订单状态机不允许非法跳转（如从“已支付”回到“待支付”） |
| 隔离性 (Isolation) | 并发事务互不干扰 | 使用 SELECT FOR UPDATE 或乐观锁防止重复支付 |
| 持久性 (Durability) | 提交后数据永久保存 | WAL 日志确保支付记录不丢失，幂等结果可恢复 |
设计启示： 中间件应利用 PostgreSQL 的
pg_stat_activity 和 pg_locks 监控事务状态，在连接池层面提前检测长时间未提交的事务，避免锁扩散。
2.4 连接池与事务的交互模型
下图展示了中间件、连接池、PostgreSQL 后端进程之间的典型交互流程，重点突出事务生命周期与连接复用的关系：
2.5 隔离级别对幂等校验的影响
PostgreSQL 默认使用 READ COMMITTED，但在高并发支付场景下，不同隔离级别对幂等校验的正确性有直接影响：
- READ COMMITTED：每次查询只能看到已提交的数据。如果两个请求同时查询同一订单，可能都看到“待支付”状态，导致重复支付。必须配合
SELECT FOR UPDATE使用。 - REPEATABLE READ：事务内多次查询结果一致，避免不可重复读。但无法防止幻读（PostgreSQL 通过快照实现，实际已接近可序列化）。
- SERIALIZABLE：最强隔离，但性能开销大，且可能因冲突导致序列化失败，需要重试机制。
推荐实践： 支付订单幂等校验中间件使用
READ COMMITTED + 行锁（SELECT FOR UPDATE）或乐观锁（版本号/时间戳）。前者适合写冲突高的场景，后者适合读多写少的场景。