3、缓存基础理论：缓存的定义、缓存命中与未命中、缓存淘汰策略（LRU/TTL/FIFO）、缓存一致性模型

3.1 缓存的定义与核心价值

缓存（Cache）是一种将数据存储在临时高速存储层中的技术，其核心目的是通过减少对原始数据源（如数据库、磁盘或远程API）的访问次数，来降低数据读取延迟并提升系统吞吐量。在Secrets管理场景中，缓存通常用于存储解密后的凭证、访问令牌或策略评估结果，避免每次请求都触发昂贵的加密计算或网络调用。

3.2 缓存命中与未命中

缓存系统的性能核心指标是命中率（Hit Ratio），即请求在缓存中找到所需数据的比例。理解命中与未命中的生命周期，是分析缓存瓶颈的基础。

3.3 缓存淘汰策略

当缓存空间满时，需要按照特定策略移除旧数据以容纳新数据。不同的淘汰策略对Secrets缓存的命中率和安全性有直接影响。

3.3.1 LRU（最近最少使用）

原理：淘汰最长时间未被访问的数据。基于“时间局部性”原理，认为最近被访问过的数据在未来更可能被再次访问。

• 优点：对热点数据敏感，能自动适应访问模式变化。
• 缺点：实现复杂度较高（通常需要双向链表+哈希表）；在Secrets场景中，如果某个Secret被周期性轮询（如每60秒一次），LRU会将其保留在缓存中，即使它很少被其他服务使用。
• 适用场景：访问模式有明显热点的Secrets，如高频使用的数据库凭证。

3.3.2 TTL（生存时间）

原理：为每个缓存条目设置一个固定的过期时间（Time-To-Live），到期后自动失效。这是Secrets管理中最常用的策略。

• 优点：实现简单，天然支持数据自动刷新；安全性好，过期后强制重新获取最新Secret。
• 缺点：TTL设置过短会导致频繁未命中；设置过长则可能导致客户端使用已吊销的凭证。
• 最佳实践：Secrets的TTL通常设置为凭证有效期的50%-70%。例如，如果KMS生成的令牌有效期为1小时，缓存TTL可设为30-40分钟。

3.3.3 FIFO（先进先出）

原理：按照数据进入缓存的顺序进行淘汰，最先进入的条目最先被移除。

• 优点：实现最简单，开销最低。
• 缺点：不考虑访问频率和时效性，可能淘汰掉仍在频繁使用的热点数据。
• 适用场景：几乎不适用于Secrets缓存，仅用于某些日志或事件缓存场景。

3.4 缓存一致性模型

缓存一致性模型定义了缓存中的数据与源数据（如KMS中的主密钥）之间保持同步的规则。在Secrets管理中，一致性模型直接关系到系统的安全性和可用性。

3.4.1 强一致性（Strong Consistency）

每次读取缓存时，都保证返回的是最新的写入值。实现方式通常是“缓存旁路（Cache-Aside）”模式中的“写入后失效”：

// 伪代码：强一致性写入流程
function updateSecret(key, newValue) {
    // 1. 先更新后端存储
    backend.update(key, newValue);
    // 2. 再使缓存失效（删除旧缓存）
    cache.delete(key);
    // 后续读取会触发缓存未命中，从后端获取最新值
}

• 优点：数据准确，安全性最高。
• 缺点：写入延迟较高；在分布式系统中实现困难（需要分布式锁或共识协议）。
• Secrets场景：仅用于关键凭证的即时吊销场景，如检测到安全事件时立即禁用某个。

3.4.2 最终一致性（Eventual Consistency）

允许缓存中的数据在一段时间内与源数据不一致，但最终会达到一致状态。这是Secrets缓存中最常用的模型。

• 实现方式：TTL过期 + 后台异步刷新。
• 优点：性能高，写入无需等待缓存更新；系统可用性好。
• 缺点：存在“不一致窗口”，在TTL过期前，客户端可能使用旧凭证。
• Secrets场景：适用于非关键凭证的缓存，如只读数据库的密码（密码轮换时允许短暂使用旧密码）。

3.4.3 读写一致性（Read-Your-Writes Consistency）

保证写入者自己立即能看到最新数据，但其他客户端可能看到旧数据。这是最终一致性的一个变种。

• 实现方式：为写入者绑定一个“本地缓存”或使用版本号标记。
• Secrets场景：当管理员手动轮换Secret后，管理员自己的后续请求应立即使用新Secret，而其他服务可以继续使用缓存中的旧Secret直到TTL过期。

3.5 缓存策略选择矩阵

在Secrets管理系统中，没有一种策略是万能的。以下矩阵帮助你在不同场景下做出选择：