ElasticSearch（九）------ElasticSearch知识点整理

た入场券 2023-07-06 13:21 130阅读 0赞

## 1、为什么要使用Elasticsearch? ##

Elasticsearch是一个基于ApacheLucene™的开源搜索引擎。无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。

**1、对比Lucene**

ES即为了解决原生Lucene使用的不足，优化Lucene的调用方式，并实现了高可用的分布式集群的搜索方案

ES也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的 RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

**2、对比关系型数据库**

**es查询速度更优**

存储同样容量的大数据，进行关键字查询，mysql数据库查询速度慢。

原因：在数据库做模糊查询时，如LIKE语句进行左模糊查询，索引失效，它会遍历整张表，同时进行字符串匹配。

**es支持分词**

数据库并不支持分词，如查询：Elasticsearch安装步骤，数据库通常只能把这几个字去进行全部匹配。

**es支持相关度评分**

Elasticsearch能很好地支持相关性评分。通过合理的优化，云搜索服务能够返回精准的结果，满足用户的需求。  
Elasticsearch支持全文搜索和相关度评分。这样在返回结果就会根据分数由高到低排列。分数越高，意味着和查询语句越相关。

## 2、ES中节点类型和各个节点的分工？ ##

[ElasticSearch（八）------节点类型和各个节点的分工][ElasticSearch_------]

## 3、Elasticsearch中的倒排索引是什么？ ##

倒排索引（Inverted Index）也叫反向索引，有反向索引必有正向索引

1、正排索引是文档 Id 到文档内容、单词的关联关系，也就是说可以通过 Id获取到文档的内容。

2、倒排索引是单词到文档 Id 的关联关系，也就是说了一通过单词搜索到文档 Id。

> 倒排索引的查询流程是：首先根据关键字搜索到对应的文档 Id，然后根据正排索引查询文档 Id 的完整内容，最后返回给用户想要的结果。

**倒排索引**

倒排索引是搜索引擎的核心，主要包含两个部分：

• 单词词典（Trem Dictionary）：记录的是所有的文档分词后的结果。
    							单词字典的实现一般采用B+Tree的方式，来保证高效
    • 倒排列表（Posting List）：记录了单词对应文档的集合，由倒排索引项（Posting）组成。

**倒排索引项（Posting）主要包含如下的信息：**

• 文档ID，用于获取原始文档的信息
    
    • 单词频率（TF，Term Frequency），记录该单词在该文档中出现的次数，用于后续相关性算分。
    
    • 位置（Position），记录单词在文档中的分词位置（多个），用于做词语搜索。
    
    • 偏移（Offset），记录单词在文档的开始和结束位置，用于高亮显示。
    
    es存储的是一个json的内容，其中包含很多字段，每个字段都会有自己的倒排索引。

**正排索引**

搜索的时候，要依靠倒排索引：排序的时候，需要依靠正排索引，看到每个document的每个field，然后进行排序，所谓的正排索引，其实就是doc values。

在建立索引的时候，一方面会建立倒排索引，以供搜索用；一方面建立正排索引，也就是doc values，以供排序，聚合，过滤等操作使用。

doc values是被保存在硬盘上的，此时如果内存足够，os会自动将其缓存在内存中，性能还是会很高的，如果内存不足够，os会将其写入磁盘上。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70]

**倒排索引的底层实现是基于**

> fst（finite state transducer）数据结构

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

1、空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；

2、查询速度快。o(len(str))的查询时间复杂度。

## 4、ElasticSearch中的集群、节点、索引、文档、类型是什么？ ##

**集群**

集群是一个或多个节点（服务器）的集合，它们共同保存整个数据，并提供跨所有节点的联合索引和搜索功能。

集群由唯一名称标识（集群的名字），默认情况下为“elasticsearch”。

此名称很重要，因为如果节点设置为按名称加入群集，则同名的Elasticsearch节点会加入同一个集群。

确保不要在不同的环境中重用相同的集群名称，否则最终会导致节点加入错误的群集。例如，您可以使用logging-dev，logging-stage以及logging-prod 用于开发，生产集群。

请注意，拥有一个只包含单个节点的集群是完全正常的。

此外，您还可以拥有多个独立的集群，每个集群都有自己唯一的集群名称。

**节点**

