ElasticSearch高频面试题
ElasticSearch高频面试题
1、Elasticsearch是如何实现master选举的？
1、对所有可以成为master的节点根据nodeId排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
2、如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举。
3、对于brain split问题，需要把候选master节点最小值设置为可以成为master节点数n/2+1（quorum）。
Elasticsearch 7.x+ 选举机制详解：
Elasticsearch 的 master 选举基于 Zen Discovery 模块实现，
核心机制是"多数投票"（Majority Voting）。
选举流程：
1. 节点启动时，向集群中所有已知节点发送 Ping 请求
2. 每个节点将收到的其他节点信息加入自己的集群状态
3. 当节点发现当前没有 master 时，发起选举
4. 所有候选 master 节点按 nodeId 排序
5. 每个节点优先投票给排序后的第一个节点
6. 如果某个节点获得 quorum（n/2+1）票数，成为 master
脑裂防护（Split Brain）：
- 通过 minimum_master_nodes 参数控制
- 该值必须设置为候选 master 节点数的一半以上
- 例如 3 个 master 节点，minimum_master_nodes = 2
- 如果网络分区导致 2 个节点与 1 个节点断开，
只有 2 个节点的分区可以选举出 master
Elasticsearch 7.0+ 的变化：
- 移除了 minimum_master_nodes 配置
- 改为自动计算，基于 cluster.initial_master_nodes
- 简化了配置，减少了脑裂风险# Elasticsearch 7.x 配置示例
cluster.name: my-application
node.name: node-1
node.master: true # 可以成为 master 节点
node.data: true # 可以存储数据
# 初始 master 候选节点列表
cluster.initial_master_nodes:
- node-1
- node-2
- node-3
# 发现机制
discovery.seed_hosts:
- 192.168.1.10
- 192.168.1.11
- 192.168.1.122、详细描述一下 Elasticsearch 索引文档的过程。
1、当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 MemoryBuffer，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache，这个从 MomeryBuffer 到 Filesystem Cache 的过程就叫做 refresh；
2、当然在某些情况下，存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失，ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystem cache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；
3、在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。
4、flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M）时。
索引文档的完整流程图：
客户端写入请求
│
▼
┌─────────────────┐
│ 协调节点 │ → 路由计算：hash(_id) % num_primary_shards
│ (Coordinating │ → 确定目标分片
│ Node) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 主分片 │ → 写入 Memory Buffer
│ (Primary Shard) │ → 同时写入 Translog（预写日志）
└────────┬────────┘
│
▼
┌─────────────────┐
│ 副本分片 │ → 并行复制到副本分片
│ (Replica Shard) │ → 副本写入 Translog
└────────┬────────┘
│
▼
返回客户端确认
│
▼
┌─────────────────┐
│ Refresh │ → Memory Buffer → Filesystem Cache（默认1秒）
│ （可搜索） │ → 此时数据可以被搜索到（近实时）
└────────┬────────┘
│
▼
┌─────────────────┐
│ Flush │ → Filesystem Cache → 磁盘（默认30分钟或512MB）
│ （持久化） │ → 创建新段，清理旧 Translog
└────────┬────────┘
│
▼
┌─────────────────┐
│ Merge │ → 后台合并小段为大段
│ （段合并） │ → 减少段数量，提高查询效率
└─────────────────┘关键时间参数和配置：
# 索引性能优化配置
index:
refresh_interval: "30s" # 增大refresh间隔，减少段数量
number_of_replicas: 0 # 批量写入时临时关闭副本
translog:
durability: "async" # 异步写入translog，提高吞吐
sync_interval: "5s" # translog刷盘间隔
flush_threshold_size: "1gb" # translog刷盘阈值// .NET 中批量写入 Elasticsearch
var bulkResponse = await client.BulkAsync(b => b
.Index("products")
.IndexMany(products)
.Refresh(Refresh.WaitFor) // 等待refresh完成
.Timeout("60s")
);3、详细描述一下 Elasticsearch 更新和删除文档的过程。
1、删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更。
2、磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。
3、在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del 文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
更新和删除的底层机制：
Elasticsearch 文档不可变原则：
- 文档一旦写入磁盘上的Segment，就不可修改
- 所有修改操作（更新、删除）都是"追加式"操作
更新流程：
1. 接收更新请求（包含 _id 和新文档内容）
2. 在 .del 文件中标记旧版本文档为"已删除"
3. 将新版本文档写入新的Segment
4. 版本号递增（_version + 1）
5. 查询时，ES会过滤掉被标记删除的旧版本
删除流程：
1. 接收删除请求（包含 _id）
2. 在 .del 文件中标记该文档为"已删除"
3. 文档仍然存在于原始Segment中，但查询时被过滤
4. Segment合并时，被删除的文档才真正从磁盘移除
乐观并发控制：
- 每个文档有 _version 和 _seq_no 字段
- 更新时可以指定 if_seq_no 和 if_primary_term
- 如果版本号不匹配，返回 409 Conflict
// 通过版本号实现乐观并发
PUT /products/_doc/1?if_seq_no=5&if_primary_term=1
{
"name": "updated product name"
}
// 如果 seq_no 不匹配，返回冲突
{
"status": 409,
"error": {
"type": "version_conflict_engine_exception",
"reason": "[1]: version conflict"
}
}段合并（Segment Merge）策略：
段合并的触发条件：
1. Segment数量达到阈值（Tier Merge Policy）
2. 被删除文档占比过高
合并策略（Tier Merge Policy）：
- 每层最多 merge_factor（默认10）个段
- 段大小逐层指数增长
- 后台线程自动执行，不影响前台读写
合并对性能的影响：
- 合并期间消耗大量IO和CPU
- 大量删除后应及时触发合并
- 可以通过 force_merge API 手动触发
POST /products/_force_merge?max_num_segments=14、详细描述一下 Elasticsearch 搜索的过程？
1、搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
2、在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。
备注：在搜索的时候是会查询 Filesystem Cache 的，但是有部分数据还在 MemoryBuffer，所以搜索是近实时的。
3、每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
4、接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
5、补充：Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更准确，但是性能会变差。
搜索过程的详细图解：
Query Then Fetch 两阶段搜索：
=== 阶段一：Query（查询） ===
客户端请求：GET /products/_search?from=0&size=10
│
▼
┌──────────────────────┐
│ 协调节点 │ → 将查询广播到所有相关分片
│ (Coordinating Node) │
└──────┬───────────────┘
│
├──→ Shard 1: 执行查询，返回 Top 10 的 (_id, _score)
├──→ Shard 2: 执行查询，返回 Top 10 的 (_id, _score)
├──→ Shard 3: 执行查询，返回 Top 10 的 (_id, _score)
└──→ Shard 0: 执行查询，返回 Top 10 的 (_id, _score)
│
▼
协调节点合并所有分片的结果，
按 _score 排序，取全局 Top 10
=== 阶段二：Fetch（取回） ===
协调节点向相关分片发送 GET 请求
（只取最终 Top 10 对应的文档）
│
├──→ Shard 2: 返回文档 1, 3, 7 的完整内容
└──→ Shard 0: 返回文档 2, 5 的完整内容
│
▼
协调节点合并结果，返回给客户端深度分页问题及解决方案：
深度分页问题：
- from=10000, size=10 时
- 每个分片需要返回 10010 条结果给协调节点
- 如果有10个分片，协调节点需要处理 100100 条结果
- from越大，性能越差
解决方案：
1. Search After（推荐）
使用上一页最后一条文档的排序值作为游标
GET /products/_search
{
"size": 10,
"query": { "match": { "name": "手机" } },
"sort": [
{ "price": "asc" },
{ "_id": "asc" }
],
"search_after": [1999, "abc123"]
}
2. Scroll API（适合大量数据导出）
不适合实时搜索，适合后台任务
POST /products/_search?scroll=2m
{
"size": 1000,
"query": { "match_all": {} }
}
3. 限制最大分页深度
index.max_result_window: 10000（默认值）
// C# 中使用 Search After
var searchResponse = await client.SearchAsync<Product>(s => s
.Index("products")
.Query(q => q.Match(m => m.Field(f => f.Name).Query("手机")))
.Sort(sort => sort
.Ascending(f => f.Price)
.Ascending(f => f.Id))
.Size(10)
.SearchAfter(lastSortValues)
);5、Elasticsearch 对于大数据量（上亿量级）的聚合如何实现？
Elasticsearch 提供的首个近似聚合是 cardinality 度量。它提供一个字段的基数，即该字段的 distinct 或者unique 值的数目。它是基于 HLL 算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。
大数据量聚合的多种策略：
// 1. Cardinality 去重计数（基于 HyperLogLog）
GET /orders/_search
{
"size": 0,
"aggs": {
"unique_customers": {
"cardinality": {
"field": "customer_id",
"precision_threshold": 40000
}
}
}
}
// precision_threshold 控制精度和内存的平衡
// 4000 → 约1%误差，占用约1KB内存
// 40000 → 约0.5%误差，占用约4KB内存
// 2. Terms 聚合 + 分片请求大小
GET /orders/_search
{
"size": 0,
"aggs": {
"top_categories": {
"terms": {
"field": "category",
"size": 100, // 返回前100个
"shard_size": 200, // 每个分片返回200个（减少误差）
"show_term_doc_count_error": true
}
}
}
}
// 3. Composite 聚合（类似数据库游标分页）
GET /orders/_search
{
"size": 0,
"aggs": {
"my_buckets": {
"composite": {
"sources": [
{ "category": { "terms": { "field": "category" } } },
{ "brand": { "terms": { "field": "brand" } } }
],
"size": 10
}
}
}
}
// 4. Date Histogram 按时间聚合
GET /orders/_search
{
"size": 0,
"aggs": {
"sales_per_month": {
"date_histogram": {
"field": "order_date",
"calendar_interval": "month",
"format": "yyyy-MM"
},
"aggs": {
"total_amount": {
"sum": { "field": "amount" }
}
}
}
}
}聚合优化原则：
1. 减少参与聚合的文档数量
- 使用 query 过滤掉不需要的文档
- 利用 date filter 限制时间范围
- 使用 filter 聚合缓存结果
2. 选择合适的聚合精度
- cardinality 的 precision_threshold
- terms 的 shard_size 参数
- date_histogram 的 interval
3. 避免高基数字段的 terms 聚合
- 对 user_id 等高基数字段聚合，结果可能不准确
- 考虑使用 cardinality 替代
4. 使用 doc_values
- doc_values 存储在磁盘，不占用堆内存
- 适合聚合和排序操作
5. 分层聚合
- 先按大类聚合，再按小类聚合
- 使用 pipeline 聚合进行二次计算6、在并发情况下，Elasticsearch 如果保证读写一致？
1、可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
2、另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
3、对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary来查询主分片，确保文档是最新版本。
一致性保障的详细机制：
写一致性级别（Write Consistency）：
- one：只要主分片可用即可写入（最快）
- quorum（默认）：大多数分片可用即可写入（推荐）
- all：所有分片都可用才能写入（最安全，最慢）
quorum 计算：
quorum = int((primary + number_of_replicas) / 2) + 1
例如：1 primary + 1 replica = quorum 1
1 primary + 2 replicas = quorum 2
读一致性选项（Read Preference）：
- _primary：只从主分片读取（保证读到最新数据）
- _primary_first：优先主分片
- _local：只从本地节点读取
- _only_node:xyz：只从指定节点读取
- _prefer_node:xyz：优先指定节点
- _shards:0,1：只从指定分片读取
// 查询时指定读偏好
GET /products/_search?preference=_primary// .NET 中使用乐观并发控制
var response = await client.IndexAsync(
new Product { Id = "1", Name = "手机" },
idx => idx
.Index("products")
.IfSequenceNumber(5) // 指定 seq_no
.IfPrimaryTerm(1) // 指定 primary_term
.Refresh(Refresh.WaitFor)
);
if (response.ApiCall.HttpStatusCode == 409)
{
// 版本冲突，需要处理
}7、ElasticSearch中的集群、节点、索引、文档、类型是什么？
群集：一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为"elasticsearch"。
节点：属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引：就像关系数据库中的"数据库"。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。
文档：类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。
类型：是索引的逻辑类别/分区，其语义完全取决于用户。
与关系型数据库的对比：
Elasticsearch 7.x 之前（包含 Type）：
MySQL → Elasticsearch
Database → Index
Table → Type（已废弃）
Row → Document
Column → Field
Schema → Mapping
Index → 全文索引（倒排索引）
Elasticsearch 7.x 之后（移除 Type）：
MySQL → Elasticsearch
Database → Index
Table → Index
Row → Document
Column → Field
Schema → Mapping
JOIN → 父子文档 / Nested
Type 被移除的原因：
1. Lucene本身没有Type的概念，ES在Lucene之上模拟了Type
2. 同一Index中不同Type的同名字段在Lucene中会冲突
3. 在一个Index中放置多种Type会导致数据稀疏
4. 官方推荐一个Index只存储一种Type的数据
节点类型：
- Master Node：管理集群状态、索引创建、分片分配
- Data Node：存储数据、执行CRUD和搜索操作
- Coordinating Node：路由请求、合并搜索结果
- Ingest Node：数据预处理管道集群架构最佳实践：
# 3节点集群配置示例
# 节点1：Master + Data
node.name: node-1
node.master: true
node.data: true
node.ingest: true
# 节点2：Master + Data
node.name: node-2
node.master: true
node.data: true
node.ingest: true
# 节点3：Data + Coordinating
node.name: node-3
node.master: false
node.data: true
node.ingest: false8、Elasticsearch的倒排索引是什么？
1、倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。倒排索引是一种像数据结构一样的散列图，可将用户从单词导向文档或网页。它是搜索引擎的核心。其主要目标是快速搜索从数百万文件中查找数据。
2、传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。有了倒排索引，就能实现o（1）时间复杂度的效率检索文章了，极大的提高了检索效率。
3、倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表。
4、倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。
倒排索引的详细结构：
正排索引（Forward Index）：文档 → 词
文档1 → [Elasticsearch, 是, 一个, 搜索, 引擎]
文档2 → [搜索, 引擎, 非常, 强大]
倒排索引（Inverted Index）：词 → 文档
Elasticsearch → [文档1]
搜索 → [文档1, 文档2]
引擎 → [文档1, 文档2]
是 → [文档1]
一个 → [文档1]
非常 → [文档2]
强大 → [文档2]
倒排索引的组成：
1. Term Dictionary（词典）
- 存储所有经过分词后的词项
- 按字典序排列
- 使用 FST 数据结构存储（内存高效）
2. Term Index（词典索引）
- 词典的前缀索引
- 用于快速定位词典中的词项
- 存储在内存中
3. Posting List（倒排表/记录表）
- 每个词项对应的文档列表
- 包含文档ID、词频、位置信息
- 使用 Frame of Reference 压缩
- 使用 Roaring Bitmaps 压缩
4. Posting List 详情
- Doc ID：文档编号
- TF（Term Frequency）：词频
- Position：词在文档中的位置
- Offset：词的偏移量
- Payloads：附加信息
查询过程示例：
搜索 "搜索 引擎"
1. 分词：["搜索", "引擎"]
2. 查词典：
- "搜索" → Posting List: [文档1, 文档2]
- "引擎" → Posting List: [文档1, 文档2]
3. 合并结果：文档1 和 文档2 都匹配
4. 计算相关性得分（BM25算法）
5. 按得分排序返回FST（Finite State Transducer）详解：
FST 的特点：
1. 空间效率极高
- 通过共享前缀和后缀压缩存储
- 例如 "cat", "car", "card" 共享 "ca" 前缀
- 比 HashMap 节省 10-50 倍空间
2. 查询效率高
- 时间复杂度 O(len(term))
- 比二分查找更快
3. 支持前缀搜索
- 可以快速找到所有以某前缀开头的词项
- 支持自动补全功能
4. 只读数据结构
- 构建后不可修改
- 非常适合词典这种写入少、读取多的场景
FST 在 Elasticsearch 中的应用：
- 词典存储
- 全文搜索的分词结果查找
- 聚合操作的术语查找
- 自动补全建议9、ElasticSearch中的分析器是什么？
1、在ElasticSearch中索引数据时，数据由为索引定义的Analyzer在内部进行转换。分析器由一个Tokenizer和零个或多个TokenFilter组成。编译器可以在一个或多个CharFilter之前。分析模块允许您在逻辑名称下注册分析器，然后可以在映射定义或某些API中引用它们。
2、Elasticsearch附带了许多可以随时使用的预建分析器。或者，您可以组合内置的字符过滤器，编译器和过滤器器来创建自定义分析器。
分析器的完整组成和工作流程：
分析器（Analyzer）的组成：
CharFilter（字符过滤器）→ Tokenizer（分词器）→ TokenFilter（词项过滤器）
工作流程：
原始文本："Hello World! 你好世界"
│
▼
┌─────────────────────┐
│ CharFilter │ → html_strip：去除HTML标签
│ （字符过滤器） │ → mapping：字符映射（如 & → and）
│ 0个或多个 │ → pattern_replace：正则替换
└────────┬────────────┘
│ "Hello World! 你好世界"
▼
┌─────────────────────┐
│ Tokenizer │ → standard：标准分词（按空格和标点）
│ （分词器） │ → ik_smart：IK智能分词
│ 必须有且只有1个 │ → ik_max_word：IK最细粒度分词
└────────┬────────────┘ → pattern：正则分词
│ ["hello", "world", "你好", "世界"]
▼
┌─────────────────────┐
│ TokenFilter │ → lowercase：转小写
│ （词项过滤器） │ → stop：去除停用词
│ 0个或多个 │ → synonym：同义词替换
└────────┬────────────┘ → stemmer：词干提取
│ ["hello", "world", "你好", "世界"]
▼
最终词项列表内置分析器和自定义分析器：
// 内置分析器
// standard：标准分析器（默认）
// simple：按非字母分词，转小写
// whitespace：按空格分词
// stop：标准 + 去除停用词
// keyword：不分词，整体作为一个词项
// pattern：正则表达式分词
// language：特定语言的分析器
// 自定义分析器
PUT /my_index
{
"settings": {
"analysis": {
"char_filter": {
"my_char_filter": {
"type": "mapping",
"mappings": ["& => and", "| => or"]
}
},
"tokenizer": {
"my_tokenizer": {
"type": "pattern",
"pattern": "[ ,.!?]+"
}
},
"filter": {
"my_synonym": {
"type": "synonym",
"synonyms": ["手机, 电话, 手机电话"]
},
"my_stopwords": {
"type": "stop",
"stopwords": ["的", "了", "是"]
}
},
"analyzer": {
"my_analyzer": {
"type": "custom",
"char_filter": ["my_char_filter"],
"tokenizer": "my_tokenizer",
"filter": ["lowercase", "my_synonym", "my_stopwords"]
}
}
}
}
}
// IK 中文分词器配置
PUT /my_index
{
"settings": {
"analysis": {
"analyzer": {
"ik_smart_analyzer": {
"type": "custom",
"tokenizer": "ik_smart"
},
"ik_max_analyzer": {
"type": "custom",
"tokenizer": "ik_max_word"
}
}
}
}
}
// 测试分析器
POST /my_index/_analyze
{
"analyzer": "ik_max_word",
"text": "中华人民共和国国歌"
}
// 结果：["中华人民共和国", "中华人民", "中华", "华人", "人民共和国",
// "人民", "共和国", "共和", "国", "国歌"]10、启用属性，索引和存储的用途是什么？
1、Enabled属性适用于各类ElasticSearch特定/创建领域，如index和size。用户提供的字段没有"已启用"属性。
2、存储意味着数据由Lucene存储，如果询问，将返回这些数据。存储字段不一定是可搜索的。默认情况下，字段不存储，但源文件是完整的。
3、索引属性只能用于搜索。只有索引域可以进行搜索。差异的原因是在分析期间对索引字段进行了转换，因此如果需要的话，您不能检索原始数据。
字段属性详解：
// 字段属性配置
PUT /products
{
"mappings": {
"properties": {
"name": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart",
"index": true, // 是否可搜索（默认 true）
"store": false, // 是否单独存储（默认 false）
"boost": 2.0 // 字段权重（影响相关性得分）
},
"sku": {
"type": "keyword",
"index": true,
"doc_values": true // 聚合和排序用（默认 true）
},
"description": {
"type": "text",
"index": true,
"norms": true, // 是否归一化（影响评分）
"index_options": "positions" // 索引选项
},
"price": {
"type": "float",
"doc_values": true,
"ignore_malformed": true // 忽略格式错误的值
},
"is_active": {
"type": "boolean",
"index": true
},
"metadata": {
"type": "object",
"enabled": false // 完全禁用，不索引也不搜索
}
}
}
}
// index_options 选项：
// docs: 只索引文档ID（用于 score 评分）
// freqs: 索引文档ID和词频
// positions: 索引文档ID、词频和位置（支持短语查询）
// offsets: 索引文档ID、词频、位置和偏移量（支持高亮）
// index_options 的选择：
// - 只需要判断文档是否包含某词 → docs
// - 需要相关性评分 → freqs
// - 需要短语查询或邻近查询 → positions
// - 需要高亮显示 → offsets11、Elasticsearch了解多少，说说你们公司es的集群架构，索引数据大小，分片有多少，以及一些调优手段。
比如：ES集群架构13个节点，索引根据通道不同共20+索引，根据日期，每日递增20+，索引：10分片，每日递增1亿+数据，每个通道每天索引大小控制：150GB之内。
生产环境调优完整方案：
仅索引层面调优手段：
1.1、设计阶段调优
1）根据业务增量需求，采取基于日期模板创建索引，通过roll over API滚动索引；
2）使用别名进行索引管理；
3）每天凌晨定时对索引做force_merge操作，以释放空间；
4）采取冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作，以缩减存储；
5）采取curator进行索引的生命周期管理；
6）仅针对需要分词的字段，合理的设置分词器；
7）Mapping阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。
1.2、写入调优
1）写入前副本数设置为0；
2）写入前关闭refresh_interval设置为-1，禁用刷新机制；
3）写入过程中：采取bulk批量写入；
4）写入后恢复副本数和刷新间隔；
5）尽量使用自动生成的id。
1.3、查询调优
1）禁用wildcard；
2）禁用批量terms（成百上千的场景）；
3）充分利用倒排索引机制，能keyword类型尽量keyword；
4）数据量大时候，可以先基于时间敲定索引再检索；
5）设置合理的路由机制。
1.4、其他调优
部署调优，业务调优等。详细的调优配置示例：
# 生产环境 elasticsearch.yml 调优配置
# 集群配置
cluster.name: prod-cluster
cluster.routing.allocation.awareness.attributes: rack_id # 机架感知
# JVM 调优
# 堆内存设置为物理内存的50%，不超过32GB
# -Xms16g -Xmx16g （在 jvm.options 中配置）
# 索引调优
indices.query.bool.max_clause_count: 4096 # 增大布尔查询子句上限
# 线程池调优
thread_pool.search.size: 20
thread_pool.search.queue_size: 1000
thread_pool.write.size: 8
thread_pool.write.queue_size: 500
# 缓存调优
indices.fielddata.cache.size: 40% # 字段数据缓存上限
indices.requests.cache.size: 2% # 请求缓存大小// 索引模板配置
PUT _template/product_template
{
"index_patterns": ["product-*"],
"settings": {
"number_of_shards": 5,
"number_of_replicas": 1,
"refresh_interval": "5s",
"index.lifecycle.name": "product_policy",
"index.lifecycle.rollover_alias": "product-alias"
},
"mappings": {
"properties": {
"product_id": { "type": "keyword" },
"name": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart",
"fields": {
"keyword": { "type": "keyword" }
}
},
"price": { "type": "float" },
"category": { "type": "keyword" },
"created_at": { "type": "date" }
}
}
}
// Rollover 策略
PUT _ilm/policy/product_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "50gb",
"max_age": "7d",
"max_docs": 100000000
}
}
},
"warm": {
"min_age": "30d",
"actions": {
"forcemerge": { "max_num_segments": 1 },
"shrink": { "number_of_shards": 1 },
"allocate": { "number_of_replicas": 0 }
}
},
"cold": {
"min_age": "90d",
"actions": {
"freeze": {},
"allocate": { "require": { "storage_type": "cold" } }
}
},
"delete": {
"min_age": "180d",
"actions": { "delete": {} }
}
}
}
}12、Elasticsearch 索引数据多了怎么办，如何调优，部署？
1、动态索引层面：基于模板+时间+rollover api滚动创建索引。
2、存储层面：冷热数据分离存储，热数据存储到SSD，冷数据进行force_merge加shrink压缩操作。
3、部署层面：结合ES自身的支持动态扩展的特点，动态新增机器可以缓解集群压力。
分片规划策略：
分片大小建议：
- 单个分片大小建议 10-50GB
- 不超过 50GB，否则合并和恢复时间过长
- 不低于 10GB，否则分片过多导致管理开销
分片数量计算：
分片数 = 预期数据总量 / 目标分片大小
例如：每天1亿条，150GB，保留30天
数据总量 = 150GB * 30 = 4500GB
分片数 = 4500GB / 30GB = 150个分片
每天索引分片数 = 150 / 30 = 5个分片/天
副本数量：
- 生产环境至少1个副本
- 高可用场景建议2个副本
- 搜索密集型场景可以增加副本数（读性能提升）
索引生命周期管理（ILM）：
Hot → Warm → Cold → Delete
热阶段：正常读写，SSD存储
温阶段：只读，HDD存储，force_merge + shrink
冷阶段：冻结，极少访问
删除阶段：超龄自动删除13、在使用 Elasticsearch 时要注意什么？
由于ES使用的Java写的，所有注意的是GC方面的问题。
1、倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segmentmemory 增长趋势。
2、各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用。
3、避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api 来实现。
4、cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node连接。
5、想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做持续的监控。
ES 生产环境注意事项详解：
1. JVM 内存配置
- 堆内存不超过物理内存的50%
- 堆内存不超过32GB（利用压缩指针）
- Xms 和 Xmx 设置相同（避免运行时调整）
- 推荐 16GB 或 31GB
2. GC 问题
- 使用 G1GC 垃圾回收器（ES 8+ 默认）
- 监控 GC 停顿时间（应 < 100ms）
- 长 GC 停顿会导致节点脱离集群
3. 磁盘相关
- 确保磁盘IO性能（SSD推荐）
- 监控磁盘使用率（不超过85%）
- 磁盘满了会导致索引变为只读
4. 网络相关
- 节点间延迟 < 10ms
- 带宽充足（分片恢复和副本同步）
- 避免跨机房部署（延迟问题）
5. 查询优化
- 避免深度分页
- 避免通配符开头的查询（*xxx）
- 避免脚本聚合（painless性能有限）
- 使用 filter 替代 query（可缓存）
- 避免返回大量字段（使用 _source filtering）
6. 监控指标
- 集群健康状态（green/yellow/red）
- 节点资源使用率（CPU、内存、磁盘）
- JVM 堆内存使用和GC情况
- 索引和分片状态
- 查询延迟和错误率14、Elasticsearch 支持哪些类型的查询？
查询主要分为两种类型：精确匹配、全文检索匹配。
精确匹配：term、exists、term set、range、prefix、ids、wildcard、regexp、fuzzy等。
全文检索：match、match_phrase、multi_match、match_phrase_prefix、query_string 等。
查询类型完整分类：
// === 叶子查询（Leaf Query） ===
// 1. 全文检索
// match：全文匹配（最常用）
{ "match": { "title": "搜索引擎" } }
// match_phrase：短语匹配（词序必须一致）
{ "match_phrase": { "title": "搜索引擎" } }
// multi_match：多字段匹配
{ "multi_match": {
"query": "手机",
"fields": ["title^3", "description", "brand"]
}}
// match_phrase_prefix：短语前缀匹配（自动补全）
{ "match_phrase_prefix": {
"title": { "query": "搜索引", "max_expansions": 10 }
}}
// query_string：查询字符串语法
{ "query_string": {
"query": "(title:手机 OR title:电话) AND price:<5000"
}}
// 2. 精确匹配
// term：精确匹配
{ "term": { "status": "active" } }
// terms：多值精确匹配（类似 SQL IN）
{ "terms": { "category": ["手机", "电脑", "平板"] } }
// range：范围查询
{ "range": { "price": { "gte": 1000, "lte": 5000 } } }
// exists：字段存在性检查
{ "exists": { "field": "description" } }
// prefix：前缀匹配
{ "prefix": { "name": "苹果" } }
// wildcard：通配符匹配
{ "wildcard": { "name": "苹果*" } }
// === 复合查询（Compound Query） ===
// bool：布尔查询（最重要）
{ "bool": {
"must": [ ... ], // 必须匹配（参与评分）
"should": [ ... ], // 应该匹配（参与评分）
"must_not": [ ... ], // 必须不匹配
"filter": [ ... ] // 必须匹配（不参与评分，可缓存）
}}
// constant_score：固定评分查询
{ "constant_score": {
"filter": { "term": { "status": "active" } }
}}
// function_score：自定义评分
{ "function_score": {
"query": { "match": { "title": "手机" } },
"functions": [
{
"field_value_factor": {
"field": "popularity",
"factor": 1.2,
"modifier": "sqrt"
}
}
],
"boost_mode": "multiply"
}}15、你能否列出与 Elasticsearch 有关的主要可用字段数据类型？
1、字符串数据类型，包括支持全文检索的 text 类型 和 精准匹配的 keyword 类型。
2、数值数据类型，例如字节，短整数，长整数，浮点数，双精度数，half_float，scaled_float。
3、日期类型，日期纳秒Date nanoseconds，布尔值，二进制（Base64编码的字符串）等。
4、范围（整数范围 integer_range，长范围 long_range，双精度范围 double_range，浮动范围 float_range，日期范围 date_range）。
5、包含对象的复杂数据类型，nested、Object。
6、GEO 地理位置相关类型。
7、特定类型如：数组（数组中的值应具有相同的数据类型）。
数据类型选择指南：
// 常用数据类型配置
PUT /products
{
"mappings": {
"properties": {
// 字符串：需要全文检索用 text，精确匹配用 keyword
"name": {
"type": "text",
"fields": { "keyword": { "type": "keyword" } }
},
"sku": { "type": "keyword" },
// 数值
"price": { "type": "float" },
"stock": { "type": "integer" },
"rating": { "type": "float" },
"score": { "type": "double" },
// 日期
"created_at": {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
},
// 布尔
"is_published": { "type": "boolean" },
// 嵌套对象
"tags": { "type": "keyword" },
"attributes": {
"type": "nested",
"properties": {
"key": { "type": "keyword" },
"value": { "type": "keyword" }
}
},
// 地理位置类型
"location": { "type": "geo_point" }, // 经纬度坐标
"geo_shape": { "type": "geo_shape" }, // 地理形状
// 范围类型
"price_range": {
"type": "float_range"
},
// 自动补全类型
"suggest": { "type": "completion" },
// 数组类型（ES天然支持数组）
"category_ids": { "type": "keyword" } // 可以存储 ["1", "2", "3"]
}
}
}
// text vs keyword 选择：
// text：需要全文检索（标题、描述、内容）
// keyword：精确匹配（ID、状态、分类、标签）
// 同时需要两者：使用 multi-fields16、如何监控 Elasticsearch 集群状态？
Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。
完整的监控方案：
1. Kibana Stack Monitoring（推荐）
- 开箱即用的ES监控
- 集群健康、节点状态、索引统计
- JVM指标、查询性能
- 配置：xpack.monitoring.enabled: true
2. 关键监控指标
- 集群状态（green/yellow/red）
- 节点数量（期望 vs 实际）
- 分片状态（活跃、初始化、重新分配）
- JVM堆内存使用率（应 < 75%）
- GC频率和停顿时间
- 磁盘使用率（应 < 85%）
- 查询延迟（p50/p95/p99）
- 索引速率（docs/s）
- 搜索速率（queries/s）
- 拒绝的请求（bulk/search/thread_pool）
3. 告警规则
- 集群状态变为 yellow/red
- JVM堆内存 > 85%
- GC停顿 > 500ms
- 磁盘使用率 > 80%
- 未分配的分片数 > 0
- 查询延迟 > 1s// 集群健康检查 API
GET _cluster/health
{
"cluster_name": "prod-cluster",
"status": "green",
"number_of_nodes": 13,
"active_primary_shards": 200,
"active_shards": 400,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
// 节点统计
GET _nodes/stats
GET _nodes/stats/jvm,os,process,indices
// 索引统计
GET _stats
GET products-2024-03-*/_stats
// 查看分片分配情况
GET _cat/shards?v
GET _cat/allocation?v17、有了解过Elasticsearch的个性化搜索方案吗？
基于word2vec和Elasticsearch实现个性化搜索。
（1）基于word2vec、Elasticsearch和自定义的脚本插件，我们就实现了一个个性化的搜索服务，相对于原有的实现，新版的点击率和转化率都有大幅的提升；
（2）基于word2vec的商品向量还有一个可用之处，就是可以用来实现相似商品的推荐；
（3）使用word2vec来实现个性化搜索或个性化推荐是有一定局限性的，因为它只能处理用户点击历史这样的时序数据，而无法全面的去考虑用户偏好。
个性化搜索的多种实现方案：
方案 1：基于用户行为加权
- 收集用户点击、购买、收藏等行为
- 为每个用户构建兴趣画像
- 搜索时根据用户画像调整相关性权重
- 实现：使用 function_score 查询
方案 2：基于向量搜索（KNN）
- 使用 Embedding 模型将商品文本转为向量
- 将用户历史偏好转为向量
- 搜索时同时考虑文本匹配和向量相似度
- ES 8.x 支持 kNN 搜索
方案 3：基于协同过滤
- "购买了此商品的人也购买了..."
- 使用 script_score 或聚合实现
- 需要离线计算用户-商品矩阵
方案 4：Learning to Rank
- 使用机器学习模型重新排序搜索结果
- ES 支持通过 X-Pack 或插件集成 LTR
- 需要标注数据和训练流程// 方案 1：基于用户行为加权的 function_score
GET /products/_search
{
"query": {
"function_score": {
"query": { "match": { "name": "手机" } },
"functions": [
{
"filter": { "term": { "category": "用户偏好分类" } },
"weight": 2.0
},
{
"filter": { "terms": { "brand": ["用户偏好品牌"] } },
"weight": 1.5
},
{
"gauss": {
"price": { "origin": 3000, "scale": 2000 }
}
}
],
"score_mode": "sum",
"boost_mode": "multiply"
}
}
}18、是否了解字典树？
Trie 的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有 3 个基本性质：
1、根节点不包含字符，除根节点外每一个节点都只包含一个字符。
2、从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。
3、每个节点的所有子节点包含的字符都不相同。
字典树（Trie）及变体在搜索引擎中的应用：
字典树的核心应用：
1. 自动补全（Autocomplete）
- 输入前缀，快速返回匹配词
- ES 的 completion suggester 基于 FST 实现
2. 拼写检查（Spell Checking）
- 输入错误词，找到最近似的正确词
- 基于 Levenshtein 距离的模糊匹配
3. 词频统计
- 每个节点记录经过次数
- 用于搜索引擎的 TF-IDF 计算
数据结构对比：
| 数据结构 | 查找复杂度 | 插入复杂度 | 空间效率 | 适用场景 |
| -- | -- | -- | -- | -- |
| Array/List | O(n) | O(1) | 高 | 小数据量 |
| HashMap | O(1) | O(1) | 中 | 通用场景 |
| Trie | O(m) | O(m) | 低 | 前缀匹配 |
| FST | O(m) | O(m*n) | 极高 | 只读词典 |
| Double Array Trie | O(m) | O(m) | 高 | 中文分词 |
m = 字符串长度
n = 词典大小
FST（Finite State Transducer）：
- Trie 的压缩版本
- 共享前缀和后缀
- 空间效率极高
- Lucene/Elasticsearch 词典的核心数据结构
- 支持 O(m) 的前缀查找和模糊匹配19、ElasticSearch是否有架构？
1、ElasticSearch可以有一个架构。架构是描述文档类型以及如何处理文档的不同字段的一个或多个字段的描述。
2、Elasticsearch具有架构灵活的能力，这意味着可以在不明确提供架构的情况下索引文档。如果未指定映射，则默认情况下，Elasticsearch会在索引期间检测文档中的新字段时动态生成一个映射。
Mapping 设计最佳实践：
// 生产环境建议关闭动态映射
PUT /products
{
"mappings": {
"dynamic": "strict", // strict: 未知字段报错
// false: 忽略未知字段
// runtime: 运行时字段
"properties": {
"product_id": { "type": "keyword" },
"name": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart",
"fields": {
"keyword": { "type": "keyword", "ignore_above": 256 },
"completion": { "type": "completion" }
}
},
"price": {
"type": "float",
"doc_values": true,
"ignore_malformed": true
}
},
"dynamic_templates": [
{
"strings_as_keywords": {
"match_mapping_type": "string",
"mapping": { "type": "keyword" }
}
},
{
"longs_as_dates": {
"match_mapping_type": "long",
"mapping": { "type": "date" }
}
}
]
}
}20、为什么要使用Elasticsearch?
因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度。
Elasticsearch vs 其他搜索方案的对比：
Elasticsearch vs 数据库 LIKE 查询：
- LIKE '%keyword%' 无法使用索引，全表扫描
- 百万级数据响应时间 > 秒级
- ES 倒排索引，毫秒级响应
Elasticsearch vs 数据库全文索引：
- MySQL FULLTEXT 只支持英文分词
- 不支持同义词、拼音、相关性评分
- ES 支持中文分词、自定义评分
Elasticsearch vs Solr：
- ES：分布式架构更简单，实时性更好，社区更活跃
- Solr：传统搜索方案，功能更成熟
Elasticsearch 适用场景：
1. 全文搜索（电商商品搜索、文档搜索）
2. 日志分析（ELK Stack）
3. 数据分析（聚合、仪表板）
4. 地理位置搜索（附近的人、门店搜索）
5. 推荐系统（相似商品推荐）
6. 监控和告警（时序数据分析）这组题真正考什么
- 面试官往往不只是考定义，而是在看你能否把基础概念放回真实 .NET 场景。
- 这类题经常沿着语言基础、框架设计、性能和工程实践往下追问。
- 高分答案通常有三层：结论、原因、项目中的例子。
- Elasticsearch 面试题往往与分布式系统、搜索引擎原理和实际调优经验交叉。
60 秒答题模板
- 先用一句话给结论。
- 再补关键原理或底层机制。
- 最后说适用边界、常见坑或项目中的使用经验。
容易失分的点
- 只会背术语，不会举例。
- 回答太散，没有结构。
- 忽略版本差异和工程背景。
- 不了解倒排索引的底层实现（FST、Posting List）。
- 不了解 ES 的写入流程（Memory Buffer → Segment）。
- 不了解深度分页问题和解决方案。
刷题建议
- 把答案拆成"定义、适用场景、风险点、实战例子"四段来复述。
- 遇到 .NET 基础题时，尽量补一个框架级别的落地场景，而不是只背术语。
- 高频概念题建议自己再追问一层：底层原理、常见坑、性能代价分别是什么。
- ES 面试题要结合实际运维经验回答，特别是调优和集群管理。
高频追问
- 如果面试官继续追问底层实现，你能否解释运行机制或源码层面的关键点？
- 如果题目放到 ASP.NET Core、消息队列或数据库场景里，这个结论是否还成立？
- 是否存在版本差异、框架差异或特殊边界条件需要主动说明？
- ES 的写入延迟是多少？如何调优？
- 如何处理 ES 集群的脑裂问题？
- ES 的段合并机制对查询性能有什么影响？
复习重点
- 把每道题的关键词整理成自己的知识树，而不是只背原句。
- 对容易混淆的概念要做横向比较，例如机制差异、适用边界和性能代价。
- 复习时优先补"为什么"，其次才是"怎么用"和"记住什么术语"。
- 重点掌握倒排索引原理、写入流程、搜索流程、分片机制和调优策略。
面试作答提醒
- 先给结论，再补原因和例子。
- 回答基础题时不要只说"能用"，最好补一句为什么这样选。
- 如果记不清细节，优先说出适用边界和排查思路。
- ES 的面试回答要体现出实际调优经验和集群运维经验。