第 8 章 低延迟与复杂读场景系统设计方法论：搜索、推荐、广告与 Feed

当系统面对搜索、推荐、广告投放、Feed 流、详情页这类“用户一打开就要马上看到结果”的场景时，设计重点不再只是数据对不对，而是如何在复杂查询、高 QPS 和持续变化的数据之间，把延迟、吞吐、结果质量和数据新鲜度一起控制住。

上一章讨论了支付、库存和账务等“事实不能错”的系统。本章讨论另一类同样典型的问题：结果不一定要求全链路瞬时强一致，但必须在严格的延迟预算内稳定产出，并且能够解释结果为什么这样生成、什么时候更新、过载时如何降级。

低延迟复杂读系统最容易被误解成“加一个缓存”或“部署一个搜索引擎”。真正的系统设计问题是：写模型、索引、候选集、特征、缓存、排序和页面拼装之间如何协作；哪些计算应该在写入时完成，哪些必须在请求时完成；当某个依赖变慢或数据暂时陈旧时，系统应该牺牲什么来保护用户体验。

8.1 问题定义：复杂读的核心是稳定地产出结果

8.1.1 复杂读不是简单地把数据查出来

简单读通常是按主键查询一个事实，复杂读则包含多个阶段：解析请求、过滤候选、全文检索、召回、排序、特征读取、聚合、权限判断、分页和结果拼装。

典型请求包括：

• 搜索商品、内容、酒店或文档。
• 推荐下一条内容、商品或广告。
• 根据用户、上下文、预算和频控进行广告决策。
• 生成按时间、关系和排序规则组织的 Feed。
• 拼装商品详情、价格、库存、营销、评价和推荐信息。

这些请求通常具有五个共同点：查询逻辑复杂，读取远多于写入，数据会持续变化，流量具有尖峰和热点，用户对延迟与结果质量都敏感。它们的“读”并不是对某张表执行一次 SELECT，而是一次面向用户意图的结果生成过程。

从业务角度看，系统最终交付的也不是“数据库返回了多少行”，而是一个可以被用户使用的结果集合。搜索空结果、推荐列表重复、广告候选缺失、Feed 顺序抖动、详情页核心字段过期，都会被用户感知为产品质量问题，而不只是某个基础设施指标变差。

8.1.2 复杂读场景的五个设计轴

这五个轴会互相冲突。提高召回数量可能提高结果质量，但会增加排序延迟；缩短缓存 TTL 可以提高新鲜度，但会降低命中率并增加回源压力；增加实时特征可以提高个性化效果，但会拉长依赖链路。

可以把复杂读抽象成下面的优化问题：

在总延迟预算、资源预算和新鲜度窗口内，最大化结果质量与业务价值

这个表达式不是要求团队计算一个精确的数学最优解，而是提醒设计者：任何“更快”的方案都要说明牺牲了什么。例如，减少精排候选可以降低 P99，却可能降低相关性；延长缓存 TTL 可以提高命中率，却可能放大陈旧价格的展示风险；把 Feed 预先写入用户时间线可以降低读取成本，却会增加写放大和关系变化时的维护成本。

8.1.3 本章的范围与非目标

本章聚焦：

1. 如何从查询模式设计读模型，而不是直接复用写库模型。
2. 如何建立延迟预算，并把预算分配到检索、特征、排序和拼装阶段。
3. 如何通过索引、缓存、预计算、物化视图和 Fanout 保护读路径。
4. 如何在不一致、依赖故障和过载时提供可解释的降级结果。

本章不展开具体搜索分词算法、推荐模型训练细节或某个云厂商的产品配置。搜索引擎、Redis、Kafka、推荐模型和 Elasticsearch 的实现细节，应结合本书后续基础设施章节阅读。

索引和搜索引擎的底层面试题可参见后端面试基础知识题单中的 Elasticsearch 主题，商品发现的完整业务读路径可参见第 14 章电商用户全生命周期设计。本章重点保留复杂读场景的统一模型、延迟预算和方案取舍。

8.2 约束与指标：把“快”拆成预算，把“好”拆成质量

8.2.1 不要使用一个统一的延迟目标

“P99 必须小于 100 ms”可以作为讨论起点，但不能成为脱离场景的通用标准。搜索建议、广告决策、商品详情和离线管理后台的延迟目标不同；同一个接口在不同请求类型下的资源成本也可能完全不同。

