4. 冷启动场景分析：新节点加入、缓存失效、大规模回填、灾难恢复时的查询延迟

Sigstore 透明日志（如 Rekor）在冷启动场景下，查询延迟会急剧上升，甚至导致服务不可用。本章深入分析四种典型冷启动场景的根因、影响范围与量化指标，为后续的削峰策略提供决策依据。

4.1 四种冷启动场景全景

4.2 新节点加入：数据空洞与索引重建

当新节点加入 Rekor 集群时，它需要从零开始构建本地 Merkle 树和索引。在数据同步完成前，该节点无法独立响应查询，所有请求必须转发给已有节点，造成热点和额外网络延迟。

4.3 缓存失效：穿透风暴与存储层过载

Sigstore 透明日志的查询缓存通常采用 TTL 策略（如 5–30 分钟）。当大量缓存同时过期（如部署新版本导致缓存清空），所有查询直接穿透到后端存储（如 Trillian 的 MySQL/Spanner），造成数据库连接池耗尽和查询排队。

缓存失效的三种模式

• 批量过期：大量 key 的 TTL 同时到达，触发缓存雪崩。建议在 TTL 基础上增加随机偏移（±20%）。
• 缓存击穿：热点 key（如知名项目的根哈希）在失效瞬间被高并发查询，直接压垮后端。建议使用互斥锁或提前续期。
• 缓存穿透：查询不存在的数据（如伪造的条目哈希），每次都需要穿透到存储层。建议使用布隆过滤器拦截。

4.4 大规模回填：写入与查询的资源争抢

当需要将历史数据回填至透明日志时（如从旧集群迁移、审计补录），写入操作会大量消耗磁盘 I/O、CPU 和内存。查询请求与回填写入共享同一存储层，产生严重的资源争抢。

4.5 灾难恢复：全量重建与一致性校验

灾难恢复是最极端的冷启动场景。当主集群完全不可用时，需要从备份或对等集群重建整个透明日志。此过程涉及全量数据下载、Merkle 树重建、一致性校验和缓存预热，查询服务在重建完成前通常不可用或延迟极高。

灾难恢复的关键阶段与延迟特征

1. 数据恢复（30–120 分钟）：从对象存储（如 GCS、S3）下载快照，延迟取决于数据量和网络带宽。1TB 数据在 1Gbps 链路下约需 2.5 小时。
2. Merkle 树重建（15–60 分钟）：重新计算所有条目的哈希树，CPU 密集型操作，单线程重建 1000 万条目约需 30 分钟。
3. 一致性校验（10–30 分钟）：与对等集群交叉验证根哈希，确保数据完整性。校验失败需要回滚到上一个检查点。
4. 缓存预热（5–20 分钟）：逐步加载热点查询结果，预热期间查询延迟仍处于高位。

4.6 冷启动延迟的量化模型

为便于制定削峰策略，我们建立冷启动查询延迟的量化模型：

冷启动查询延迟 = 基础查询延迟 + 冷启动惩罚因子

冷启动惩罚因子 = f(数据缺失率, 缓存命中率, 资源争抢系数)

其中：
- 数据缺失率 = 1 - (本地已同步数据量 / 总数据量)
- 缓存命中率 = 缓存命中次数 / 总查询次数（冷启动期间通常 < 30%）
- 资源争抢系数 = 1 + (写入 QPS / 稳态写入 QPS) * 0.5

以新节点加入为例，假设基础查询延迟为 100ms，数据缺失率 80%，缓存命中率 20%，资源争抢系数 1.5，则冷启动查询延迟约为：

延迟 ≈ 100ms * (1 + 0.8 * 2 + (1 - 0.2) * 3) * 1.5
     ≈ 100ms * (1 + 1.6 + 2.4) * 1.5
     ≈ 100ms * 5 * 1.5
     ≈ 750ms

该模型帮助 SRE 团队在冷启动前预估延迟影响，并据此调整客户端超时和重试策略。

4.7 冷启动场景的监控与告警

针对上述四种场景，建议部署以下监控指标，实现冷启动的自动检测与告警：