opensearch-personalize-caching-strategies

双边平台研究：OpenSearch + Personalize 缓存最佳实践

本文提炼了运行 AWS OpenSearch（搜索）和 AWS Personalize（通过微服务提供推荐）的双边平台缓存策略参考。包含 9 个类别中的 52 条规则，按级联效应排序——从上游的「是否」缓存决策，到键设计、个性化边界、策略选择、TTL 设计、缓存击穿保护、可观测性，以及级联效应较低的负缓存和分层组合类别。每条规则都会解释原因（成本、延迟或正确性机制），展示错误与正确的代码示例（微服务层使用 TypeScript/Node，批处理和分析使用 Python，OpenSearch 专用查询使用 OpenSearch JSON，CDN/Kubernetes 使用 YAML），并引用权威来源——AWS Personalize/OpenSearch/ElastiCache 文档、XFetch 论文（Vattani et al. VLDB 2015）、RFC 5861（stale-while-revalidate），以及缓存基础设施团队的工程博客（Netflix EVCache、Pinterest Cachelib、Twitter Twemcache、Cloudflare）。

这是 opensearch-function-scoring-algorithms 的补充——那个技能回答「排名应该计算什么？」，而这个技能回答「如何将其扩展到生产流量，同时避免拖垮 OpenSearch 或 Personalize？」

适用场景

在以下情况下使用此技能：

• 首次为搜索或推荐界面添加缓存——从 decide-cache-roi-calculation 和 decide-hot-key-distribution 开始
• 首页或类别页面呈现 5 个以上推荐器，且 Personalize 账单增长速度快于流量增长——decide-amplification-multiplier、pers-recommender-fan-out-coalescing、pers-cohort-precomputation
• 缓存命中率低得可疑（低于 30-40%），但不知道原因——key-canonicalize-query、key-strip-volatile-params、key-bucket-numerical-ranges、obs-key-cardinality-tracking
• 流量高峰期间 Personalize 受到限流（HTTP 429）——decide-personalize-quota-budget、neg-cache-throttled-personalize、stamp-circuit-breaker-on-origin-error
• TTL 边界处 p99 出现峰值——stamp-coalesce-concurrent-misses、stamp-probabilistic-early-expiration、stamp-serve-stale-on-rebuild、ttl-soft-and-hard、ttl-jitter-to-prevent-thundering
• 模型重新训练后，推荐内容仍然过时——key-version-the-model、ttl-personalize-solution-version、strat-async-warm-up
• 读后写界面显示了过时数据（用户收藏、已保存的搜索）——strat-write-through-mutations、ttl-event-driven-invalidation
• 缓存决策需要向财务部门证明合理性——decide-cache-roi-calculation、obs-cost-attribution、obs-cache-simulation-from-logs
• 匿名流量和已登录流量混用相同路由——pers-anonymous-vs-logged-split、tier-cdn-for-anonymous
• 缓存面临内存压力，需要判断是扩容、缩短 TTL，还是更改策略——decide-hot-key-distribution、tier-l2-elasticache-redis、obs-cache-simulation-from-logs
• 常见查询导致 OpenSearch CPU 使用率偏高——tier-opensearch-request-cache、tier-opensearch-filter-context、neg-cache-empty-results
• 病毒式传播的链接或爬虫带来流量激增，导致源站不堪重负——neg-bloom-filter-against-misses、neg-cache-empty-results、stamp-circuit-breaker-on-origin-error 这些规则适用于任何由应用微服务提供服务、使用 OpenSearch 和 Personalize 的 AWS 市场，无论所属垂直领域是住宿、外卖、时尚、服务、招聘、二手商品还是房地产。触发场景包括“缓存命中率”、“缓存未命中风暴”、“Personalize 限流”、“Personalize 成本”、“多推荐器页面”、“群组缓存”、“single-flight”、“stale-while-revalidate”、“XFetch”、“OpenSearch 慢查询”、“ElastiCache 规格选择”、“CloudFront 搜索缓存”、“布隆过滤器缓存穿透”和“惊群效应”。

缓存管道

类别根据请求时的缓存管道划分。前面的阶段会层层影响后续阶段：如果“是否应该缓存？”的判断有误，下游的一切都会白费；如果键未规范化，命中率就会被限制在可实现上限的一小部分；如果没有可观测性，就无法判断这些规则是否有帮助。

