Elasticsearch 7.x入门学习-系统架构与工作流程

1 核心概念

1.1 索引（Index）

Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能。

一个索引就是一个拥有相似特征的文档集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母），并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录就可以看成是索引，通过目录定位可以提高查询速度。

1.2 类型（Type）

在Elasticsearch 6及之前版本在一个索引中，可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常会为具有一组共同字段的文档定义一个类型。不同的版本，类型（Type）有不同的变化。

1.3 文档（Document）

一个文档是一个可被索引的基础信息单元，也就是一条数据。比如：你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以 JSON（Javascript Object Notation）格式来表示，而 JSON 是一个到处存在的互联网数据交互格式。在一个 Index/Type 里面，你可以存储任意多的文档。

1.4 字段（Field）

相当于是数据表的字段，对文档数据根据不同属性进行的分类标识。

1.5 映射（Mapping）

Mapping是处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的，其它就是处理 ES 里面数据的一些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。

1.6 分片（Shards）

一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有 10 亿文档数据的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。或者单个节点处理搜索请求，响应太慢。为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片很重要，分片允许水平分割 / 扩展内容容量。而在分片之上还可以进行分布式的、并行的操作，进而提高性能和吞吐量。至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由Elasticsearch 管理的，对于作为用户的你来说，这些都是透明的，无需过分关心。

1.7 副本（Replicas）

在网络环境中Elasticsearch节点有随时宕机的可能行，在某个分片/节点处于离线状态的情况下，有一个故障转移机制显得格外重要。为此Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做副本分片。

副本分片的两大作用：

• 在分片/节点失败的情况下，提供了高可用性。为保证可用性，副本分片不能与主分片置于同一节点上。

• 扩展吞吐量，因为搜索可以在所有的副本上并行运行。

总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。

分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是在创建完成后不能改变分片的数量。默认情况下，Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有 1 个主分片和另外 1 个复制分片（1 个完全拷贝），这样的话每个索引总共就有 2 个分片，我们需要根据索引需要确定分片个数。

1.8 分配（Allocation）

分配就是将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由 master 节点完成的

2 系统架构

一个运行中的 Elasticsearch 服务实例称为一个节点，而集群是由一个或者多个拥有相同cluster.name 配置的节点组成， 这些节点共同承担数据和负载的压力。当加入新节点到集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。

作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。Elasticsearch 对这一切的管理都是透明的。

3 单节点集群搭建

下面从单节点集群搭建开始逐步配置副本节点，水平扩容，应对故障。

我们首先在包含一个单节点集群内创建名为 users 的索引，我们将对user集群分配 3个主分片和一份副本（每个主分片拥有一个副本分片）。配置参数如下：

{
    "settings": {
        "number_of_shards": 3,
        "number_of_replicas": 1
    }
}

该配置下Elasticsearch集群单节点部署下的分片情况示例图：

通过浏览器 elasticsearch-head 插件查看实际的集群情况

集群健康值yellow(3 of 6)表示当前集群的全部主分片都正常运行，但是副本分片没有全部处在正常状态。

3个主分片正常， 3 个副本分片都是 Unassigned —— 它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。

我们的集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在node-1001。在硬件故障时有丢失数据的风险。我们下面就要启动副本节点实现分片冗余存储。

4 副本节点

当集群中只有一个节点在运行时，意味着会有单点故障问题。 但是再启动一个节点即可防止数据丢失。在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。只有在同一台机器上运行的节点才会自动组成集群。在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。

如果启动了第二个节点，我们的集群将会拥有两个节点的集群 : 所有主分片和副本分片都已被分配。（如果没有分配分片到新增加的节点的话，就要在主节点的配置文件中添加配置cluster.routing.allocation.disk.threshold_enabled: false，这个配置会根据磁盘的使用情况限制分配分片，所以需要把这个配置关闭。）

集群节点示例图如下，Node1节点下都是主分片，Node2节点下都是副本分片

通过 elasticsearch-head 插件查看集群情况

集群健康值：green，表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行

node-1001节点 3 个主分片正常，node-1002节点 3 个副本分片正常。当第二个节点加入到集群后，3 个副本分片被分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。所有新增加被索引的文档都将会保存在主分片上，然后被并行得复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

点击分片可以看到有个属性primary告诉我们这个分片是主分片还是副本分片：
主分片primary属性为true，副本分片primary属性为false

5 水平扩容

我们怎么对运行中的集群按需扩容呢？现在当我们启动了第三个节点，集群将会拥有三个节点 ，Elasticsearch 为了分散负载而对分片进行重新分配。

集群节点分片示例图：

通过 elasticsearch-head 插件查看实际的集群情况和分片分布情况。集群健康值：green表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。