Google 的《The Tail at Scale》说明，在大规模服务中，尾延迟会因为请求扇出、依赖抖动和资源利用率上升而被放大。因此设计时必须关注 P95、P99 和最慢依赖，而不是只看平均响应时间。[1]

延迟目标应该按场景写成契约：搜索建议要求首字响应快，详情页保证基础字段先返回，推荐模块允许独立超时，广告决策必须在极短时间内完成，运营后台则可以接受更长等待。契约还应说明超时后的行为：是返回旧结果、减少候选、跳过增强模块，还是直接拒绝请求。

8.2.2 延迟预算示例

假设商品详情页的目标预算为 180 ms，可以先建立一张可调整的预算表。数字不是通用标准，应以线上测量和容量测试为依据；它的作用是迫使团队明确每一段时间花在哪里。

网关、鉴权和请求解析：10 ms
详情物化视图读取：25 ms
价格与库存动态字段：40 ms
推荐和营销模块：35 ms
结果拼装与序列化：30 ms
网络余量与降级判断：40 ms
总预算：180 ms

更适合评审和容量测试的形式是阶段预算表：

预算不能简单地被每个服务都复制一份。如果价格服务和库存服务各自要求 100 ms，详情页就不可能稳定满足 180 ms；如果推荐不是核心结果，就不应让它拥有一个“必须完成”的预算。工程上需要区分服务自己的处理预算、调用方等待预算和端到端用户预算。

预算还要包括排队、连接池等待、序列化、跨可用区网络、重试和熔断判断。很多系统在单次调用压测中很快，在混合查询和高并发下却变慢，原因正是这些共享资源没有被计入阶段预算。真正的预算应来自分阶段 trace，而不是来自每个服务负责人对自己接口的主观估计。

8.2.3 指标体系

点击率和转化率只能作为业务信号，不能直接替代技术指标。一个推荐结果点击率下降，可能是排序质量问题，也可能是延迟变高导致用户根本没有看到完整结果；一个搜索空结果率上升，可能是索引构建失败，也可能是查询改写或过滤规则发生变化。指标必须能沿着请求 ID、查询版本、索引版本和策略版本回溯到具体阶段。

质量指标也不能只看一个总平均值。推荐系统需要观察候选覆盖、长尾覆盖、重复率、曝光分布和用户负反馈；搜索系统要观察无结果 Query、错误召回、首条点击和满意度；Feed 要观察新鲜内容比例、重复内容比例和游标连续性。美团公开的搜索排序实践将数据层、召回层、粗排、精排、重排和展示层拆开，并以分层架构平衡排序效果和性能，这种拆分也便于分别定义质量与延迟指标。[14][15]

8.2.4 数据新鲜度要写成业务契约

“近实时”不是指标。应针对不同字段定义窗口：商品标题允许延迟几十秒，价格可能只允许几秒，库存可能必须在下单校验时回源，推荐特征可能允许分钟级延迟，广告预算则需要更严格的扣减语义。

同一个页面也可能同时存在不同新鲜度：商品描述可以读缓存，价格和库存必须读取受控的动态服务，推荐搭配可以使用旧候选集。页面级“全局一致”往往不是必要目标，字段级新鲜度契约才更容易落地。契约至少要包含数据源、允许年龄、版本含义、超时行为、回退值和恢复动作。

可以把读结果的状态划分为：当前版本、可接受旧版本、超过窗口但仍可展示、禁止展示和未知状态。这样，服务不是简单返回一个对象，而是返回对象、来源版本、生成时间、数据年龄和状态。调用方才能决定是继续展示、标注“正在更新”、回源校验，还是直接隐藏该字段。

8.3 核心模型：读模型是派生数据，查询模式决定数据结构

8.3.1 写模型和读模型承担不同职责

写模型主要保护领域事实、写入约束和业务事务；读模型主要服务检索、过滤、排序、聚合和展示。它们可能来自同一份原始数据，但不应被迫使用同一种数据结构。

一个典型的数据流是：

权威写模型
  → 变更事件 / CDC / Outbox
  → 索引、物化视图、候选集、特征库、缓存
  → 在线复杂读服务

读模型是派生数据，因此必须记录来源版本、更新时间、构建状态和失败原因。出现异常时，系统才能知道某条结果是源数据、旧版本派生数据，还是降级数据。数据系统的设计通常要区分系统记录与派生数据：派生数据可以被重建，但必须有明确的重建输入、顺序和校验方式。[2]

8.3.2 从事实到结果的统一数据模型

复杂读可以拆成六类对象：