Request → [1] Decide → [2] Key construction → [3] Personalisation boundary
        → [4] Strategy (read/write path) → [5] TTL/freshness → [6] Stampede protection
        → [8] Negative/defensive → [9] Tier composition (L1/L2/CDN/OS-internal) → Response
                                                ↑
                                [7] Observability (meta-layer applied to all stages:
                                    hit rate by key class, latency-with-and-without,
                                    cost-per-1k, cardinality, staleness, log-replay)

按优先级划分的规则类别

优先级	类别	影响	前缀	规则数
1	决策与成本计算	严重	decide-	7
2	缓存键设计	严重	key-	7
3	个性化边界	高	pers-	6
4	策略与写入路径	高	strat-	6
5	TTL 与新鲜度	高	ttl-	6
6	惊群保护	高	stamp-	5
7	可观测性与实证测量	高	obs-	6
8	负缓存与防御性缓存	中高	neg-	4
9	分层与边缘缓存	中高	tier-	5

快速参考

1. 决策与成本计算（严重）

• decide-cache-roi-calculation — 添加缓存前先计算缓存投资回报率
• decide-cardinality-floor — 流量分布平坦时跳过缓存
• decide-personalize-quota-budget — 选择缓存策略前，先建模 Personalize TPS 预算
• decide-latency-budget — 仅当源端 p99 延迟超过延迟预算时才缓存
• decide-amplification-multiplier — 将多推荐器页面的放大效应纳入考量
• decide-hot-key-distribution — 确定缓存规格前，先分析流量分布
• decide-search-vs-personalize-asymmetry — 为搜索缓存候选集，为 Personalize 缓存完整负载

2. 缓存键设计（严重）

• key-canonicalize-query — 哈希前先规范化查询
• key-segment-not-user — 用户数多于群组数时，按群组为推荐器生成键
• key-version-the-model — 在缓存键中包含 Personalize 解决方案版本
• key-locale-currency-explicit — 在键中明确指定区域设置、货币和时区
• key-strip-volatile-params — 哈希前去除易变参数和跟踪参数
• key-bucket-numerical-ranges — 哈希前对连续筛选条件进行分桶
• key-stable-hash-algorithm — 高基数键使用 SHA-256，而非 MD5

3. 个性化边界（高优先级）

• pers-cohort-precomputation — 离线预计算各群组的推荐结果
• pers-anonymous-vs-logged-split — 将匿名流量路由到全局缓存，将已登录流量路由到群组缓存
• pers-cold-start-cache-priority — 从热门度缓存为冷启动用户提供结果，跳过个性化
• pers-recommender-fan-out-coalescing — 将多个推荐器的扇出请求合并为批量调用
• pers-shared-candidates-private-ranking — 在全局缓存检索候选项，并从缓存中按用户重新排序
• pers-session-vector-write-through — 在缓存中维护会话向量，并在每次事件发生时执行直写

4. 策略与写入路径（高优先级）

• strat-cache-aside-default — 将旁路缓存作为读密集型路径的默认策略
• strat-refresh-ahead-hot-keys — 仅对最热门的 1% 键使用提前刷新
• strat-write-through-mutations — 当用户变更后会立即重新读取时，使用直写
• strat-precompute-batch — 使用批处理作业预计算热门部分
• strat-tiered-promotion — L2 命中时提升到 L1 进程内缓存
• strat-async-warm-up — 在部署、重启或模型重新训练后异步预热

5. TTL 与新鲜度（高优先级）

• ttl-by-content-volatility — 根据内容变化频率设置 TTL，而非出于工程便利
• ttl-soft-and-hard — 将软 TTL（异步刷新）与硬 TTL（同步未命中）分开
• ttl-jitter-to-prevent-thundering — 在 TTL 中加入随机抖动，防止同步过期
• ttl-personalize-solution-version — 将 TTL 固定到 Personalize 解决方案版本，而非墙上时钟
• ttl-event-driven-invalidation — 将 TTL 与事件驱动失效机制配合使用，确保关键数据新鲜度
• ttl-bound-by-staleness-tolerance — 根据产品对数据陈旧的容忍度限制 TTL，而非使用默认值

6. 缓存击穿防护（高优先级）

• stamp-coalesce-concurrent-misses — 将并发未命中合并为一次源站调用
• stamp-probabilistic-early-expiration — 对热门键使用 XFetch 概率性提前过期
• stamp-serve-stale-on-rebuild — 刷新进行期间提供过期数据
• stamp-circuit-breaker-on-origin-error — 遇到源站错误时触发熔断器，并回退到过期数据
• stamp-distributed-lock-rebuild — 使用分布式锁协调跨实例的缓存重建