node-1001和node-1002上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有 2 个分片，而不是之前的 3 个。 这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个节点的性能将会得到提升。

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。 我们这个拥有 6 个分片（3 个主分片和 3 个副本分片）的索引可以最大扩容到 6 个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。但是如果我们想要扩容超过 6 个节点怎么办呢？

首先主分片的数目在索引创建时就已经确定了下来不能改变。实际上这个数目定义了这个索引能够存储的最大数据量（实际大小取决于你的数据、硬件和使用场景）。 但是读操作（搜索和返回数据）可以同时被主分片或副本分片所处理，所以拥有越多的副本分片时，就拥有越高的吞吐量。

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2。

{
 "number_of_replicas" : 2
}

users 索引现在拥有 9 个分片：3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍。

而在不添加节点的情况下，配置副本分片，集群节点分片情况示例图如下：

通过 elasticsearch-head 插件查看实际的集群情况

如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少， 需要增加更多的硬件资源来提升吞吐量。虽然不能提高性能，但是配置更多的副本分片数可以提高了数据冗余量，按照上面的节点配置，可以在失去 2 个节点的情况下不丢失任何数据。

6 应对故障

当前Node-1001节点包含了主分片1，副本分配0和2。现在关闭Node-1001主节点，集群的状态转换为:关闭了一个节点后的集群。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node-1002。在我们关闭Node-1001的同时也失去了主分片1，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。

幸运的是，在其它节点上存在着主分片1的完整副本，通过 elasticsearch-head 插件查看实际的集群情况。 可以看到新的主节点将主分片1在 Node-1002上对应的副本分片提升为主分片， 此时集群的状态将会为yellow。这个提升主分片的过程是瞬间发生的。

那么为什么当前的集群状态是 yellow 而不是 green 呢？

虽然当前拥有user索引所有的三个主分片，但是因为同时设置了每个主分片需要对应 2 份副本分片，而此时集群中每个主分片只存在一份副本分片。 所以集群不能为 green 的状态。不过当前的集群状态下，即使我们同样关闭了 Node-1002 ，依然可以保持在不丢任何数据的情况下运行，因为Node-1003 为每一个分片都保留着一份副本。

如果我们重新启动 Node-1001，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。 如果 Node-1001依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件，和之前的集群相比，只是Master主节点切换了。

7 路由计算

Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，Elasticsearch如何决定这个文档应当被存储在分片1 还是分片 2 中呢？

这是根据下面这个公式决定的：

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

这就是为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。

8 分片控制

我们假设有一个集群由三个节点组成。 它包含一个叫 emps 的索引，有两个主分片，每个主分片有两个副本分片。相同分片的副本不会放在同一节点。

我们可以发送请求到集群中的任一节点，每个节点都有能力处理任意请求，每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在上面的例子中，将所有的请求发送到 Node 1，我们将其称为协调节点(Coordinating Node) 。当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。

数据写流程

新建、索引和删除请求都是写操作， 必须在主分片上面完成之后才能被复制到相关的副本分片

新建，索引和删除文档所需要的步骤顺序：

1. 客户端向 Node 1 发送新建、索引或者删除请求。
2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的主分片目前被分配在 Node 3 上。
3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点Node 1报告成功，协调节点Node 1向客户端报告成功。

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很少使用，因为 Elasticsearch 已经很快，但是为了完整起见，请参考下面表格：

新索引默认有 1 个副本分片，这意味着为满足规定数量应该需要两个活动的分片副本。 但是，这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题，要求只有number_of_replicas 大 于1 的时候，规定数量才会执行。

数据读流程

我们可以从主分片或者从其它任意副本分片检索文档

从主分片或者副本分片检索文档的步骤顺序：

1. 客户端向 Node 1 发送获取请求。
2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。 在这种情况下，它将请求转发到 Node 2 。
3. Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。

在处理读取请求时，协调节点在每次请求的时候都会通过轮询确定主分片的所有的副本分片来达到负载均衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

更新流程

部分更新一个文档结合了先前说明的读取和写入流程：

部分更新一个文档的步骤如下：

1. 客户端向 Node 1 发送更新请求。
2. 它将请求转发到主分片所在的 Node 3 。
3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次后放弃。
4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回成功，协调节点向客户端返回成功。

当主分片把更改转发到副本分片时， 它不会转发更新请求。 而是转发完整文档的新版本。这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。 如果Elasticsearch 仅转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档。

多文档操作流程

mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。它将整个多文档请求分解成每个分片的多文档请求，并且将这些请求并行转发到每个参与节点。

协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返回给客户端

用单个 mget 请求取回多个文档所需的步骤顺序:

1. 客户端向 Node 1 发送 mget 请求。
2. Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到每个所需的主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客户端

bulk API， 允许在单个批量请求中执行多个创建、索引、删除和更新请求。

bulk API 按如下步骤顺序执行：

1. 客户端向 Node 1 发送 bulk 请求。
2. Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。
3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。