权威性只属于明确承担业务约束的事实源。索引中的价格可以帮助展示和排序，但它不是结算价格；搜索结果中的库存标签可以帮助用户筛选，但不能替代下单时的库存校验；推荐缓存中的广告候选可以参与竞价，但不能替代预算扣减。把派生数据误当权威数据，是复杂读系统最危险的边界错误。

8.3.3 复杂读的统一管道

搜索、推荐、广告和 Feed 虽然业务不同，但可以用一条统一管道理解：

请求解析
  → 查询改写 / 权限过滤
  → 候选召回或索引检索
  → 规则过滤
  → 特征读取
  → 粗排 / 精排 / 重排
  → 去重、分页、拼装
  → 缓存、降级与结果解释

每个阶段都可能成为瓶颈。只优化搜索引擎而忽略排序，或者只提高缓存命中率而忽略回源风暴，都不能保证端到端延迟。

每个阶段还要说明它可以放弃什么。例如，召回可以只保留高置信度候选，粗排可以使用较低成本的模型，精排可以限制候选数量，重排可以在超时后跳过；但权限、删除、合规和核心事实校验不能因为延迟紧张而被静默跳过。分层的价值不是把一个服务拆成很多服务，而是让质量、延迟和失败语义能够分别治理。

多路召回通常需要先并行得到候选，再做去重、配额、粗排和精排。候选数量应当是可计算的资源预算，而不是越多越好：候选越多，排序特征读取、模型推理和去重成本越高；候选过少，又会造成质量天花板。腾讯公开的推荐系统资料也将召回理解为从海量物品中快速筛选小候选集，再进入排序阶段，并强调不同召回策略应根据业务和成本组合。[17][18]

8.3.4 预计算不是偷懒，而是把成本转移到可控路径

当结果可以提前准备时，应优先考虑：索引文档、物化详情、聚合统计、候选集、商品热度、用户画像和模型特征。

预计算获得的是更短的请求路径，但牺牲了部分实时性和更新链路的简单性。因此必须同时设计：更新触发、失败重试、版本传播、重建索引、旧版本回退和热点强刷。

批处理和流处理的价值不是让所有事情都异步，而是把可重复、可并行、对请求上下文不敏感的工作移出用户请求路径。Google 的 MapReduce 工作说明了大规模数据处理可以通过批量任务、分片和失败重试来完成；在复杂读系统中，这类离线能力常被用来生成索引、候选和统计特征。[3] 预计算不是“把一致性问题消失”，而是把它从用户请求中移动到可观测的传播链路。

8.3.5 缓存的语义比命中率更重要

缓存设计至少应回答：

• 缓存的是事实、派生结果还是临时计算结果？
• 允许陈旧多久？
• 失效由谁触发？TTL 和主动失效冲突时谁优先？
• 热点失效后如何防止所有请求同时回源？
• 缓存不可用时是否有更慢但正确的路径？
• 缓存命中时是否需要校验版本或业务状态？

Redis 官方文档将 cache-aside 定位为以 TTL 约束陈旧窗口、降低主数据库读压力的模式，同时提醒热点失效会造成缓存击穿。[12] Facebook 的 Memcache 工程实践进一步说明，大规模缓存系统会涉及一致性、失效、复制、故障转移和负载均衡；当缓存承担了过多职责时，缓存本身可能从“加速层”变成系统必须依赖的状态层。[4]

因此，缓存命中率只能回答“多少请求没有回源”，不能回答“返回的结果是否可信”。应同时记录数据年龄、命中来源、版本差距、回源原因和回源结果。对于价格、库存、权限、删除标记等高风险字段，命中缓存后仍可能需要短路校验或版本校验；对于商品描述、图片和推荐搭配，可以允许更长的陈旧窗口。

8.3.6 分页、候选和排序也属于数据模型

复杂读的分页不是界面层的小功能。offset 分页需要先跳过前面大量结果，随着页码增加，查询和排序成本可能持续上升；在数据变化时，offset 还可能导致重复或漏项。对稳定排序的搜索结果，可以使用基于排序值和唯一 ID 的游标；Elasticsearch 的 search_after 文档将游标式分页用于深分页场景，并要求调用方维护一致的排序条件和游标语义。[11]

游标必须绑定查询版本、排序版本、过滤条件摘要和过期时间，否则用户翻到下一页时，前后两次请求可能已经使用了不同的排序逻辑。Feed 还应保存时间线快照或游标生成时间，避免热点内容插入导致一条内容在不同页重复出现。推荐结果则要保存去重和曝光过滤所需的窗口，不能只缓存一个没有上下文的 ID 列表。