节点是作为集群一部分的单个服务器（可以理解为单个Elasticsearch实例，一个进程），存储数据并参与集群的索引和搜索功能。

与集群一样，节点由名称标识，默认情况下，该名称是在启动时分配给节点的随机通用唯一标识符（UUID）。

如果不需要默认值，可以定义所需的任何节点名称。此名称对于管理目的非常重要，您可以在其中识别网络中的哪些服务器与Elasticsearch集群中的哪些节点相对应。

可以将节点配置为按群集名称加入特定群集。

默认情况下，每个节点都设置为加入一个名为cluster的集群elasticsearch，这意味着如果您在网络上启动了许多节点并且假设它们可以相互发现 - 它们将自动形成并加入一个名为的集群elasticsearch。（节点的集群名默认都是elasticsearch）

在单个群集中，您可以拥有任意数量的节点。

此外，如果您的网络上当前没有其他Elasticsearch节点正在运行，则默认情况下启动单个节点将形成一个名为elasticsearch的新单节点集群。

**索引(index)**

索引是具有某些类似特征的文档集合。

例如，您可以拥有客户数据的索引，产品目录的一个索引以及订单数据的一个索引。

索引由名称标识（索引名必须全部为小写），并且此名称用于在对其中的文档执行索引，搜索，更新和删除操作时引用索引。

在单个集群中，您可以根据需要定义任意数量的索引。

一个索引就相当于传统数据库中的一个数据库实例。

**类型(type)**

在6.0.0中弃用。  
一种类型，曾经是索引的逻辑类别/分区，允许您在同一索引中存储不同类型的文档，例如一种类型用于用户，另一种类型用于博客帖子。

之后不再可能在索引中创建多个类型，并且将在更高版本中删除类型的整个概念。

type相当于传统数据库中的表，Elasticsearch已经将这个概念废弃，一个库（index）只有一张表（默认名为\_doc）。所以我们的type统一使用\_doc即可。避免以后升级兼容问题。

**文档(document)**

文档是可以索引的基本信息单元。

例如，您可以为单个客户提供文档，为单个产品提供另一个文档，为单个订单提供另一个文档。

该文档以JSON（JavaScript Object Notation）表示，JSON是一种普遍存在的互联网数据交换格式。

在索引/类型中，您可以根据需要存储任意数量的文档。

请注意，尽管文档实际上位于索引中，但实际上必须将文档分配给索引中的类型（如上所述，使用\_doc）。

文档的概念相当于传统数据库中的数据行（record）,只是recode是结构化的，字段确定，文档中的字段不确定，字段数量也不确定。适合非结构化数据存储。

## 5、elasticsearch 索引数据多了怎么办，如何调优，部署 ##

索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在后”，

这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户

检索或者其他业务受到影响。

**5.1、 动态索引层面**

基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索

引的模板格式为：blog\_index\_时间戳的形式，每天递增数据。

这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的

32 次幂-1，索引存储达到了 tb+甚至更大。

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

**5.2、 存储层面**

冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。

对于冷数据不会再写入新数据，可以考虑定期 force\_merge 加 shrink 压缩操作，

节省存储空间和检索效率。

**5.3、部署层面**

一旦之前没有规划，这里就属于应急策略。

结合 es 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注

意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的。

## 4、ElasticSearch中的分片是什么？ ##

**分片（shard）**

如果一个索引具有很大的数据量，它的数据量可能会超出单个节点的容量限制（硬盘容量），而且单个节点数据量过大，执行性能也会随之下降，每个搜索请求的执行效率都会降低。

为了解决上述问题， Elasticsearch 提出了分片的概念，索引将划分成多份，称为分片。当创建索引时，可以很简单的指定想要的分片数量。每个分片都是功能齐全的，独立的“索引”，驻留在集群的各个节点中。

> 分片有助于横向扩展，N个分片会被尽可能平均地（rebalance）分配在不同的节点上

> 分片是独立的，对于一个Search Request的行为，每个分片都会执行这个Request。

> Elasticsearch 中的分片其实就是 Lucene 索引。，所以一个分片只能存放 Integer.MAX\_VALUE - 128 = 2,147,483,519 个docs。

> 默认索引是5个分片，一个副本（即5primary+5replica=10个分片）；主分片和备分片不会出现在同一个节点上（防止单点故障）

> 分片一定设置是不可以修改的，只能新建新索引解决

