在一般的语境下，一个 Elasticsearch 的索引并不仅仅指倒排索引，还包括了对应的文档。这 个和关系型数据库下的语义是不同的。 Elasticsearch 的一个索引有多个分片，每个分片又有主从结构。这种结构相信你已经很熟悉了，它类似于分库分表。

作为类比，你可以这样理解。 一个索引就是一个逻辑表。 分片就是分库分表。 每个分片都有主从结构，在分库分表里面，一般也是用主从集群来存储数据。

Elasticsearch 会尽量把分片分散在不同的节点上，这一点和 Kafka 尽量把分区分散在不同的 broker 上是一样的，都是为了保证在节点崩溃的时候将影响最小化。

Elasticsearch 是一个分布式搜索引擎，主要用于文本数据的实时搜索和分析。与关系型数据库不同，Elasticsearch 是基于文档存储的，使用倒排索引加速搜索过程。

分片是为了将数据分散到多个节点上，实现数据的分布式存储；副本用于提高系统的容错性和查询性能。

• 在创建索引时，可以指定分片数和副本数，示例：

  PUT /my_index
  {
    "settings": {
      "number_of_shards": 5,
      "number_of_replicas": 1
    }
  }

倒排索引是将文档中的每个词条和它出现的文档进行索引。它允许 Elasticsearch 快速检索匹配的文档，提高查询效率。

• 使用 match 查询进行全文搜索。例如：

  {
    "query": {
      "match": {
        "field_name": "search_text"
      }
    }
  }

映射是对文档中字段类型的定义，它决定了如何存储和索引数据。映射类似于数据库中的表结构。

Elasticsearch 的集群由多个节点组成，这些节点通过网络进行通信，共同负责存储和处理数据。集群中的每个节点可以充当不同的角色，例如主节点、数据节点和协调节点。

通过副本（Replica）来实现数据的冗余存储，副本不仅提供容错能力，还可以用于分担查询负载。

优化查询可以通过合理的索引设计、使用过滤器代替查询、减少 wildcard 和 regexp 查询的使用等方式实现。

考虑索引的字段类型、分析器的选择、是否需要排序等。避免过多的字段、避免高基数字段、合理设置分片和副本数等。

聚合是 Elasticsearch 中进行数据统计和分析的功能，常见的聚合类型有 avg（平均值）、sum（总和）、terms（按值分组）等。

Elasticsearch 使用的是软删除（soft delete），即标记文档为已删除，而不立即删除文档。最终的删除操作会通过段合并（segment merge）进行清理。

可以使用 Elasticsearch 的聚合功能进行日志数据的分析，比如按日期统计日志数量、按日志级别聚合等。

bulk 操作用于批量插入、更新、删除文档，能够提高操作效率，减少单独请求的开销。

面试官 ：想了解应聘者之前公司接触的ES使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。

解答 ：如实结合自己的实践场景回答即可。比如：ES集群架构13个节点，索引根据通道不同共20+索引，根据日期，每日递增20+，索引：10分片，每日递增1亿+数据，每个通道每天索引大小控制：150GB之内。

仅索引层面调优手段：

• 根据业务增量需求，采取基于日期模板创建索引，通过roll over API滚动索引；
• 使用别名进行索引管理；
• 每天凌晨定时对索引做force_merge操作，以释放空间；
• 采取冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作，以缩减存储；
• 采取curator进行索引的生命周期管理；
• 仅针对需要分词的字段，合理的设置分词器；
• Mapping阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。 ……..

• 写入前副本数设置为0；
• 写入前关闭refresh_interval设置为-1，禁用刷新机制；
• 写入过程中：采取bulk批量写入；
• 写入后恢复副本数和刷新间隔；
• 尽量使用自动生成的id。

• 禁用wildcard；
• 禁用批量terms（成百上千的场景）；
• 充分利用倒排索引机制，能keyword类型尽量keyword；
• 数据量大时候，可以先基于时间敲定索引再检索；
• 设置合理的路由机制。