8.4 参考架构：从写入传播到在线读路径

8.4.1 写入侧：构建派生读模型

写入侧可以采用以下流程：

1. 权威服务在本地事务内提交业务事实。
2. 通过 Outbox、CDC 或事件日志发布变更。
3. 索引构建器更新搜索文档。
4. 物化视图构建器更新详情和聚合结果。
5. 特征计算任务更新在线特征或候选集。
6. 缓存刷新器主动刷新热点数据，长尾数据按需加载。
7. 记录版本号、更新时间、失败原因和重建进度。

写入传播失败不能直接覆盖权威事实，也不能让读模型无限重试。应使用重试、死信、全量重建和差异校验保证最终收敛。

8.4.2 在线侧：围绕预算执行

在线请求可以按以下顺序处理：

接收请求
  → 识别场景和优先级
  → 命中结果缓存或本地缓存
  → 未命中时执行检索 / 召回
  → 并行读取必要特征
  → 在预算内执行排序
  → 拼装核心结果
  → 超时则跳过非核心依赖并返回降级结果

关键依赖应设置独立超时，禁止使用一个全局超时掩盖内部预算失控。依赖失败时，应该知道哪些字段可空、哪些字段可以使用旧值、哪些结果必须直接失败。

8.4.3 各类系统的主要差异

不同系统的共同架构不能抹平业务边界。推荐可以接受旧候选，但不能展示已下架内容；广告可以使用预计算候选，但不能无视预算和频控；详情页可以展示旧描述，但不能把超过允许窗口的库存当成可购买事实。读路径必须在“速度”和“业务安全”之间明确红线。

8.5 方案选型：用 ADR 记录延迟、质量和新鲜度的取舍

8.5.1 典型方案的获得与牺牲

方案比较不能只写“推荐使用某组件”，而要写清楚当前约束下的优先级。直接查交易库得到的是事实新鲜和开发简单，但复杂排序、聚合和热点会争抢写资源；索引得到的是查询性能和横向扩展，但必须接受传播延迟；物化视图得到的是短读路径，但要付出重建、版本和差异校验成本。CQRS 的核心也不是增加一个读库，而是承认同一业务数据的写入组织方式和读取组织方式可能不同，并为两侧建立明确的同步边界。[7]

ADR 中的“获得 / 牺牲”应使用同一组维度比较，例如一致性、新鲜度、延迟、吞吐、质量、成本、复杂度、可运维性和恢复能力。若方案不能保证某项能力，应直接写出，而不是用“最终一致”把具体窗口隐藏起来。每个决策还应给出验证指标和重新评估条件，让 ADR 成为可被后续数据推翻的工程假设，而不是上线前的形式文档。

8.5.2 示例 ADR：商品发现采用索引 + 物化详情 + 动态事实校验

背景：商品搜索需要关键词、过滤和排序；详情页需要拼装商品、价格、库存、营销和推荐；商品信息更新频率低于读请求，但价格和库存变化更快。

决策驱动因素：搜索和详情不能持续回源交易库；价格和库存不能完全依赖陈旧缓存；读链路需要在高峰时降级，且搜索结果必须能说明索引延迟。

候选方案：所有查询直接查交易库、全量 Redis 缓存、搜索索引承担全部字段、CQRS + 物化视图、搜索索引与动态事实服务组合。

最终决策：商品主数据构建搜索索引；详情页使用物化视图减少多源拼装；价格和库存作为动态字段由受控服务校验；推荐和营销属于可降级模块；索引和物化视图通过事件传播并记录版本。

获得的能力：

• 复杂查询不再挤压交易库。
• 搜索、详情和推荐可以按查询模式独立扩展。
• 页面核心字段与非核心字段可以分级处理。
• 价格和库存不会因为页面缓存而完全失去事实约束。
• 发生索引延迟时可以通过版本和更新时间解释。

主动牺牲的能力：

• 商品修改不会在所有读模型中瞬时可见。
• 需要维护事件传播、索引重建、物化视图和缓存失效。
• 页面数据来自多个版本，短时间内可能出现字段之间的新鲜度差异。
• 系统不能只靠数据库事务保证完整读结果一致。

已接受风险与补救：索引延迟可能导致搜索结果短暂缺少新商品，通过索引延迟监控、热点强刷和全量重建补救；价格或库存服务超时时，页面只能展示基础信息，并标注暂不可购买；缓存失效可能造成回源压力，通过单飞、随机 TTL、本地兜底和按优先级限流保护数据库。

