ElasticSearcch6.4 — Reading and Writing documents 译

读写文档

介绍

ElasticSearch中的每个索引都分为多个主分片，每个主分片有多次复制，复制的这些版本被认作是副本群组，并且在添加和删除的时候必须保持一致，如果我们不这样做，那么从一个副本分片读取的内容可能就和从另一个副本分片读取的内容不一样了，保持主分片和副本分片同步， 保持从主分片和副本分片读取的内容一致称为数据复制模型。

Elasticsearch的数据复制模型主要基于主备份模型，并在微软研究院的PacificA论文中得到了很好的描述，复制组中的一个副本作为主分片，其他拷贝被称为副本分片，主分片作为全部索引操作的入口点，它负责校验他们，并确定他们是正确的，一旦索引操作被主分片接受，它同时也会负责将这个操作复制给其他副本分片。

这章节目的是对ElasticSearch复制模型进行更高级概述，并讨论他对读写操作之间的各种交互的影响。

读写模型

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

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

1. 校验进入的请求并拒绝无效的结构（例如：预期数字字段但传入了对象字段）
2. 在本地执行索引或删除索引相关操作，也会校验字段的内容并根据需要拒绝（例如：关键字太长，无法在Lucene中进行索引）
3. 转发操作到每个副本分片，如果有多个副本分片，这个操作是并行的
4. 一旦所有的副本分片都成功执行了操作并对主分片作出响应，主分片确认成功地完成了对客户端的请求。

失败处理

索引过程可能会出现很多问题--磁盘被损坏，节点彼此之间断开连接，或者一些配置错误可能导致副本上的操作失败，尽管它在主服务器上成功，这些都是不常见的，但是主分片必须作出回应。

在主分片自身失败的情况下，托管主分片的节点将会向它的master发送消息，索引操作将等待（默认情况下最多一分钟）master将其中的一个副本升级为新的主分片，这个操作也会转发给新的主分片处理，master节点也会监控节点的运行状况并决定主动降级主分片，这通常发生在持有主分片的节点因为网络问题脱离集群，请参阅 here了解更多。

一旦主分片执行成功，它就必须处理当它在副本分片上执行时发生的潜在的错误，这个操作无法到达副本分片或者无法得到副本分片响应的原因可能是副本分片的实际故障或者网络问题。这些最终都有同样的结果：作为同步分片集合的部分副本分片将忽略被确认的操作，为了避免违反不变量，主分片会向master节点发送移除有问题的副本分片的请求，只有master节点确认删除了有问题的分片，主分片才能确认操作，请注意，master节点还会指导另一个节点开始构建新的副本分片，为了系统恢复到正常状态。

当转发请求到副本分片时，主分片将会使用副本分片校验它自己仍是一个活跃的主分片，如果主分片由于网络分区（或长GC）被隔离，在它意识到自己被降级之前，它将会继续处理进来的索引操作，来自这个旧的主分片的操作会被副本分片拒绝，当主分片接收到副本分片因为它不再是主分片而拒绝它请求的响应时，它会连接到master节点，了解到自己被替换，然后转发到新的主分片上。

 

如果没有副本分片会发生什么？

由于索引的配置或者仅仅因为所有的副本分片都失败了，所以这是一个有效的场景，在这种情况下，主分片在处理操作的时候没有任何校验，这可能是有问题的，另一方面，主分片不能自己让其他分片失败，而是请求master节点代表自己这样做，这意味着master知道主分片是唯一的一个好的拷贝。

基础读模式

在Elasticsearch中读取数据可以通过ID轻量级查找或者一个带复杂聚合的重搜索请求，需要有很好的CPU功率支持，主备份模型保持所有副本分片相同（异常操作除外），因此，单个同步的拷贝足以提供读取请求。

当读取请求被一个节点接受，它负责将其转发到保存相关分片的节点，整理响应以及响应给客户端，我们称这个节点为请求的协调节点，基本流程如下：

1. 解决读取请求到相关分片，请注意，大多数搜索将会发送到一个或者多个索引，通常需要从很多分片中读取数据，每个代表不同的数据集。
2. 从分片复制组里面查找出每个相关分片的活跃拷贝，可以是主分片或者副本分片，默认情况下，ElasticSearch只会简单的在拷贝分片之间轮训。
3. 将分片级请求发送到所选拷贝。
4. 结合结果和响应，请注意，通过ID查找的情况下，只有一个分片是相关的，可以跳过该步骤。

失败处理

当分片响应读取请求失败时，协调节点会在同一个副本群组里查找另一个拷贝，并将搜索请求发送给这个拷贝，重复的失败可能导致没有可获取的分片，这种情况下，例如_search，ElasticSearch将快速的响应，虽然有部分结果，而不是等待问题解决（部分结果在响应的_shards头中指出）

 

一些简单的定义

每一个基本流程都决定了ElasticSearch系统如何表现为读取和写入数据，此外，由于读取和写入可以同时执行，所以这两个基本流彼此相互作用，这有一些定义：

高效读取

正常操作下，每个相关复制群组执行一次读取操作，只有在故障条件下，才会在多个拷贝的同一分片上执行相同的搜索。

读取未确认

由于主分片首先在本地进行索引，然后向副本分片发送请求，在它确认之前可能一个同时的读取操作已经看到了。

默认两个拷贝

该模型可以容错，同时只保留两个数据拷贝，这与基于法定数量的系统形成对比，其中容错的最小副本数为3。

失败

失败情况下，有以下可能：

单个分片可能减慢索引

因为主分片在每个操作都会等待同步副本集合中的所有副本，这是我们为以上提及的读取效率付出代价，当然，单个缓慢的分片也会减慢已经发送给它的不幸的搜索。

脏读

隔离的主分片会暴露没有确认的写入。这是由于隔离的主分片只有在向其副本发送请求或者向主节点发送请求时才会被隔离。在这一点上，操作已经被索引到主分片并且可以通过并发读取。Elasticsearch通过每秒钟（默认情况下）ping主节点来减轻这种风险，如果没有主节点，则拒绝索引操作。

提示

本文档提供了ElasticSearch如何处理数据更高级的描述，当然，底层还有更多更多的事情，像主要术语的东西，集群状态发布和master节点选举等都扮演着保持系统正常运行的角色， 本文档不包括已知或者重要的bug，我们认识到GIthub很难跟上 GitHub is hard to keep up with，为了帮助人们掌握这些优势，我们在网站上维护了一个专门的弹性页面resiliency page。我们强烈建议阅读它。