## 5、ElasticSearch中的副本是什么？ ##

**故障转移/集群恢复**

如果持有主分片的节点挂了，一个副本分片就会晋升为主分片  
在索引写入时，副本分片做着与主分片相同的工作。新文档首先被索引进主分片然后再同步到其它所有的副本分片。增加副本数并不会增加索引容量。

**通过副本进行负载均衡**

索性能取决于最慢的节点的响应时间，所以尝试均衡所有节点的负载是一个好想法。 如果我们只是增加一个节点而不是两个，最终我们会有两个节点各持有一个分片，而另一个持有两个分片做着两倍的工作。

我们可以通过调整副本数量来平衡这些。通过分配两份副本而不是一个，最终我们会拥有六个分片，刚好可以平均分给三个节点

## 6、ElasticSearch中的分析器是什么？ ##

**适用于西文字符**

Elasticsearch的分析器（analyzer）包括三部分

1、字符过滤器：他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将 & 转化成 `and`等。

2、分词器：简单的分词器遇到空格或标点的时候讲文本拆分为词条（Token）。

3、Token过滤器：改变词条（eg: Quick --> quick）;删除词（eg: a ,the ,and）; 增加同义词（eg: jump == leap）

**适用于中文分词的，如IKAnalyzer**

IKAnalyzer分词器采用的是“正向迭代最细粒度切分算法”。有两种可选模式 ：细粒度(ik\_max\_word)和最大词长(ik\_smart)

## 7、Elasticsearch是如何实现Master选举的？ ##

Elasticsearch中的Master并不像mysql、hadoop集群的master那样，它既不是集群数据的唯一流入点，也不是所有元数据的存放点。所以，一般情况下Elasticsearch的Master负载是很低的。  
Elasticsearch的Master有一项工作是其他节点做不到的，那就是维护集群状态。

**集群状态中包括以下信息：**

> 集群层面的设置  
> 集群内有哪些节点  
> 各索引的设置，映射，分析器和别名等  
> 索引内各分片所在的节点位置

上述的集群状态信息，由Master节点进行维护，并且同步到集群中所有节点。也就是说集群中的任何节点都存储着集群状态信息，但只有Master能够改变信息

Elasticsearch自带有一套选举机制。如果是集群扩容加一个节点进来，那么肯定会跟随之前集群已有的Master。如果是集群刚刚启动，这个时候就需要进行Master的选举。

**master选举谁发起，什么时候发起**

master选举由候选master节点发起，当一个master-eligible节点发现满足以下条件时发起选举：

1、master-eligible节点的当前状态不是master。  
2、该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点，没有任何节点连接到master。  
3、包括本节点在内，当前已有超过minimum\_master\_nodes个节点没有连接到master。

即一个master-eligible节点发现包括自己在内的多数派的master-eligible节点认为集群没有master时，就可以发起master选举。

**选举算法**

**Bully算法**

比较常见的一种算法，它假定所有的节点都有一个唯一id，并对根据id进行排序。然后选举出最大的id，作为Master。这种方法的弊端是容易造成一种反复选举的情况。比如最大的id负载过大，导致假死，这个时候选举出第二大的最为Master。过一会第一大的id恢复了，又选最大的作为Master，然后又假死，反反复复。

Elasticsearch的解决方法是通过推迟选举直到当前Master失效之后，才会进行新的Master选举。但是这种做法也有个弊端，就是会产生脑裂，同时选举多个Master出来。这里Elasticsearch的做法是采用投票过半数的方式来决定Master，避免脑裂。关于脑裂文章的最后会详细说明。

**选举时间**

集群重启

Master挂掉，其他节点检测到Master死亡，会触发重新选举。

**新Master获取最新集群状态**

新选举出的Master并不一定具备最新的集群状态，它是通过gateway 模块来实现集群状态的持久化和恢复

**脑裂**

个集群分裂成两个集群，出现了两个Master。这里如果要避免脑裂要配置discovery.zen.minimum\_master\_nodes=N/2+1。这个配置的意思是说在选举Master的过程中，需要多少个节点通信，说白点就是票数。如果达不到N/2+1，就是超过半数，就会选举失败，重新选举。

**关于脑裂的优化：**