验证指标：索引 P99 延迟、商品详情缓存命中率、价格和库存动态字段超时率、页面整体 P99、非核心模块降级率、过期数据比例和搜索空结果率。

重新评估条件：索引重建窗口超过业务新鲜度要求、动态字段请求成为页面主要瓶颈、缓存回源成本超过独立读模型成本，或业务需要读己写和强新鲜度保证。

8.5.3 Fanout 的 ADR 判断

Feed 不能只问“写扩散还是读扩散”，而应按用户关系规模、内容热点、读写比例、允许延迟、存储放大和删除语义综合判断。

• 普通用户关注关系稳定、读取频繁时，写扩散可以换取更短的读路径。
• 超级节点粉丝数巨大时，写扩散会造成不可接受的写放大，应转为读扩散或混合策略。
• 混合策略获得了更好的总体平衡，但牺牲了实现简单性，需要维护两套路径和去重规则。
• 内容删除、权限变化和用户拉黑必须能够影响已经生成的时间线，不能因为写扩散完成就认为结果永久有效。

Facebook 的 TAO 论文展示了面向固定访问模式的读优化图存储：它在持久化存储之上提供图关系访问和缓存，以低延迟服务大规模社交图；但它也明确选择了适合业务的有限一致性，而不是把所有关系读取都变成强一致事务。[5] 这个例子说明，读优化存储的价值来自清晰的访问模式和接受边界，而不是来自某个产品名称。

8.6 完整案例：商品搜索与详情页的读路径设计

8.6.1 写入到读模型

假设一个电商平台有商品主数据、价格、库存、营销、评价和推荐搭配六类信息。用户输入关键词进入搜索列表，再点击商品进入详情页。系统要满足以下假设性约束：搜索列表优先保证相关性和响应速度；静态商品信息允许几十秒内收敛；价格和库存必须在下单前重新校验；推荐和营销可以在高峰时跳过；新发布商品需要在可接受窗口内进入搜索。

商品的读状态不应只有“存在 / 不存在”，而应至少包含源版本、索引版本、详情视图版本、价格版本、库存版本和生成时间。商品主数据事件携带 product_id、source_version、event_type、occurred_at；每个派生消费者维护自己的 applied_version。当事件乱序到达时，旧版本只能被记录为过期事件，不能覆盖已经应用的新版本。

商品服务提交商品、类目、属性和展示状态后，在同一业务事务中写入变更记录。事件发布器将变更发送到索引、详情物化、推荐特征和缓存刷新任务。流程可以表示为：

商品权威库
  → 商品版本 V42
  → 变更事件 product.updated(V42)
  ├─→ 搜索索引：文档版本 V42
  ├─→ 详情物化：视图版本 V42
  ├─→ 推荐特征：候选 / 属性版本 V42
  └─→ 热点缓存：按需刷新或标记失效

每个派生结果都携带商品版本号。索引服务更新失败时，商品仍然保留在权威库；详情物化失败时，系统可以返回上一个完整视图并记录版本差距；价格或库存变化时，可以只更新动态字段，避免重建完整详情。对高热度商品，事件系统可以提升优先级，但不能无限制地让热点重建任务挤压全量恢复任务。

事件传播的可观测性至少包括：源版本到索引版本的差值、事件进入队列时间、消费者处理时间、重试次数、死信数量、单商品重建耗时和最近一次全量校验结果。版本水位比单纯的“消息消费成功率”更能说明用户是否已经看到更新。

8.6.2 搜索请求

搜索请求首先解析关键词、过滤条件、排序方式、地域和分页游标。查询理解阶段可以做同义词、实体和意图处理，但必须记录改写后的 Query，避免出现“用户搜什么”和“系统实际查什么”无法解释的问题。索引负责召回和过滤，排序字段尽量提前写入文档；聚合和高成本统计必须有独立预算。

多路召回可以包括文本匹配、类目过滤、地理距离、热门商品、个性化候选和向量召回。各路召回先并行得到候选，再经过去重、配额、粗排和精排。美团搜索公开文章将召回、粗排、多路融合、精排和重排拆成不同层次，并指出多业务场景需要在效果与性能之间做配额和截断，这正是复杂读系统需要保留的工程边界。[14]

深分页不能无限依赖 offset，因为跳过大量结果会放大查询成本。更稳定的方式是使用游标或基于排序键的连续读取，并把游标绑定到查询版本、排序规则和过期时间。

