4. OPA 默认缓存机制剖析：内置缓存策略、缓存失效时间、缓存命中率的影响因素
OPA 的默认缓存机制是降低策略评估延迟、减少对 K8s API Server 压力的第一道防线。理解其内置策略、失效时间模型以及命中率的关键影响因素，是后续进行精细化调优的基础。本章将深入 OPA 的缓存内核，拆解其工作原理。
4.1 内置缓存策略：两阶段分层模型
OPA 并非采用单一的缓存结构，而是使用一种 两阶段分层缓存 模型，分别处理 数据文档 和 策略/规则 的缓存。
核心要点： OPA 的缓存分为“数据缓存”和“规则缓存”两层。数据缓存存储从 K8s API 拉取的资源清单（如 Pods、Services）；规则缓存存储编译后的策略 AST（抽象语法树）和中间表示。两者失效机制不同，对性能的影响也不同。
4.2 缓存失效时间（TTL）机制
OPA 的缓存失效并非简单的固定 TTL，而是结合了 主动推送 和 被动轮询 两种机制。默认情况下，OPA 通过 Watch API 与 K8s 建立长连接，实现近乎实时的缓存更新。
| 缓存类型 | 默认失效策略 | TTL 默认值 | 触发失效条件 |
|---|---|---|---|
| 数据缓存 | Watch 事件驱动 + 兜底 TTL | 无固定 TTL（依赖 Watch） | K8s 资源变更事件、连接断开后重连 |
| 规则缓存 | 依赖图失效 + 手动触发 | 无 TTL（持久化） | 策略文件变更、Bundle 更新、依赖数据变更 |
| HTTP 响应缓存 | 基于 ETag / Last-Modified | 由 K8s API Server 控制 | HTTP 304 响应、缓存过期 |
注意： 当 OPA 与 K8s API Server 之间的 Watch 连接因网络问题中断时，OPA 会回退到轮询模式。此时，缓存的有效性取决于轮询间隔。默认轮询间隔为 60 秒，这意味着在最坏情况下，OPA 可能使用长达 60 秒的过期数据。
4.3 缓存命中率的影响因素
缓存命中率直接决定了 OPA 的平均评估延迟。以下四个因素是影响命中率的关键变量：
- 数据变更频率： 频繁变更的命名空间（如 CI/CD 环境）会导致缓存频繁失效，命中率下降。
- 策略查询的重复性： 如果每次准入请求都查询不同的资源子集（如随机 Pod），缓存命中率会很低。
- 缓存大小限制： OPA 默认对缓存大小没有硬性限制，但受限于内存。当内存压力大时，GC 可能导致缓存条目被回收。
- Watch 连接稳定性： 连接断开后的重同步阶段，缓存会被清空并重新填充，期间命中率降为零。
4.4 缓存命中率与延迟的关系
以下表格展示了不同缓存命中率下，OPA 评估延迟的典型表现：
| 缓存命中率 | 典型评估延迟 | 对 K8s API 的压力 | 适用场景 |
|---|---|---|---|
| > 95% | < 1 ms | 极低 | 稳定生产环境 |
| 70% - 95% | 1 - 5 ms | 中等 | 中等变更频率环境 |
| 50% - 70% | 5 - 20 ms | 较高 | 频繁变更环境 |
| < 50% | > 20 ms | 极高 | 需要紧急优化 |
4.5 默认缓存配置的局限性
优化提示： 默认缓存机制在大多数场景下表现良好，但在高并发或大规模集群中，存在以下三个主要局限性：
- 无差异化 TTL： 所有资源类型使用相同的失效策略，无法为频繁变更的资源（如 Pod）和不常变更的资源（如 Namespace）设置不同的缓存时间。
- 缓存穿透问题： 当查询一个不存在的资源时（如一个已被删除的 Pod），OPA 仍然会向 K8s API 发起请求，导致缓存穿透。
- 缺乏预热机制： OPA 启动或重连后，缓存是空的，需要经历一段“冷启动”期，期间所有请求都会穿透到 API Server。