高频面试问题与回答框架
搜索引擎面试中，80% 的高频问题集中在倒排索引、查询处理、排序策略、分布式架构和性能优化五大领域。不同公司对考察侧重点有显著差异：百度侧重大规模检索系统与 Query 理解；阿里关注电商搜索排序与实时索引；字节强调倒排链合并与内存效率；腾讯偏向社交搜索与实时性。掌握通用回答框架 + 公司差异化准备，是面试决胜关键。
| 问题类型 | 典型考察点 | 重点公司 | 面试权重 |
|---|---|---|---|
| 倒排索引实现 | 词典结构、合并策略、压缩编码 | 百度、阿里、字节 | ★★★★★ |
| 查询处理与排序 | BM25、TF-IDF、Query改写 | 阿里、百度、美团 | ★★★★☆ |
| 分布式检索架构 | 分片路由、副本一致性、故障恢复 | 字节、腾讯、快手 | ★★★★★ |
| 性能瓶颈与优化 | 跳表加速、缓存策略、预计算 | 百度、阿里、字节 | ★★★★☆ |
| 实时索引与更新 | 增量索引、LSM Tree、Near-Real-Time | 腾讯、阿里、字节 | ★★★☆☆ |
问题1：请设计一个倒排索引，并说明如何支持 AND/OR 查询
面试官考察点：对倒排索引核心数据结构、跳表/位图加速、多条件求交/求并算法的理解。
回答框架：
① 确认需求（索引规模、实时性要求）→ ② 选择词典结构（Hash / Trie / FST）→ ③ 倒排链存储（文档ID + 词频 + 位置）→ ④ 求交算法（跳表 / BitSet / AND-OR 组合）→ ⑤ 时间复杂度与缓存策略。
简短示例回答：
“我会采用 FST 作为词典，压缩倒排链使用 Varint 编码。AND 查询时，选择最短链用跳表做双指针求交，O(m+n)；OR 查询先合并长链，用 Roaring Bitmap 压缩存储，跳过大量不命中文档。同时引入 LRU 缓存热查询结果。”
可能追问：
- 如果索引量 10 亿，跳表跳步怎么设计？
- 如何处理带权重的 AND/OR 逻辑？
- 实时更新索引时如何保证查询一致性？
问题2：说说 TiDB / Elasticsearch 的分片与副本机制，设计一套搜索引擎分片路由方案
面试官考察点：分布式一致性、哈希路由、副本同步、故障迁移经验。
回答框架：
① 明确分片粒度（按文档ID或关键词Hash）→ ② 路由算法（一致性哈希 + 虚拟节点）→ ③ 副本写策略（Quorum / Raft）→ ④ 扩容缩容数据搬迁方案 → ⑤ 读写链路分层设计（协调节点-数据节点）。
简短示例回答：
“我采用一致性哈希路由，每分片配置 3 副本，用 Raft 保证强一致性。写入时等待多数副本确认；查询从任意副本读取，配合版本号解决冲突。扩容时采用虚拟节点平滑迁移，利用后台线程逐步搬移数据块。”
可能追问：
- 一致性哈希可能出现倾斜，怎么解决？
- 副本之间数据一致性和查询性能如何权衡？
- 单分片故障如何自动恢复而不影响写入？
问题3：如何优化搜索引擎的 Top-K 查询性能？
面试官考察点：海量数据排序、堆/快速选择、剪枝策略、内存与磁盘权衡。
回答框架：
① 评估数据量级与内存限制 → ② 选择算法（堆排序 vs 快速选择 vs 外部排序）→ ③ 索引裁剪（提前终止、淘汰低分文档）→ ④ 分层加速（前置粗排 + 后置精排）→ ⑤ 多路归并合并各分片结果。
简短示例回答：
“先用 Max-Heap 维护 Top-K，大小固定为 K，避免全排序。配合倒排链的 skip 列表跳过低分文档；对于跨分片场景，各节点返回 Top-K 后，协调节点合并取全局 Top-K，复杂度 O(N log K)。同时利用缓存预加载热 Query 的 top 结果。”
可能追问：
- 如果 Top-K 的 K 很大（比如 10000），怎么优化？
- 如何保证排序结果的公平性（多样性/时效性）？
- 多路归并时每个分片返回多少结果才够？