搜索结果不是商品事实本身。价格、库存和活动资格如果属于强业务约束，展示层可以使用索引中的近似值，但下单前必须回到权威服务重新校验。搜索结果还要记录结果生成时间和索引版本；当用户投诉“新商品搜不到”时，系统应能回答是商品尚未发布、事件未投递、索引未刷新，还是查询过滤规则排除了它。

8.6.3 详情页请求

详情页可以把字段分成三组：

• 核心静态字段：商品标题、图片、规格和描述，可进入物化视图和长 TTL 缓存。
• 动态交易字段：价格、库存、优惠资格，需要更短的新鲜度窗口或实时校验。
• 非核心增强字段：推荐搭配、评价摘要、猜你喜欢，可以独立超时和降级。

请求到达后先读详情物化视图，再并行读取动态价格和库存；推荐和营销模块拥有独立的等待预算。若动态服务在预算内返回，页面附带当前版本；若超时，页面可以返回静态字段，但必须将商品状态标为“价格或库存正在更新”，不能把旧值渲染成仍然可下单的事实。

缓存策略也应按字段拆开。整页缓存命中快，但容易把价格、库存和推荐全部绑定在同一个 TTL 上；局部缓存更容易表达不同新鲜度，却增加拼装复杂度。商品描述和图片可以使用物化详情缓存，价格和库存使用短 TTL 快照或受控服务，用户个性化推荐则使用候选集缓存加实时过滤。

8.6.4 推荐与广告的映射

推荐系统通常采用召回、粗排、精排和重排分层。YouTube 推荐论文公开描述了候选生成模型与排序模型分离的两阶段结构，说明“把所有候选都交给一个大模型一次性排序”通常不是可扩展的在线方案。[6] 推荐候选可以来自用户历史、相似商品、内容标签、热门池和实时行为；候选层追求覆盖与速度，排序层才承担更昂贵的个性化计算。

推荐结果进入详情页时，还要执行商品下架、地域限制、已购买、曝光频控和库存状态过滤。推荐特征可以准实时，商品可售状态却不能因为旧候选而失效。推荐服务超时可以返回热门搭配或空模块，但不能让它占用价格和库存的核心预算。

广告请求还要加入预算、定向、频控、出价和合规过滤。它不是简单的推荐排序：候选相关性、商业约束和预算事实必须分层处理。推荐候选可以预计算，广告预算扣减则需要更严格的事实控制；如果预算服务超时，宁可减少广告候选或返回保底广告，也不应无界重试。

8.6.5 Feed 和热点内容的变体

Feed 场景的核心不是单条内容查询，而是把用户关系、时间顺序、内容质量和热点扩散合并成一条可分页的时间线。普通用户可以使用 Fanout-on-write，把新内容提前写入关注者的时间线；超级节点或热点内容则更适合 Fanout-on-read，在读取时合并。

混合方案需要额外处理三个问题：

• 同一内容可能同时来自用户时间线、热点池和推荐候选，必须按内容 ID 去重。
• 内容写入和删除传播存在延迟，必须在读取时执行最小权限和状态过滤。
• 时间线不能只依赖 offset 分页，否则新内容插入会导致重复或漏读；应使用带版本或时间边界的游标。

因此，Feed 的 ADR 往往不是“选择写扩散”或“选择读扩散”，而是按用户类型、内容热度和资源成本选择不同路径。获得的是总体吞吐和延迟的平衡，牺牲的是两套数据路径、去重逻辑和一致性治理的复杂度。内容删除、权限变化和用户拉黑必须能够影响已经生成的时间线，不能因为写扩散完成就认为结果永久有效。速度来自预组织数据，但业务有效性仍然需要在线检查。

8.7 故障与治理：允许结果降级，不允许系统失控

8.7.1 缓存故障：击穿、穿透和雪崩要分开处理

缓存故障至少有三种形态：

• 击穿：单个热点 Key 过期或失效，瞬间大量请求回源。
• 穿透：请求的对象不存在或参数非法，反复绕过缓存访问后端。
• 雪崩：大量 Key 同时失效，或缓存集群整体不可用，造成回源洪峰。

三者的保护手段不同。击穿需要 Singleflight、互斥重建、逻辑过期或热点预热；穿透需要参数校验、空值短缓存、布隆过滤器和访问限流；雪崩需要 TTL 打散、多级缓存、容量预留、故障切换和按优先级降级。中文工程资料对这三类问题的区分和治理有较多实践总结，但具体阈值必须根据业务流量和数据分布测量，不能把示例配置当成通用标准。[20]

