es的读和写-Reading and writing documents
Introduction
每个Elasticseach 中的索引都被分割到分片中，每个分片可以有多个副本。这些副本叫做复制组(d 这里是自己翻译的具体叫什么还需要同步下)。当文档被添加或者删除的时候复制组要保持同步。如果同步失败，从这个副本中读取和其他副本中对比将会导致不同的结果。保持分片复制的过程并在副本中读取这个过程我们称之为 data replication model. （数据复制模型）
Elasticsearch 的数据复制模型基于primary-backup model（主备模型）。这种模型（ PacificA paper ）描述的非常好。模型基于副本集群中一个单独的副本作为主分区。其他的副本分区叫做replica shard 副本分区。primary shard 提供了所有的索引操作的入口点。它负责验证他们并保证是正确的。一旦索引操作已经被primary 分区接受，primary 通常会负责复制操作到其他副本中。
本章的目的是给大家提供一个高级别Elasticsearch 复制模型视图并讨论他们的写入和读取操作中各种各样的交互实现。（翻译的不太好）
Basic write model
Elasticsearch集群中每个索引操作第一件事情就是使用路由映射索引到复制组中，通常来讲是基于文档ID，一旦复制组确认，操作将会转发到当前的复制组中的主分区。这个步骤我们叫做 coordinating stage.
文档写入的下一个阶段是primary stage ，并在主分片上执行。主分片负责验证操作并转发操作到其他的分片副本。一旦分片副本下线，primary 就不需要复制数据到所有的副本。
然而，Elasticsearch维护了一组分片副本来接收操作，这个列表叫做in-sync 副本，由master维护，就像名字暗示的那样，他们是好的分片副本，他们会保证处理所有的index 写入和删除操作会被用户确认。主分片负责维护分片的一致性并且复制所有的操作到每个副本。
The primary shard follows this basic flow:
- 验证输入的操作如果结构非法则拒绝它，必须期望一个数字类型，但是传来的是object
- 本地执行写入或者删除相关的文档，通常也会验证字段的内容，如果不正确也会拒绝，比如说字段内容过长
- Forward the operation to each replica in the current in-sync copies set. If there are multiple replicas, this is done in parallel.转发操作到每一个在in-sync 副本中的每一个副本，如果有多个副本，则并行执行。
- Once all in-sync replicas have successfully performed the operation and responded to the primary, the primary acknowledges the successful completion of the request to the client.一旦所有的in-sync副本成功的执行了操作并且回应了primary，primary 会确认client请求是否完全成功。
Each in-sync replica copy performs the indexing operation locally so that it has a copy. This stage of indexing is the replica stage.
每个当前同步副本组中的副本在本地执行索引操作所以副本会有数据副本，这个阶段叫做replica stage
每个同步副本在本地执行索引操作，以保有数据副本。这一索引处理阶段称为副本阶段。
这些索引写入的步骤（coordinating，primary，replica）是顺序的，为了保证内部的重试机制，每个阶段的存活周期包含每个阶段的下一个阶段。举个例子来说，coordinating stage 直到每个primary 阶段在不同的主分片中完成才完成。每个primary stage 直到in-sync阶段完成了写入到本地回复给复制请求完成才完成。
Failure handling
很多事情都会导致写入错误，磁盘可能会损坏，node 可能会与其他节点失联。或者配置错误导致的写入副本失败，尽管在主分区执行成功。这些错误很少见但是primary 不得不作出响应。
在这个例子中primary失败了，node托管主分区将会发送一条消息到master。写入操作将会等待（默认是1分钟）master 升级一个新的副本分区为主分区，操作将会转发到新的主分区来处理。主意master通常会监控node的健康，然后决定降级primary。这种情形一般是因为网络问题导致node持有的主分区和集群隔离（See here for more details.）
一旦在主分区中执行成功主分区(primary)将不得不处理在副本分区中潜在的风险。这也许是硬件上的失败也可能是网络的问题导致操作到达不了副本，或者是阻止副本响应primary。不管怎么说都会导致相同的结果，一个属于in-sync的副本集合会丢失一个确认操作，为了避免这种不一致，primary 回发送一条消息到master，请求有问题的分片从in-sync 中删除。只有在删除那个分片被master确认后，primary 分区才会通知操作，通常master 回指示另一个node开始构建一个新的分区副本，为了恢复系统的健康状态
当转发操作到副本，primary 主分区将会使用副本去验证他是不是是活跃的主分区（primary）.如果primary 主分区因为网络问题或者长时间的gc 导致隔离，在被察觉后被降级之前他回继续处理操作，操作来自于一个不正常的主分区那么副本将会拒绝他的请求。当主分区接受到副本分区的拒绝响应，那是因为它不再是主分区了，然后主分区会联系master并且主分区会感知到自己已经被替换。然后这些操作将会路由到新的主分区
| 没有副本会发生什么？ This is a valid scenario that can happen due to index configuration or simply because all the replicas have failed. In that case the primary is processing operations without any external validation, which may seem problematic. On the other hand, the primary cannot fail other shards on its own but request the master to do so on its behalf. This means that the master knows that the primary is the only single good copy. We are therefore guaranteed that the master will not promote any other (out-of-date) shard copy to be a new primary and that any operation indexed into the primary will not be lost. Of course, since at that point we are running with only single copy of the data, physical hardware issues can cause data loss. See Active shards for some mitigation options. |
Basic read model
读操作在es中可以是非常轻量级的查询根据id，或者是很重的复杂的聚合查询会导致显著的cpu消耗。primary-backup 模型的精妙之处在于保持所有的分片副本数据一致（除了正在执行的操作），因此 一个单独的in-sync的copy（同步副本）可以服务大量的读请求。
当读请求被node 接受后，node负责转发read request到相关分片的node，聚合响应并响应client。我们称之为 请求的协调节点(coordinating node)
The basic flow is as follows:
- 映射读请求到相关的分片，注意当大部分的查询将会路由到一个或多个索引。通常需要从多个分片中读取，每个分片都代表了一组不同的数据子集。
- 从分片副本组中查询活跃的相关分片的副本。既可以从主分区中或者副本分片中读取，默认Elasticsearch使用 adaptive replica selection 查询分片副本。
- 发送分级分片读请求到被选中的副本（这里很重要什么是分级分片读请求）
- 合并结果并响应，注意如果是通过id查询，仅仅一个分片所以这些步骤可以跳过。
Shard failures
当分片响应给客户端失败的时候，协调节点会发送请求到其它的分片副本中，若连续多次失败，则可能导致该分片的所有副本均不可用。"
为了保证快速响应，以下的APIs会响应部分数据 如果一个或者多个分片响应失败：
- Search
- Multi Search
- Multi Get
响应包含部分结果依然会返回200的状态码。分片响应失败会通过timed_out and _shards字段在http header中展示。
A few simple implications
这些基本的流程决定了Elasticsearch系统中读和写的行为，此外当读和写请求并发执行时，这两个基本流程影响着彼此，所以这会导致一些原生的特性。
Efficient reads: 在正常运行的情况下 每个读请求都会在相关的复制组中执行一次，仅仅在失败的条件下采会在相同分片中的多个副本中执行相同的查询。
Read unacknowledged: 当主分区在本地写入索引后，然后复制数据到其它的副本，在这个期间并发读取是可能读取到还未确认的数据，也就是说主分区的数据还没同步到副本分区。
Two copies by default: 该模型可以实现容错功能，就算仅仅维护两个副本的数据。与quorum-based 系统对比最小的副本数量是3（这里要打个问号为什么仅仅通过两份数据就可以实现容错功能。如果脑裂了也可以嘛）
Failures
在失败的情况下以下情况是可能的:
A single shard can slow down indexing
单分片写入速度会变慢。
因为主分区会等待所有的in-sync 中的副本分区响应。一个单独分片会变慢整个复制组。这些代价也就是上面提到过的读效率（Efficient reads）所付出的。当然一个变慢的分区也会导致路由到这个分区的搜索。
脏读
当主分片（primary）与集群隔离时，其写入操作可能无法获得确认。这是因为被隔离的主分片只有在向副本分片发送请求或尝试联系主节点（master）时，才会意识到自己已处于隔离状态。而此时，该操作已被索引到主分片中，可能被并发读取操作访问到。Elasticsearch 通过默认每秒 ping 一次主节点（默认频率）来降低此风险，若无法感知到主节点，则会拒绝后续索引操作。"
The tip of the iceberg
This document provides a high level overview of how Elasticsearch deals with data. Of course, there is much more going on under the hood. Things like primary terms, cluster state publishing, and master election all play a role in keeping this system behaving correctly. This document also doesn’t cover known and important bugs (both closed and open). We recognize that GitHub is hard to keep up with. To help people stay on top of those, we maintain a dedicated resiliency page on our website. We strongly advise reading it.
本篇文档提供了一个Elasticsearch如何处理数据的高级视图。当然还有很多复杂的原理隐藏在冰川下。像是 primary term（主分片版本号用来解决脑裂问题），集群状态发布和集群选举所有机制确保系统行为的正确。本文档也不包含已知的和重要的bug。我们认识到GitHub 很哪保持他们的最新状态（ GitHub is hard to keep up with）。为了帮助人们保持对这些事情更加清晰，我们维护了一个专门的可信的页面在我们的页面上（ resiliency page），我们强力建议读一读它。