Elasticsearch(二) 文档读写

介绍
Elasticsearch中的每个索引都分为分片，每个分片可以有多个副本。这些副本称为复制组，并且在添加或删除文档时必须保持同步。如果失败了，从一个副本读取将导致与从另一个读取相比非常不同的结果。保持分片复制同步并从中读取的过程就是所说的数据复制模型。

Elasticsearch的数据复制模型基于（primary-backup model ）主备模型，并在Microsoft Research的 PacificA 论文中得到很好的描述。该模型基于具有作为主分片的复制组的单个副本。其他副本称为副本分片。主用作所有索引操作的主要入口点。负责验证，确保正确。一旦索引操作被主接受，主负责将操作复制到其他副本。

本节的目的是给出弹性搜索复制模型的高级概述，并讨论它对写操作和读操作之间的各种交互的影响。

写操作
Elasticsearch中的每个索引操作首先通过使用路由（通常基于文档ID）解析为复制组。一旦确定了复制组，操作将在内部转发到组的当前主分片。主分片负责验证操作并将其转发给其他副本。由于副本可以脱机，因此不需要主要复制到所有副本。相反，Elasticsearch会维护一个应该接收操作的分片副本的列表。该列表称为同步副本，由主节点维护。顾名思义，这些是一组“好”的碎片副本，保证已经处理了所有已被确认给用户的索引和删除操作。主分片负责维护这个不变量，因此必须将所有操作复制到此集合中的每个副本。

主分片遵循以下基本流程：

1. 验证传入值，如果结构无效，则拒绝它（示例：具有预期数字的对象字段）
2. 在本地执行操作，即索引或删除相关文档。验证字段的内容并拒绝（如果需要）（示例：关键字值太长，无法在Lucene中进行索引）。
3. 将当前同步复制集中的操作转发到每个副本。如果有多个副本，这是并行完成的。
4. 一旦所有的副本都成功地执行了操作并对主应用程序作出响应，主要确认成功地完成了对客户端的请求。

错误处理
索引过程中可能会出现许多问题 - 磁盘可能会损坏，节点可能会断开连接，否则某些配置错误可能导致副本上的操作失败，尽管它在主服务器上成功。这些不常见，但是主分片必须做出回应。

在主分片本身失败的情况下，托管主节点的节点将向主人发送关于它的消息。索引操作将等待（默认情况下最多1分钟），以便主节点 master 将其中一个副本升级为新的主。然后将该操作转发到新的主分片。请注意，master还监控节点的运行状况，并可能决定主动降级主节点。这通常发生在保持主节点的节点与网络问题与集群隔离的情况下。

一旦主分片操作成功地执行了，那么在复制分片上执行时，主要处理潜在的失败。这可能是由于副本上的实际故障或由于网络问题导致操作无法到达副本​​（或防止副本响应）引起的。所有这些都具有相同的最终结果：作为同步复制集合的一部分的副本将忽略即将被确认的操作。为了避免违反不变量，主要向主机发送消息，请求从同步复制集合中删除有问题的分片。只有一旦拆卸了分片才被主人确认，主要确认操作。请注意，master还将指示另一个节点开始构建新的分片副本，以便将系统恢复到正常状态。

在将操作转发到副本时，主要将使用副本来验证它仍然是主动的。如果主要由于网络分区（或长GC）隔离，则可能会在意识到已降级之前继续处理传入的索引操作。来自陈旧的操作将被副本拒绝。当主接收到来自拒绝其请求的响应时，因为它不再是主要的，所以它将接触到主，并将学习它已被替换。然后将操作路由到新的主服务器。

读请求

Elasticsearch中的读取可以通过ID进行非常轻量级的查找，或者具有复杂的聚合的 重度搜索请求，很消耗CPU功率。主备份模式的一个优点是它保持所有分片副本相同（飞行前操作除外）。因此，单个同步复制足以提供读取请求。

当节点接收到读请求时，该节点负责将其转发到保存相关分片的节点，整理响应以及响应客户端。我们称该节点为该请求的协调节点。基本流程如下：

1. 将读请求解析为相关分片。请注意，由于大多数搜索将发送到一个或多个索引，它们通常需要从多个分片中读取，每个分片表示数据的不同子集。
2. 从分片复制组中选择每个相关分片的活动副本。这可以是主要或副本。默认情况下，弹性搜索只会在分片副本之间循环。
3. 将分片级读取请求发送到所选副本。
4. 归并结果并响应。请注意，在通过ID查找的情况下，只有一个分片是相关的，并且可以跳过该步骤。

当分片未能响应读请求时，协调节点将从同一复制组中选择另一个副本，并将该分片级搜索请求发送给该副本。 重复故障可能导致没有碎片副本可用。 在某些情况下，如_search，Elasticsearch将更愿意快速响应，尽管部分结果，而不是等待该问题得到解决（部分结果在响应的_shards标题中指出）。

问题
这些基本流程中的每一个确定了Elasticsearch如何表现为读取和写入系统。 此外，由于可以同时执行读写请求，所以这两个基本流彼此相互作用。 这有一些固有的问题：

高效读取
在正常操作下，每个相关复制组执行一次读取操作一次。 只有在故障条件下，同一个分片的多个副本才能执行相同的搜索。
读取未确认
由于主要首先在本地进行索引，然后复制请求，所以并发读取可以在确认之前已经看到更改。
默认为两份
该模型可以容错，同时只保留两个数据副本。 这与大多数分布式系统相反，它们的容错的最小份数为3。