7. 可观测性与实证测量（HIGH）

• obs-hit-rate-by-key-class — 按键类别跟踪命中率，切勿只统计汇总值
• obs-latency-histograms-with-without — 分别测量命中和未命中的延迟直方图
• obs-cost-attribution — 分别计算有缓存和无缓存时每千次请求的成本
• obs-key-cardinality-tracking — 每日抽样统计键的基数；出现激增时发出警报
• obs-stale-served-ratio — 测量过期数据服务比例，以验证 TTL 的选择
• obs-cache-simulation-from-logs — 更改 TTL 或策略前，先将生产日志输入缓存模拟器进行回放

8. 负缓存与防御性缓存（MEDIUM-HIGH）

• neg-cache-empty-results — 使用较短的 TTL 缓存空搜索结果
• neg-cache-throttled-personalize — Personalize 限流时，提供上一次已知的正常结果
• neg-bloom-filter-against-misses — 使用布隆过滤器阻止高基数未命中风暴
• neg-poison-pill-detection — 对缓存条目进行校验和检查，以检测并拒绝被污染的写入

9. 分层缓存与边缘缓存（MEDIUM-HIGH）

• tier-l1-in-process — 使用进程内 LRU 作为 L1，实现亚毫秒级读取
• tier-l2-elasticache-redis — 根据跨实例工作集确定 L2 ElastiCache 的容量
• tier-cdn-for-anonymous — 对匿名流量使用 CDN；对 Cookie 流量绕过 CDN
• tier-opensearch-request-cache — 为聚合密集型查询启用 OpenSearch 请求缓存
• tier-opensearch-filter-context — 将可复用谓词放入过滤上下文，以实现片段级缓存

使用方法

对于聚焦的问题（“我应该缓存这个吗？”、“为什么我的命中率这么低？”、“如何应对 Personalize 限流？”），直接跳转到相关规则即可——每条规则都自成一体，包含原因、代码和引用。

对于新功能或运行不佳功能的完整缓存设计评审，请从上到下依次检查各类别。级联效应确实存在：错误的 decide-cache-roi-calculation 会让工程资源浪费在无法带来收益的缓存上；有漏洞的 key-canonicalize-query 会限制可达到的命中率；缺少 pers-cohort-precomputation 会使 Personalize 费用与 MAU 成正比。当命中率超过 90% 时，防止缓存击穿和做好可观测性是必需的——在请求风暴中，10% 的未命中就足以压垮源站；而没有按类别统计的命中率仪表盘，你就无从判断。

要基于实测调优现有缓存，请从 obs-cache-simulation-from-logs 开始（使用假设配置重放日志），并配合 obs-hit-rate-by-key-class、obs-cost-attribution 和 obs-stale-served-ratio 配置仪表盘。这三项能回答：缓存是否发挥了作用、成本是多少，以及用户是否看到了过时数据？

针对多推荐器首页问题（最常见的 Personalize 成本激增模式），优先顺序为：decide-amplification-multiplier → pers-cohort-precomputation → pers-recommender-fan-out-coalescing → pers-anonymous-vs-logged-split。这四项通常能将消费类市场平台的 Personalize 支出降低 70-90%。

针对“Personalize 在负载下触发限流”的故障，优先顺序为：stamp-circuit-breaker-on-origin-error → neg-cache-throttled-personalize → decide-personalize-quota-budget。前两项能稳定面向用户的影响；第三项会合理设置 minProvisionedTPS，避免问题再次发生。

如需交叉参考相关技能，请参阅 opensearch-function-scoring-algorithms——该技能介绍在 OpenSearch 中需要计算什么（function_score、kNN、RRF、rank_feature、decay、LTR、MMR、评估）。本技能介绍如何缓存计算结果，使集群能够承受生产流量。

阅读章节定义，了解级联影响的依据；添加新规则时，请阅读规则模板。

相关技能

• opensearch-function-scoring-algorithms — 面向 OpenSearch、有研究依据的排序、检索和评估规则。它讲的是“计算什么”；本技能讲的是“如何扩展规模”。

参考文件

文件	描述
references/_sections.md	类别定义及按级联影响排列的顺序
AGENTS.md	精简的目录导航（自动生成；请勿手动编辑）
assets/templates/_template.md	编写新规则的模板
metadata.json	版本和权威参考 URL