1、单节点集群

分配 3 个主分片和一份副本（每个主分片拥有一个副本分片）

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

通过 elasticsearch-head 插件查看集群情况，我们的集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在 node-1 。

表示当前集群的全部主分片都正常运行，但是副本分片没有全部处在正常状态。当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。

2、故障转移

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

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

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

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

 {
  "number_of_replicas" : 2
 }
 

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

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

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

3、应对故障

我们关闭第一个节点，这时集群的状态为:关闭了一个节点后的集群。在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这 些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片， 此时集群的状态将会为 yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

4、路由计算

当索引一个文档的时候，文档会被存储到一个主分片中。 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 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定 义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被 存储到同一个分片中。

5、分片控制

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

5.1、写流程

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

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

客户端向 Node 1 发送新建、索引或者删除请求。

节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的 主分片目前被分配在 Node 3 上。

Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调 节点向客户端报告成功。

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

consistency：

consistency，即一致性。在默认设置下，即使仅仅是在试图执行一个写操作之 前，主分片都会要求 必须要有 规定数量(quorum)（或者换种说法，也即必须要 有大多数）的分片副本处于活跃可用状态，才会去执行写操作(其中分片副本 可以是主分片或者副本分片)。这是为了避免在发生网络分区故障（network partition）的时候进行写操作，进而导致数据不一致。规定数量即： int( (primary + number_of_replicas) / 2 ) + 1 consistency 参数的值可以设为 one （只要主分片状态 ok 就允许执行写操 作）,all（必须要主分片和所有副本分片的状态没问题才允许执行写操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行写 操作。 注意，规定数量 的计算公式中 number_of_replicas 指的是在索引设置中的设定 副本分片数，而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片，那规定数量的计算结果即： int( (primary + 3 replicas) / 2 ) + 1 = 3 如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数 量，也因此您将无法索引和删除任何文档。

timeout ：

如果没有足够的副本分片会发生什么？ Elasticsearch 会等待，希望更多的分片出 现。默认情况下，它最多等待 1 分钟。 如果你需要，你可以使用 timeout 参数 使它更早终止： 100 100 毫秒，30s 是 30 秒。

5.2、写流程

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

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

客户端向 Node 1 发送获取请求。

节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个 节点上。 在这种情况下，它将请求转发到 Node 2 。

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

5.3、更新流程

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

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

客户端向 Node 1 发送更新请求。

它将请求转发到主分片所在的 Node 3 。

Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片 的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次 后放弃。

如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的 副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回 成功，协调节点向客户端返回成功。

5.4、多文档操作流程

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

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

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

客户端向 Node 1 发送 mget 请求。

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

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

客户端向 Node 1 发送 bulk 请求。

Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节 点主机。

主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或 删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功， 该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。