部署调优，业务调优等。

上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。有了倒排索引，就能实现o（1）时间复杂度 的效率检索文章了，极大的提高了检索效率。

学术的解答方式：

倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表。

加分项 ：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。lucene从4+版本后开始大量使用的数据结构是FST。FST有两个优点：

• 空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
• 查询速度快。O(len(str))的查询时间复杂度。

优化分页查询

在 Elasticsearch 里面，也有两种可行的优化手段。

1. Scroll 和 Scroll Scan：这种方式适合一次性查询大量的数据，比如说导出数据之类的场景。这种用法更加接近你在别的语言或者中间件里面接触到的游标的概念。

2. Search After：也就是翻页，你在查询的时候需要在当次查询里面带上上一次查询中返回的 search_after 字段。

增大刷新间隔

• 可以把 index.refresh_interval 调大一些

优化不必要字段

冷热分离

它的基本思路是同一个业务里面数据也有冷热之分。对于冷数据来说，可以考虑使用运行在廉价服务器上的 Elasticsearch 来存储；而对

于热数据来说，就可以使用运行在昂贵的高性能服务器上的 Elasticsearch。

面试官 ：想了解大数据量的运维能力。

解答 ：索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在后”，这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。如何调优，正如问题1所说，这里细化一下：

基于模板+时间+rollover api滚动 创建索引，举例：设计阶段定义：blog索引的模板格式为：blog_index_时间戳的形式，每天递增数据。

这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线2的32次幂-1，索引存储达到了TB+甚至更大。

一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。

冷热数据分离存储 ，热数据（比如最近3天或者一周的数据），其余为冷数据。对于冷数据不会再写入新数据，可以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率。

一旦之前没有规划，这里就属于应急策略。结合ES自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点等规划合理 ，不需要重启集群也能完成动态新增的。

Elasticsearch 的节点可以分成很多种角色，并且一个节点可以扮演多种角色。这里我列举几种主要的。

• 候选主节点（Master-eligible Node)：可以被选举为主节点的节点。主节点主要负责集群本身的管理，比如说创建索引。类似的还有仅投票节点（Voting-only Node），这类节点只参与主从选举，但是自身并不会被选举为主节点。

• 协调节点（Coordinating Node）：协调节点负责协调请求的处理过程。一个查询请求会被发送到协调节点上，协调节点确定数据节点，然后让数据节点执行查询，最后协调节点合并数据节点返回的结果集。大多数节点都会兼任这个角色。

• 数据节点（Data Node）：存储数据的节点。当协调节点发来查询请求的时候，也会执行查询并且把结果返回给协调节点。类似的还有热数据节点（Hot Data Node）、暖数据节点（Warm Data Node）、冷数据节点（Cold Data Node），你从名字就可以看出来，它们只是用于存储不同热度的数据。

1. 文档首先被写入到 Buffer 里面，这个是 Elasticsearch 自己的 Buffer。
2. 定时刷新到 Page Cache 里面。这个过程叫做 refresh，默认是 1 秒钟执行一次。
3. 刷新到磁盘中，这时候还会同步记录一个 Commit Point。

在写入到 Page Cache 之后会产生很多段（Segment），一个段里面包含了多个文档。文档只有写到了这里之后才可以被搜索到，因此从支持搜索的角度来说，Elasticsearch 是近实时的。

不断写入会不断产生段，而每一个段都要消耗 CPU、内存和文件句柄，所以需要考虑合并。

但是你也注意到了，这些段本身还在支持搜索，因此在合并段的时候，不能对已有的查询产生影响。

所以又有了合并段的过程，大概是

1. 已有的段不动。
2. 创建一个新的段，把已有段的数据写过去，标记为删除的文档就不会写到段里面。
3. 告知查询使用新的段。
4. 等使用老的段的查询都结束了，直接删掉老的段。

那么查询怎么知道应该使用合并段了呢？这都依赖于一个统一的机制，就是 Commit Point。你可以理解成，它里面记录了哪些段是可用的。所以当合并段之后，产生一个新的 CommitPoint，里面有合并后的段，但是没有被合并的段，就相当于告知了查询使用新的段。