缓存故障时，降级路径必须在正常设计中就存在。可以读取上一次成功的静态结果、切换到本地快照、只返回核心字段或限制长尾查询；不能在缓存故障后临时发明一套更复杂的“备用实时计算”，否则所谓 fallback 可能比原路径更容易失败。AWS 的优雅降级建议将部分硬依赖转为软依赖，在下游延迟或错误时返回最后一次成功值或简单静态结果，同时避免用复杂的替代机制扩大故障面。[10]

8.7.2 索引和物化视图延迟

索引延迟不是一个单一指标，应区分事件未产生、事件未投递、消费者积压、文档更新失败、刷新未完成和查询侧版本过旧。每一层都要记录水位：源版本、队列版本、构建版本、已刷新版本和查询返回版本。

出现延迟时，先保护业务，再修复派生数据。热门商品可以执行定向强刷，长尾商品等待队列自然收敛；索引构建失败进入重试或死信，持续失败进入全量重建；详情页可以使用上一完整版本，但在超过陈旧窗口后改为基础字段或不可购买状态。不要在所有请求上同步等待索引追平，否则一处传播延迟会变成全站读延迟。

全量重建也需要限速和校验。重建任务应使用独立资源，不能与在线查询抢占全部 CPU 和磁盘；新索引应先在旁路完成校验，再通过别名或版本指针切换；切换后保留旧索引一段时间，以便在字段映射或数据清洗错误时回滚。重建完成的标准不是任务结束，而是版本差距、文档数量、关键字段覆盖率和抽样比对都通过。

8.7.3 过载、重试和部分依赖失败

过载时最危险的行为通常是无条件重试。一次页面请求同时调用多个依赖，若每个依赖超时后再重试，实际请求量会迅速超过入口 QPS。Google SRE 的过载治理强调，系统应结合 CPU、队列、连接池和下游健康度进行负载削减，而不是只看请求数；级联失败往往是健康实例减少、排队增长和重试放大的结果。[8][9]

读链路应建立分级降级：

1. 关闭高成本特征和非核心排序；
2. 减少召回深度、聚合数量和 Feed 扩散范围；
3. 优先返回缓存、上一版本或热门兜底结果；
4. 对长尾 Query、深分页和低优先级调用限流；
5. 只有在核心事实无法可靠返回时，才返回明确错误。

降级需要有状态、原因和恢复条件。不能只在日志中打印 fallback=true，还要知道是缓存故障、排序超时、索引滞后、过载保护还是策略主动降级。恢复时先小流量探测，再逐步放开候选数、特征和非核心依赖，避免流量恢复本身再次冲垮系统。

8.7.4 可观测性、质量回放与容量治理

复杂读系统应把一次请求拆成可关联的 trace：入口、查询改写、召回、候选过滤、特征读取、排序、拼装、缓存和降级。每阶段记录候选数量、耗时、版本、命中情况和错误原因；不要只记录最终总耗时，因为总耗时无法回答“是索引慢还是模型慢”。OpenTelemetry 的 trace、metric 和 log 关联能力可作为统一观测入口。[13]

质量治理需要保存 Query、召回源、过滤原因、排序版本、曝光列表和用户反馈，但要遵守隐私和数据保留边界。对搜索可以做 bad case 回放，对推荐可以做离线候选覆盖与线上 A/B 对比，对 Feed 可以检查重复、顺序和删除生效。美团公开的搜索质量实践强调把结果质量分层诊断，区分供给存在但链路未召回、召回后被过滤、排序失配和展示问题，这种诊断思路适合迁移到复杂读平台。[16][19]

容量治理不能只做峰值 QPS 压测，还要做混合请求、热点倾斜、缓存冷启动、索引重建、依赖超时、节点丢失和降级恢复测试。测试结果应记录资源曲线和拐点：在什么利用率下 P99 开始非线性上升，队列多长时需要拒绝，候选数量降低多少会影响质量，缓存恢复需要多长时间。没有这些边界，SLO 只是一个愿望数字。

8.7.5 读己写、版本和陈旧数据解释

复杂读系统不能只用“缓存是否命中”解释结果，还要能解释结果对应哪个版本。用户刚修改商品、刚发布内容或刚完成关注操作后，常常会期待读己写；如果系统无法做到全局即时可见，就应通过版本标记、请求会话版本或局部回源保证关键页面的可见性。

