3. 一致性问题全景：最终一致性、强一致性、CAP理论在缓存场景下的权衡、常见不一致场景
在合规治理驱动的架构中，缓存与数据库之间的一致性问题是审计风险的主要来源。本章从理论模型出发，系统梳理一致性分类、CAP 约束下的缓存设计权衡，以及生产环境中高频出现的脏读、幻读、缓存雪崩等不一致场景，为后续审计规则设计奠定基础。
3.1 一致性模型：从强一致到最终一致
一致性模型定义了数据在分布式系统中的可见性与更新顺序。在缓存 + 数据库的混合架构中，不同模型直接影响审计日志的准确性和回放能力。
| 一致性模型 | 核心定义 | 缓存场景典型实现 | 合规审计影响 |
|---|---|---|---|
| 强一致性 | 写入完成后，任何后续读取都能读到最新值 | 同步双写 + 分布式锁 / 事务性缓存（如 Redis 红锁 + 数据库 XA） | 审计日志可直接信任缓存快照，无需额外校验 |
| 最终一致性 | 写入后存在短暂不一致窗口，但最终所有副本会收敛到一致状态 | 异步写回 + 消息队列补偿 / 缓存过期后回源 | 审计需记录时间戳与版本号，容忍短暂偏差 |
| 因果一致性 | 有因果关系的操作按顺序可见，无因果关系的可并发 | 逻辑时钟 + 版本向量（如 Dynamo 风格） | 审计需追踪操作依赖链，适用于事件溯源场景 |
| 读己之写 | 写入者总能读到自己的写入，其他用户可能读到旧值 | Session 级缓存 + 本地写优先 | 用户级审计可接受，全局审计需合并会话 |
3.2 CAP 理论在缓存场景下的权衡
CAP 理论指出分布式系统在一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者中最多同时满足两项。缓存系统通常部署在跨机房或跨可用区环境中，网络分区是常态，因此必须在 C 和 A 之间做出选择。
下表对比了三种典型缓存架构的 CAP 倾向及审计风险：
| 架构模式 | CAP 选择 | 分区时行为 | 审计风险点 |
|---|---|---|---|
| 本地缓存 + 数据库直读 | AP（高可用优先） | 返回本地缓存旧数据，异步尝试同步 | 脏数据被审计采集，需额外校验时间戳 |
| 分布式缓存（Redis Cluster）+ 同步复制 | CP（强一致优先） | 分区时缓存节点拒绝写入，等待多数派确认 | 审计日志完整，但可用性下降可能触发业务中断 |
| 读写分离 + 缓存旁路（Cache-Aside） | AP 为主，局部 CP | 缓存失效后回源 DB，DB 分区时返回降级数据 | 审计需区分“缓存命中”与“DB 回源”两条路径 |
3.3 常见不一致场景：脏读、幻读、缓存雪崩
在缓存与数据库双写或异步同步过程中，以下三种不一致场景是审计合规的高频风险点，也是审计规则设计的核心检测目标。
3.3.1 脏读（Dirty Read）
定义： 一个事务读取了另一个未提交事务写入的缓存数据。在缓存场景中，通常表现为：应用先更新缓存（如 Redis），但数据库事务尚未提交，此时其他请求从缓存读到“脏数据”。
典型触发路径：
- 应用线程 A 更新缓存（set key=value_new）
- 线程 A 执行数据库 UPDATE，但事务未提交
- 线程 B 从缓存读取到 value_new
- 线程 A 事务回滚，数据库回退到旧值，但缓存仍为 value_new
审计检测手段：
- 在缓存写入时记录事务 ID 与状态标记
- 审计采集器对比缓存快照与数据库 binlog 中的事务提交状态
- 设置缓存 TTL 上限，强制过期后回源校验
3.3.2 幻读（Phantom Read）
定义： 在缓存场景中，幻读特指同一查询条件在缓存与数据库之间返回了不同的结果集行数。例如：缓存中存储了分页列表，但数据库在两次查询之间插入了新行，导致缓存结果集“多出”或“缺少”记录。
| 对比维度 | 传统数据库幻读 | 缓存场景幻读 |
|---|---|---|
| 触发条件 | 同一事务内两次范围查询，另一事务插入新行 | 缓存快照与数据库当前状态不一致 |
| 影响范围 | 事务隔离级别（RR 以下） | 缓存命中与回源路径分离 |
| 审计难点 | 通过 MVCC 或锁机制可检测 | 缓存无事务隔离，需依赖版本号或游标标记 |
| 常见场景 | 报表统计、库存查询 | 分页列表、排行榜、聚合计数 |
max_version 或 row_count_hash，审计时对比缓存与数据库的哈希值是否一致。
3.3.3 缓存雪崩（Cache Avalanche）
定义： 大量缓存 key 在同一时间过期失效，或缓存节点整体宕机，导致所有请求直接穿透到数据库，引发数据库负载飙升甚至宕机。从一致性角度看，雪崩期间缓存与数据库的“同步窗口”被强制打开，极易产生不一致。
雪崩导致不一致的三种路径：
- 路径一： 缓存过期后，多个并发请求同时回源，第一个请求更新缓存，后续请求读到旧缓存（因回源未完成）
- 路径二： 缓存节点宕机，请求全部落到数据库，数据库在压力下出现主从延迟，缓存重建时读到从库旧数据
- 路径三： 雪崩恢复后，缓存与数据库的版本号未对齐，导致“新缓存 + 旧数据库”或“旧缓存 + 新数据库”的交叉不一致
3.4 不一致场景的审计优先级矩阵
基于合规治理的视角，不同不一致场景对审计的影响程度不同。下表给出优先级排序，帮助审计规则设计时合理分配资源：
| 优先级 | 不一致场景 | 影响等级 | 检测难度 | 合规风险 | 推荐审计频率 |
|---|---|---|---|---|---|
| P0 | 脏读（未提交事务数据） | 严重 | 中 | 资金对账不平、库存超卖 | 实时 / 秒级 |
| P1 | 缓存雪崩导致的不一致 | 严重 | 高 | 批量数据偏差、系统降级 | 事件触发 + 恢复后全量对账 |
| P2 | 幻读（集合结果不一致） | 中等 | 高 | 报表统计错误、分页数据异常 | 分钟级 / 定时采样 |
| P3 | 最终一致性窗口内的短暂偏差 | 低 | 低 | 非关键业务展示偏差 | 小时级 / 日志回放 |