实际上，Elasticsearch 在写入的时候，还要写入一个东西，也就是 Translog。直观来说，你可以把这个看成是 MySQL 里和 redo log 差不多的东西。也就是如果宕机了，Elasticsearch可以用 Translog 来恢复数据。

MySQL 写入的时候，其实只是修改了内存里的值，然后记录了日志，也就是 binlog、redo log 和 undo log。

Elasticsearch写入的时候，也是写到了 Buffer 里，然后记录了 Translog。不同的是，Translog 是固定间隔刷新到磁盘上的，默认情况下是 5 秒。

Elasticsearch 高可用的核心是分片，并且每个分片都有主从之分。也就是说，万一主分片崩溃了，还可以使用从分片，从而保证了最基本的可用性。

而且 Elasticsearch 在写入数据的过程中，为了保证高性能，都是写到自己的 Buffer 里面，后面再刷新到磁盘上。所以为了降低数据丢失的风险，Elasticsearch 还额外写了一个 Translog，它就类似于 MySQL 里的 redo log。后面 Elasticsearch 崩溃之后，可以利用 Translog 来恢复数据。

面试官 ：想了解ES集群的底层原理，不再只关注业务层面了。

解答 ：前置前提：

• 只有候选主节点（master：true）的节点才能成为主节点。
• 最小主节点数（min_master_nodes）的目的是防止脑裂。

这个我看了各种网上分析的版本和源码分析的书籍，云里雾里。核对了一下代码，核心入口为findMaster，选择主节点成功返回对应Master，否则返回null。选举流程大致描述如下：

• 第一步：确认候选主节点数达标，elasticsearch.yml设置的值discovery.zen.minimum_master_nodes；
• 第二步：比较：先判定是否具备master资格，具备候选主节点资格的优先返回；若两节点都为候选主节点，则id小的值会主节点。注意这里的id为string类型。

面试官 ：想了解ES的底层原理，不再只关注业务层面了。

解答 ：这里的索引文档应该理解为文档写入ES，创建索引的过程。文档写入包含：单文档写入和批量bulk写入，这里只解释一下：单文档写入流程。

记住官方文档中的这个图。

第一步：客户写集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，请求的节点扮演路由节点 的角色。）

第二步：节点1接受到请求后，使用文档_id来确定文档属于分片0。请求会被转到另外的节点，假定节点3。因此分片0的主分片分配到节点3上。

第三步：节点3在主分片上执行写操作，如果成功，则将请求并行转发到节点1和节点2的副本分片上，等待结果返回。所有的副本分片都报告成功，节点3将向协调节点（节点1）报告成功，节点1向请求客户端报告写入成功。

如果面试官再问：第二步中的文档获取分片的过程？回答：借助路由算法获取，路由算法就是根据路由和文档id计算目标的分片id的过程。

shard = hash(_routing) % (num_of_primary_shards)

搜索拆解为“query then fetch” 两个阶段。query阶段的目的：定位到位置，但不取。步骤拆解如下：

1. 假设一个索引数据有5主+1副本 共10分片，一次请求会命中（主或者副本分片中）的一个。
2. 每个分片在本地进行查询，结果返回到本地有序的优先队列中。
3. 第 2 步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。

fetch阶段的目的：取数据。路由节点获取所有文档，返回给客户端。

面试官 ：想了解对ES集群的运维能力。

解答 ：

• 关闭缓存swap;
• 堆内存设置为：Min（节点内存/2, 32GB）;
• 设置最大文件句柄数；
• 线程池+队列大小根据业务需要做调整；
• 磁盘存储raid方式——存储有条件使用RAID10，增加单节点性能以及避免单节点存储故障。

面试官 ：想了解你的知识面的广度和深度。

解答 ：

Lucene是有索引和搜索的两个过程，包含索引创建，索引，搜索三个要点。可以基于这个脉络展开一些。