倒排索引 (Inverted Index)

面试回复话术：

“ES 之所以能实现毫秒级的全文检索，核心在于倒排索引。
简单来说，传统数据库（如 MySQL）是‘文档 -> 关键词’的映射，查找时需要全表扫描或模糊匹配（like ‘%abc%’），效率极低。
而 ES 是‘关键词 -> 文档列表’的映射。
具体流程是：

1. 分词：将文本（如‘商旅订单’）拆解为独立的词项（‘商旅’、‘订单’）。
2. 建立词典与倒排表：记录每个词项出现在哪些文档 ID 中。
3. 查询优化：搜索时，直接定位词项，通过位图（Bitmap）快速求交集或并集。

在商旅系统中，用户搜索‘北京 机票’，ES 会分别找到包含‘北京’和‘机票’的文档 ID 集合，取交集后瞬间返回结果。”

技术应用场景：

• 场景：复杂的订单搜索。
• 需求：用户需要按“订单号”、“乘客姓名”、“出发地”、“目的地”组合搜索。
• 实现：
  • Text 类型：用于“目的地”、“备注”，进行分词匹配（Match Query）。
  • Keyword 类型：用于“订单号”、“状态”，进行精确匹配（Term Query）和聚合统计。

架构与分片 (Node, Shard, Replica)

面试回复话术：

“ES 是一个分布式系统，其核心扩展性依赖于分片（Shard）和副本（Replica）。

• 分片：为了解决单机存储和性能瓶颈，索引数据被水平切分到多个分片上。在创建索引时，我通常会预估数据量，设置合理的主分片数（如 5 个），因为分片数一旦设定不可修改（除非重索引）。
• 副本：为了高可用，每个主分片可以有多个副本。副本不仅提供数据冗余（主分片挂了副本自动晋升），还能分担读压力（查询可以在所有副本上负载均衡）。

写入流程：
客户端请求 -> 协调节点（Coordinator） -> 根据路由哈希定位主分片 -> 主分片写入并转发给副本 -> 副本确认后返回成功。

搜索流程（Query Then Fetch）：

1. Query 阶段：协调节点将请求广播给所有相关分片，分片本地查询并返回 Top N 结果（ID 和 排序值）。
2. Fetch 阶段：协调节点汇总结果，进行全局排序、截断，再向相关分片请求具体的文档数据（Source），最后返回给客户端。”

技术应用场景：

• 场景：海量日志分析。
• 问题：单索引数据量过大（如超过 50GB），导致查询变慢。
• 解决：使用 索引生命周期管理（ILM） 和 滚动索引（Rollover）。按天创建索引（如 logs-2023.10.01），当索引过大或时间到期自动切换到新索引，旧索引定期合并（Force Merge）或删除。

---

核心难题与解决方案 (Java 技术视角)

深度分页 (Deep Paging)

面试回复话术：

“在 ES 中，深度分页（如 from=10000, size=10）性能非常差，因为协调节点需要从每个分片收集 from + size 条数据，排序后再丢弃前面的，内存和网络开销巨大。
解决方案：

1. Search After（推荐）：适用于实时游标翻页。记录上一页最后一条数据的排序值（如时间戳+ID），下一页查询时带上这个值。这在 Java 代码中通过 SearchAfterBuilder 实现。
2. Scroll API：适用于全量导出。它生成一个快照上下文，适合后台批处理，但不适合实时用户查询。”

技术应用场景：

• 场景：运营后台导出大量订单报表。
• 实现：使用 Scroll 机制，每次拉取 1000 条，处理完释放上下文，避免内存溢出（OOM）。

数据一致性 (Data Consistency)

面试回复话术：

“ES 是近实时的（默认刷新间隔 1s），且与 MySQL 是异构数据源，容易出现数据不一致。
我的同步方案是：

1. 同步双写（不推荐）：代码简单，但容易因为网络抖动导致不一致。
2. 异步同步（推荐）：
   • Canal + MQ：监听 MySQL 的 Binlog，解析后发送到 MQ，消费者再写入 ES。这解耦了业务，且保证了最终一致性。
   • Logstash：如果是日志数据，直接使用 Logstash 采集文件推送到 ES。
3. 兜底机制：定期运行校验脚本（如每天凌晨），对比 MySQL 和 ES 的关键数据，发现不一致则触发修复。”

技术应用场景：

• 场景：商品/订单搜索。
• 流程：订单服务更新 MySQL -> 发送 MQ 消息 -> 搜索服务消费 MQ -> 更新 ES 文档。

---

综合应用场景：海量日志检索与复杂商品搜索

场景一：商旅系统的日志分析 (ELK Stack)

背景：微服务架构下，每天产生 GB 级的日志，排查问题困难。
解决方案：

• 架构：Filebeat (采集) -> Kafka (缓冲) -> Logstash (过滤/格式化) -> Elasticsearch (存储/索引) -> Kibana (展示)。
• Java 开发配合：
  • 在代码中使用 MDC (Mapped Diagnostic Context) 注入 TraceId。
  • 这样在 Kibana 中搜索一个 TraceId，就能串联起该请求在所有微服务中的完整调用链路，极大缩短故障排查时间。

场景二：复杂的机票/酒店搜索

背景：用户需要根据“价格区间”、“起飞时间”、“航司”、“经停次数”进行多维度筛选和排序。
解决方案：

• 数据结构设计：
  • flight_no (Keyword): 精确匹配。
  • description (Text): 全文检索（支持模糊搜航司名）。
  • price (Integer/Double): 范围查询 (Range Query) 和排序。
  • departure_time (Date): 范围查询。
• 聚合分析 (Aggregation)：
  • 利用 ES 的 Bucket Aggregation 实现“分面搜索”。例如，统计每个航司有多少个航班（Term Aggregation），或者统计价格分布（Range Aggregation），直接在搜索结果页左侧展示筛选条件。

模拟面试问答示例

Q: 你们的 ES 集群遇到过性能瓶颈吗？怎么优化的？

A:

“遇到过。在一次大促活动中，运营人员进行了一个非常复杂的聚合查询（统计所有订单的销售额并按地区分组），导致 ES 集群 CPU 飙升，甚至影响了正常的搜索服务。

排查与优化过程：

1. 定位慢查询：通过 ES 的 Slow Log 和 Profile API，发现该查询涉及大量字段的聚合，且使用了 fielddata，导致堆内存压力极大。
2. 优化 Mapping：将聚合字段设置为 doc_values（默认开启），关闭不必要的 fielddata。
3. 冷热分离：我们将历史订单数据迁移到‘冷节点’（HDD 磁盘），热数据保留在‘热节点’（SSD 磁盘）。
4. 路由优化：对于特定用户的订单查询，我们在写入时指定了 routing（路由键，如 userId）。查询时也带上 routing，这样请求只会打到包含该用户数据的一两个分片上，而不是广播到所有分片，性能提升了数倍。

通过这次优化，我们不仅解决了 CPU 飙升问题，还将核心搜索接口的响应时间稳定在了 200ms 以内。”