一种常见做法是让写请求返回变更版本，后续读请求携带该版本。读模型若尚未追上版本，可以短暂回源、等待有限时间、读取同一主分片，或者返回明确的处理中状态；不能无限阻塞，也不能静默承诺已经生效。版本等待必须受预算约束，否则“读己写”会变成一条不受控的同步链路。

对于允许陈旧的数据，应记录数据年龄和来源版本。页面可以展示旧的推荐候选，但价格、库存、权限和内容删除状态不能被普通缓存掩盖。这样“不一致”就从一个无法解释的异常，变成具有时间窗口、版本号和处理策略的业务状态。

8.8 方法论总结

8.8.1 十个判断句

1. 低延迟不是某个缓存或搜索引擎的能力，而是端到端预算、并行边界和降级策略共同产生的结果。
2. P99 比平均延迟更能暴露复杂读系统的真实体验；请求扇出越大，越需要治理最慢依赖和共享资源排队。
3. 查询模式决定读模型，写模型不应该被强行复用到所有读取场景；但读模型必须保留来源、版本和重建能力。
4. 能预计算的不要在线计算，能缓存的不要重复计算，但任何预计算和缓存都必须定义陈旧、失效、回源和恢复语义。
5. 搜索、推荐、广告和 Feed 都应拆成召回、过滤、排序、拼装和降级阶段；拆分是为了预算和治理，不是为了增加服务数量。
6. 候选数量、特征维度和排序层级都是资源预算，结果质量提升必须与额外 CPU、网络、存储和延迟成本一起评估。
7. 一致性要按字段和业务动作定义窗口，而不是对整个页面做笼统承诺；价格、库存、权限和删除状态应有更严格的在线校验。
8. 读系统的降级目标是保护核心结果和整体可用性，不是无条件保留所有增强功能；降级还必须带原因、等级和恢复条件。
9. 方案选型必须通过 ADR 说明获得了什么、牺牲了什么、失败后如何收敛，以及什么条件下重新评估。
10. 一次设计评审至少要追问：权威事实是什么、读模型如何生成、延迟预算在哪里、陈旧多久可接受、热点怎样保护、失败如何解释、结果如何重建。

8.8.2 读链路评审清单

8.8.3 一句话表达

低延迟与复杂读系统设计的核心，不是让所有请求实时回源并现场完成全部计算，而是围绕查询模式构建派生读模型，用索引、缓存、预计算、分层排序、延迟预算和可控降级，把复杂结果稳定地压进用户可接受的时间窗口。

8.9 参考资料

[1] Jeffrey Dean, Luiz André Barroso, “The Tail at Scale”, Communications of the ACM, 2013。

[2] Martin Kleppmann, Chris Riccomini, Designing Data-Intensive Applications, 2nd Edition, O’Reilly, 2026。

[3] Jeffrey Dean, Sanjay Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters”, OSDI, 2004。

[4] Rajesh Nishtala et al., “Scaling Memcache at Facebook”, 10th USENIX Symposium on Networked Systems Design and Implementation, 2013。

[5] Nathan Bronson et al., “TAO: Facebook’s Distributed Data Store for the Social Graph”, 2013 USENIX Annual Technical Conference, 2013。

[6] Paul Covington, Jay Adams, Emre Sargin, “Deep Neural Networks for YouTube Recommendations”, ACM Conference on Recommender Systems, 2016。

[7] Martin Fowler, “CQRS”, Martin Fowler’s Bliki。

[8] Google SRE, “Handling Overload”, Site Reliability Engineering。

[9] Google SRE, “Addressing Cascading Failures”, Site Reliability Engineering。

[10] AWS, “REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies”, AWS Well-Architected Framework。

[11] Elastic, “Paginate search results”, Elasticsearch Reference。

[12] Redis, “Redis cache-aside”, Redis Documentation。

[13] OpenTelemetry, “Documentation”, OpenTelemetry Project。

[14] 美团技术团队，《多业务建模在美团搜索排序中的实践》，2021。

[15] 美团技术团队，《深入浅出排序学习：写给程序员的算法系统开发实践》，2018。

[16] 美团技术团队，《美团点评旅游搜索召回策略的演进》，2017。

[17] 腾讯云开发者社区，《业内推荐系统架构介绍》，2019。

[18] 腾讯云开发者社区，《推荐系统的召回》，2018。

[19] 美团技术团队，《美团综合业务推荐系统的质量模型及实践》，2022。

[20] 阿里云开发者社区，《深入解析 Redis 缓存击穿穿透雪崩的解决方案》，2024。