#一个节点多久ping一次，默认1s
    discovery.zen.fd.ping_interval: 1s
    ##等待ping返回时间，默认30s
    discovery.zen.fd.ping_timeout: 10s
    ##ping超时重试次数，默认3次
    discovery.zen.fd.ping_retries: 3
    ##选举时需要的节点连接数
    discovery.zen.minimum_master_nodes=N/2+1

参考：https://blog.csdn.net/xiaoyu\_BD/article/details/82016395

## 8、Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？ ##

当集群master候选数量不小于3个时，可以通过设置最少投票通过数量`discovery.zen.minimum_master_nodes=N/2+1`超过所有候选节点一半以上来解决脑裂问题；  
当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题。

## 9、详细描述一下Elasticsearch索引文档的过程。 ##

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center]

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

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

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

**如果面试官再问：第二步中的文档获取分片的过程？**

借助路由算法获取，路由算法就是根据路由和文档 id 计算目标的分片 id 的过程。

1shard = hash(_routing) % (num_of_primary_shards)

## 10、详细描述一下Elasticsearch更新和删除文档的过程。 ##

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

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

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

## 11、详细描述一下Elasticsearch搜索的过程。 ##

**搜索类型**

**1、query and fetch**  
向索引的所有分片（shard）都发出查询请求，各分片返回的时候把元素文档（document）和计算后的排名信息一起返回。这种搜索方式是最快的。因为相比下面的几种搜索方式，这种查询方法只需要去shard查询一次。但是各个shard返回的结果的数量之和可能是用户要求的size的n倍。

**2、query then fetch（默认的搜索方式）**

如果你搜索时，没有指定搜索方式，就是使用的这种搜索方式。这种搜索方式，大概分两个步骤，第一步，先向所有的shard发出请求，各分片只返回排序和排名相关的信息（注意，不包括文档document)，然后按照各分片返回的分数进行重新排序和排名，取前size个文档。然后进行第二步，去相关的shard取document。这种方式返回的document与用户要求的size是相等的。

**query 阶段的目的：定位到位置，但不取。**

**步骤拆解如下：**

1、假设一个索引数据有 5 主+1 副本 共 10 分片，一次请求会命中（主或者副本

分片中）的一个。

2、每个分片在本地进行查询，结果返回到本地有序的优先队列中。

3、第 2）步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。

**fetch 阶段的目的：取数据。**

路由节点获取所有文档，返回给客户端。

**3、DFS query and fetch**

这种方式比第一种方式多了一个初始化散发(initial scatter)步骤，有这一步，据说可以更精确控制搜索打分和排名。

**4、DFS query then fetch**  
比第2种方式多了一个初始化散发(initial scatter)步骤。

## 12、Elasticsearch在部署时，对Linux的设置有哪些优化方法？ ##

**1、关闭缓存 swap**

内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。

> Linux内核为了提高读写效率与速度，会将文件在内存中进行缓存，这部分内存就是Cache Memory(缓存内存)。即使你的程序运行结束后，Cache Memory也不会自动释放。这就会导致你在Linux系统中程序频繁读写文件后，你会发现可用物理内存变少。当系统的物理内存不够用的时候，就需要将物理内存中的一部分空间释放出来，以供当前运行的程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间被临时保存到Swap空间中，等到那些程序要运行时，再从Swap分区中恢复保存的数据到内存中。这样，系统总是在物理内存不够时，才进行Swap交换。

如果实际环境不允许禁用掉swap，你可以尝试降低swappiness。此值控制操作系统使用交换区的积极性。这可以防止在正常情况下使用交换区，但仍允许操作系统在紧急情况下将内存里的东西放到交换区。

**2、堆内存设置为：min（节点内存/2, 32gb）;**

ElasticSearch的默认设置中，给服务分配了1GB的堆空间。这个值都太小了.

建议是：64 GB 内存的机器是非常理想的，50%的可用内存给ElasticSearch堆，剩下的50%保持自由

**堆内存不要超过32GB**

JVM的对象指针压缩只能在堆小于32GB的场景下使用。

