PostgreSQL 基础回顾：事务隔离级别、MVCC 机制、WAL 日志原理
在深入缓存一致性验证之前，必须牢固掌握 PostgreSQL 的三大核心基石：事务隔离级别、MVCC（多版本并发控制）和 WAL（预写式日志）。这三者共同决定了数据库在并发读写、崩溃恢复时的行为，也是缓存数据不一致问题的根本来源。
2.1 事务隔离级别
SQL 标准定义了四种事务隔离级别，PostgreSQL 实现了其中三种（未提交读被当作已提交读处理）。隔离级别决定了事务之间对数据变更的可见性，直接影响缓存数据是否可能读到“脏”或“不可重复”的数据。
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 序列化异常 |
|---|---|---|---|---|
| 读已提交（Read Committed） | 不可能 | 可能 | 可能 | 可能 |
| 可重复读（Repeatable Read） | 不可能 | 不可能 | 可能（PG 中不可能） | 可能 |
| 可序列化（Serializable） | 不可能 | 不可能 | 不可能 | 不可能 |
关键认知： PostgreSQL 的“可重复读”级别通过快照隔离（Snapshot Isolation）完全避免了幻读，这是与标准 SQL 不同的地方。在缓存一致性测试中，读已提交是最常见的默认级别，也是产生不一致场景最多的级别。
2.2 MVCC 机制
MVCC 是 PostgreSQL 实现高并发读写的核心机制。每个事务在启动时都会获得一个事务 ID（XID），数据行上会记录创建它的 xmin 和删除/过期它的 xmax。通过比较事务快照与行上的 XID，PostgreSQL 可以判断该行对当前事务是否可见。
MVCC 核心规则：
- 每个查询只看到在事务开始前已提交的数据（可重复读级别）。
- 写操作不会阻塞读操作，读操作也不会阻塞写操作。
- 更新操作实际是“删除旧版本 + 插入新版本”，旧版本保留在数据页中直到被清理（VACUUM）。
缓存一致性影响： 由于 MVCC 的存在，应用程序在
SELECT 后看到的是一份“快照数据”。如果此时缓存层也保存了同一行数据，而另一个事务提交了更新，数据库与缓存之间就会出现版本偏差。验证方案必须能检测到这种“读已提交”级别下的短暂不一致窗口。
2.3 WAL 日志原理
WAL（Write-Ahead Logging）是 PostgreSQL 保证数据持久性和崩溃恢复的核心机制。其基本原则是：在数据页被写入磁盘之前，必须先确保对应的日志记录已经落盘。
- 日志先行： 任何数据修改操作（INSERT/UPDATE/DELETE）首先产生 WAL 记录，写入 WAL 缓冲区，然后才修改共享缓冲区中的数据页。
- 检查点（Checkpoint）： 定期将共享缓冲区中的脏页刷入数据文件，并记录检查点位置，缩短崩溃恢复时间。
- 归档与复制： WAL 日志可以被连续归档，用于时间点恢复（PITR）和流复制（Streaming Replication）。
| 组件 | 作用 | 对缓存一致性的影响 |
|---|---|---|
| WAL 缓冲区 | 内存中暂存未落盘的日志 | 事务提交时强制刷盘，但数据页可能仍在内存 |
| 共享缓冲区 | 缓存数据页，减少磁盘 I/O | 脏页未刷盘前，数据库崩溃会导致数据丢失 |
| 检查点进程 | 将脏页写入数据文件 | 检查点后，缓存与数据文件一致，但应用层缓存可能仍旧 |
验证方案关联： 在缓存一致性测试中，WAL 机制意味着：即使数据库返回“事务已提交”，数据页可能仍在共享缓冲区中，尚未写入数据文件。如果此时数据库崩溃，恢复后的数据可能与缓存中保存的数据一致，也可能不一致（取决于缓存是否在崩溃前已更新）。测试需要覆盖崩溃恢复场景下的缓存一致性。
2.4 三者协同与缓存一致性
事务隔离级别、MVCC 和 WAL 共同构成了 PostgreSQL 的事务与存储体系。在缓存一致性验证中，需要关注以下协同效应：
- 隔离级别 + MVCC： 决定了事务读取到的数据版本。缓存如果基于“读已提交”级别读取，可能读到旧版本，导致缓存与数据库最新提交数据不一致。
- WAL + 检查点： 决定了数据持久化的时机。缓存可能在数据库尚未完全持久化时就认为数据已“落盘”，从而产生误判。
- MVCC 版本链 + 缓存更新策略： 如果缓存更新策略是“先更新数据库，再删除缓存”，在 MVCC 下，并发事务可能读到旧版本并重新填充缓存，导致缓存数据回退。
测试设计启示： 设计缓存一致性验证用例时，必须显式指定事务隔离级别，并考虑 MVCC 快照的生效时机。建议在测试中同时监控
pg_current_xact_id() 和 pg_current_wal_lsn()，以精确判断事务提交与 WAL 刷盘的时序关系。