---

1. 什么是ElasticSearch？为什么要使用Elasticsearch?——克服模糊查询的缺点、查询速度快

• Elasticsearch是一个基于Lucene的搜索引擎。
• 它提供了具有HTTP Web界面和无架构JSON文档的分布式，多租户能力的全文搜索引擎。
• Elasticsearch是用Java开发的，根据Apache许可条款作为开源发布。

大型项目中，需要查询的内容非常多，若采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下。

而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度。

---

2. ES中的倒排索引是什么？——词→文章

• 传统检索：是通过文章，逐个遍历找到对应关键词的位置。

• 倒排索引（词典+倒排表）：是通过分词策略，形成了词和文章的映射关系表，也称倒排表，这种词典 + 映射表即为倒排索引。

  • 其中词典中存储词元，倒排表中存储该词元在哪些文中出现的位置。
  • 时间复杂度：有了倒排索引，就能实现 O(1) 时间复杂度的效率检索文章了，极大的提高了检索效率。
  • 底层实现：倒排索引的底层实现是基于FST（Finite State Transducer）数据结构。

Lucene 从 4+ 版本后开始大量使用的数据结构是 FST。FST 有两个优点：

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

---

3. ES是如何实现master选举的？——各节点分别排序投票

前置条件：
1、只有是候选主节点（master：true）的节点才能成为主节点。
2、最小主节点数（min_master_nodes）： 这个参数决定了要选举一个Master需要多少个节点（最少候选节点数），目的是防止脑裂。

Elasticsearch 的选主是 ZenDiscovery 模块负责的，主要包含 Ping和 Unicast两部分；

Ping：节点之间的通信方式，通过这个RPC来发现彼此

Unicast：单播模块，包含一个主机列表以控制哪些节点需要 ping 通

获取主节点的核心入口为 findMaster，选择主节点成功返回对应 Master，否则返回 null。

选举流程大致描述如下：

1. 节点数检验：确认候选主节点数达到最小主节点数（discovery.zen.minimum_master_nodes）;
2. 初始化各个master节点。对所有候选主节点根据nodeId（节点ID）字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点，某节点被选中一次则记一票。
3. 投票选出最终master节点。如果对某个节点的投票数达到一定的值（候选主节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。

---

4. 如何解决ES集群的脑裂问题——增大最少候选节点数 / 增大超时时间

集群脑裂（集群内部观点分裂）： 如果发生网络中断或者服务器宕机，那么集群会有可能被划分为两个部分，各自有自己的master来管理，那么这就是脑裂。这样的脑裂状态直接让节点失去了集群的正确状态，导致集群不能正常工作。

例如，Elasticsearch 集群中的节点（比如共 20 个），其中的 10 个选了一个 master，另外 10 个选了另一个 master 的情况。

造成原因：

1. 如果集群中节点不在同一个网段有可能是网络延迟造成的
2. 如果集群中的节点在同一个网段，有可能是主节点负载太大造成的

解决措施：

1. 调节最少候选节点数：discovery.zen.minimum_master_nodes。这个参数决定了要选举一个Master需要多少个节点（最少候选节点数）。默认值是1。根据一般经验这个一般设置成 N/2 + 1，N是集群中节点的数量，例如一个有3个节点的集群，minimum_master_nodes 应该被设置成 3/2 + 1 = 2（向下取整）。

2. 调整超时时间：discovery.zen.ping.timeout，等待ping响应的超时时间，默认值是3秒。如果网络缓慢或拥塞，建议略微调大这个值（即允许更高的网络延迟）。

   • 这个参数不仅仅适应更高的网络延迟，也适用于在一个由于超负荷而响应缓慢的节点的情况。

   • 如果您刚开始使用elasticsearch，建议搭建拥有3个节点的集群，这种方式可以把discovery.zen.minimum_master_nodes设置成2，这样就限制了发生脑裂现象的可能，且保持着高度的可用性：如果你设置了副本，在丢失一个节点的情况下，集群仍可运行。

---

5. 🚩详细描述一下ES索引文档的过程？

这里的索引文档应该理解为文档写入 ES，创建索引的过程。

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

2. 分片位置判断：协调节点接受到请求后，默认使用文档 ID 参与计算（也支持通过 routing），得到该文档属于哪个分片。随后请求会被转到另外的节点。

   bash# 路由算法：根据文档id或路由计算目标的分片id
   shard = hash(document_id) % (num_of_primary_shards)
   

3. 正常情况：refresh：当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 Memory Buffer，然后定时（默认是每隔 1 秒）写入到Filesystem Cache，这个从 Momery Buffer 到 Filesystem Cache 的过程就叫做 refresh；

4. 异常情况：translog flush：当然在某些情况下，存在 Memery Buffer 和 Filesystem Cache 的数据可能会丢失，ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystem cache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；

   • 在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。
   • flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512 M）时。

• 补充

  • Lucene 的 Segement 分段机制
    • Lucene 索引是由多个段组成，段本身是一个功能齐全的倒排索引。
    • 段是不可变的，允许 Lucene 将新的文档增量地添加到索引中，而不用从头重建索引。
    • 对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗 CPU 的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。
  • Elasticsearch 的段合并机制：为了解决这个问题，Elasticsearch 会合并小段到一个较大的段，提交新的合并段到磁盘，并删除那些旧的小段。（段合并）

6. 详细描述一下ES更新和删除文档的过程？——记录删除段、查询后过滤即可

删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更。

• （伪）删除：磁盘上的每个段都有一个相应的 .del 文件。当删除请求发送后，文档并没有真的被删除，而是在 .del 文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在 .del 文件中被标记为删除的文档将不会被写入新段。

• 更新：在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在 .del 文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

---

7. 详细描述一下ES搜索的过程？——Query/ Fetch

搜索被执行成一个两阶段过程（查询+取出），即 Query Then Fetch

1. Query阶段：分治合并

   • 查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。
   • 每个分片在本地执行搜索并构建一个匹配文档的、大小为 from + size 的优先队列。

     PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。

   • 分片结果合并：每个分片返回各自优先队列中所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

2. Fetch阶段
   协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

---

8. 在并发情况下，ES如果保证读写一致？

1. 可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

2. 对于写操作：一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

3. 对于读操作：可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；

   如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。

---

9.ElasticSearch中的集群、节点、索引、文档、类型、分片是什么？

• 集群：是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“elasticsearch”。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分。

• 节点：是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。

• 索引：就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。

   MySQL =>数据库 　　     ElasticSearch =>索引
  

• 文档：类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。

    MySQL => Databases => 　       Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
  

• 类型：是索引的逻辑类别/分区，其语义完全取决于用户。

• 分片：因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素。

---