> 在Java中，所有的对象都在堆中分配，并通过一个指针引用。普通对象指针（OOP - Ordinary object pointers）会指向这些对象，指针的长度是CPU的本地字长：32bit或64bit，这取决于处理器。引用指针里存储的是一个确切的内存地址。  
> 在32位操作系统中，这意味这堆的最大大小是4GB。对于64位系统来说，堆可以很大，但是64位指针意味着会占用更多的空间，因为指针长度更长了。比浪费空间更糟糕的是，更长的指针在主存储和高速缓存之间移动时，需要占用更大的带宽（LLC，L1等等）。  
> Java使用了一种被称为压缩指针的方法来解决这个问题。压缩指针指的是，不再用指针指向内存中的精确地址，而是将引用指向一个对象偏移量（object offsets）。这意味着一个32位的指针可以指向40亿的对象，而不是40亿位（byte）。最终，这意味着在指针压缩的情况下，堆依然采用32位指针，但允许增长到32GB的物理大小。  
> 一旦超过了这个神奇的30-32GB的边界，指针会切换会普通对象指针（oop）。指针的大小增长，更多的CPU至内存带宽使用，你在大量的损失调有效内存。实际上，一个40至50GB的堆相当于一个32GB的使用了引用压缩的堆。

**3、设置最大文件句柄数；**

当前用户所有进程能打开的最大文件数量。

Lucene 使用了大量的文件。同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符

Too many open files 错误

**4、线程池+队列大小根据业务需要做调整；**

**5、磁盘存储 raid 方式——存储有条件使用 raid10，增加单节点性能以及避免单节点存储故障。**

## 13、在并发情况下，Elasticsearch如果保证读写一致？ ##

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

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

对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数\_preference为primary来查询主分片，确保文档是最新版本。

**ES 数据并发冲突控制是基于的乐观锁和版本号的机制**

一个document第一次创建的时候，它的\_version内部版本号就是1；以后，每次对这个document执行修改或者删除操作，都会对这个\_version版本号自动加1；哪怕是删除，也会对这条数据的版本号加1(假删除)。

客户端对es数据做更新的时候，如果带上了版本号，那带的版本号与es中文档的版本号一致才能修改成功，否则抛出异常。如果客户端没有带上版本号，首先会读取最新版本号才做更新尝试，这个尝试类似于CAS操作，可能需要尝试很多次才能成功。乐观锁的好处是不需要互斥锁的参与。

es节点更新之后会向副本节点同步更新数据(同步写入)，直到所有副本都更新了才返回成功。

**2、另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。**

但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

我们在发送任何一个增删改操作的时候，比如PUT /index/type/id，都可以带上一个consistency参数，指明我们想要的写一致性是什么？

PUT /index/type/id?consistency=quorum

one：要求我们这个写操作，只要有一个primary shard是active状态，就可以执行。  
all：要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作。  
quorum：默认值，要求所有的shard中，必须是大部分的shard都是活跃的，可用的，才可以执行这个写操作。

**3、设置 replication 为 sync(默认)**

这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数\_preference 为 primary 来查询主分片，确保文档是最新版本。

replication：默认值为sync,主分片得到复制分片的成功响应后才返回。

async，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点是否成功。

默认的sync复制允许Elasticsearch强制反馈传输。async复制可能导致在不等待其他分片就绪的情况下发送过多的请求二使Elasticsearch过载

## 14、如何监控 elasticsearch 集群状态？ ##

Kibana是一个基于Node.js的Elasticsearch索引库数据统计工具，可以利用Elasticsearch的聚合功能，生成各种图表，如柱形图，线状图，饼图等

## 15、是否了解字典树？ ##

## 16、拼写纠错是如何实现的？ ##

拼写纠错是基于编辑距离来实现；

编辑距离是一种标准的方法，它用来表示经过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数；

> Elasticsearch 指定了 fuzziness 参数支持对最大编辑距离的配置，默认为 ２

GET /my_index/my_type/_search
    {
      "query": {
        "fuzzy": {
          "text" : {
            "value": "hello",  // 输入的关键词
            "fuzziness": 2  // 编辑距离，最多允许有2个字母写错
          }
        }
      }
    }

## 17、客户端在和集群连接时，如何选择特定的节点执行请求的？ ##

一般来说，客户端会连到一个负载均衡的接入点，由负载均衡定义的规则选择后端进行连接，客户端一般不主动选择特定的节点执行请求。

TransportClient 利用 transport 模块远程连接一个 elasticsearch 集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的 transport 地址，并以 轮询 的方式与这些地址进行通信。

[ElasticSearch_------]: https://yilei.blog.csdn.net/article/details/107947829
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200220174155679.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200814220708175.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70#pic_center