百度 Java / 后端怎么准备
百度工程岗公开讨论里，检索链路的延迟预算很常见：召回、截断、排序、展示各占多少毫秒。
本页按漏斗、截断、缓存、降级和跨团队协作来练。没有搜索经历就用你做过的查询服务类比，并主动声明类比边界。
百度怎么面Java后端
- 会问你如何在超时下仍返回「还能看」的结果。
- 缓存题要区分倒排、正排和结果页缓存。
- 效果同学可能会追问你砍流量时伤了哪些指标。
面试阶段与知识点
第一批不把每个阶段拆成独立 URL，避免程序化重复页。阶段对应下面的题，练完再用模拟面试串起来。
- 检索漏斗：延迟预算和截断。
- 缓存层次：命中率与一致性。
- 降级：保可用性时如何少伤效果。
- 协作：和策略同学抢资源。
值得开口练的题
每题给考察点、思路、结构化参考答案和追问。参考答案用来组织语言，面试时必须换成你自己的项目事实。
检索链路总超时 200ms，哪一段该被截断？
考察点
- 预算分配
- 尾延迟
- 降级结果质量
回答思路
先要各段 P99 耗时分布，再砍最不伤体验的段，而不是平均切预算或一刀切空结果。
结构化参考答案
- 测量召回、粗排、精排、重排各环节的耗时分布，找出拖尾延迟的主要来源。
- 优先截断可并行的召回通道或缩小候选集，而不是超时后直接返回空白结果页。
- 给排序链路保留最小候选集保底，确保超时仍能返回可浏览的结果列表。
- 截断策略按查询类型区分，导航类和探索类查询的延迟预算和降级路径应不同。
面试官可能追问
- 如何避免截断让长尾查询永远变差？
- 尾延迟是 GC 还是下游？
- 截断要不要对用户可见？
热点 Query 的结果页缓存如何失效？
考察点
- 时效
- 正确性
- 击穿
回答思路
搜索结果不能永久缓存，但热点 Query 必须挡流量；失效策略要兼顾时效和击穿保护。
结构化参考答案
- 采用短 TTL 加主动失效：内容变更时发布新版本号，触发相关结果页缓存更新。
- 重建时使用单飞机制，避免同一热点 Query 并发回源把倒排或存储层打穿。
- 个性化排序部分不进公共页缓存，或只缓存非个性化层，减少脏读和隐私风险。
- 过期返回旧页若业务可接受，要打降级标记，便于后续效果分析和新鲜度评估。
面试官可能追问
- 突发新闻如何把 TTL 打到秒级？
- 缓存和索引更新谁先谁后？
- 如何衡量缓存伤害了新鲜度？
相关性服务挂了，工程侧怎么降级？
考察点
- 保底排序
- 通道开关
- 复盘指标
回答思路
降级方案必须预先写好并演练，不能等相关性服务挂掉后现场临时发明排序逻辑。
结构化参考答案
- 切换到粗排或静态质量分保底，保证用户仍能拿到有序结果列表而不是空白页。
- 关闭耗时特征计算，保留可解释的基础排序因子，控制 P99 在预算内。
- 对效果看板打降级标记，避免运维期间的保底结果被误判为模型效果变差。
- 服务恢复后回放抽样对比，确认没有脏缓存或未清理的降级状态残留。
面试官可能追问
- 降级期间商业广告怎么排？
- 谁有权限开降级开关？
- 如何演练？
倒排索引更新延迟导致搜不到刚发布内容，你怎么处理？
考察点
- 近线索引
- 可见性
- 用户预期
回答思路
发布者期望「刚发的能搜到」，这和全量索引成本冲突；要讲近线索引和可见性分层。
结构化参考答案
- 新内容写入近线索引通道，查询时与全量索引结果合并，缩短发布到可搜的窗口。
- 对发布者本人可提供更强可见性，对其他用户仍走主索引，平衡体验与成本。
- 监控从发布到可被检索的时间分布，异常延迟要能告警并定位到索引链路。
- 索引失败要有重试和死信处理，避免内容永久失踪却无任何运维感知。
面试官可能追问
- 近线通道被刷怎么办？
- 删除如何比插入更优先？
- 多机房索引不一致用户看到什么？
策略同学要加很重的特征，会把 P99 打爆，你怎么谈？
考察点
- 延迟预算
- 实验
- 折中
回答思路
用延迟预算和在线实验说话，不否定效果诉求；目标是找到可上线的折中路径。
结构化参考答案
- 展示当前链路各段延迟预算，以及该特征在线推理的实际耗时占比。
- 提出只在高价值查询或抽样流量上启用，并配套一键回滚和效果门槛。
- 要求策略同学提供在线增益证据，而不是只拿离线指标要求全量上线。
- 最终达成「先小流量证明增益再谈全量」的共识，避免 P99 被单次推全打爆。
面试官可能追问
- 如果离线增益很大但在线延迟不可接受呢？
- 你如何避免成为瓶颈角色？
- 冲突升级找谁？
和岗位、模拟面试一起用
资料管理里保存目标岗位 JD，模拟面试会按简历出题。点题目下的按钮会把本题带进模拟开场，仍需先绑定简历与岗位。