路由文档到分片中

当文档索引到ES中时，我们会通过一个计算公式计算出这个文档具体会路由到那个分片中

shard = hash(routing) % number_of_primary_shards

routing是一个可变的值，一般默认由我们文档的ID构成（也可以自己定义这个字段值），所以这个公式就是，将我们文档的ID做hash然后对主分片数进行取余，获取到，我们这个文档需要存储到那个分片中，文档路由到分片的同时，会将数据同步到其余节点这个主分片对应的副本分片中。
所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。

主分片和副本分片交互

假设我们ES中3个节点中的一个索引有2个主分片，2 个副本分片，那么，我们的请求向ES发送时，无论到达那个节点，这个节点都知道任意文档存储在那个节点那个分片中，节点之间可以互相通信，每个节点都有处理任意请求的能力，拿到请求会将请求发送到对应的分片所在的节点进行操作，同时操作结束后，会将状态同步到其余节点中。

新建、删除、索引 文档

新建、索引和删除 请求都是 写 操作， 必须在主分片上面完成之后才能被复制到相关的副本分片
以下是在主副分片和任何副本分片上面 成功新建，索引和删除文档所需要的步骤顺序：
客户端向 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 , 即大多数的分片副本状态没问题就允许执行写操作。
可以通过以下命令设置

put /index/type/id?consistency=quorum

注意，规定数量 的计算公式中 number_of_replicas 指的是在索引设置中的设定副本分片数，而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片，那规定数量的计算结果即：

int( (primary + 3 replicas) / 2 ) + 1 = 3

如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数量，也因此您将无法索引和删除任何文档
timeout:
如果没有足够的副本分片会发生什么？ Elasticsearch会等待，希望更多的分片出现。默认情况下，它最多等待1分钟。 如果你需要，你可以使用 timeout 参数 使它更早终止： 100 100毫秒，30s 是30秒。
新索引默认有 1 个副本分片，这意味着为满足 规定数量 应该 需要两个活动的分片副本。 但是，这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题，要求只有当 number_of_replicas 大于1的时候，规定数量才会执行.

取回一个文档

取回一个文档主要分为三步：
第一：请求发送到ES的主节点，主节点根据请求发送过来的文档ID（根据路由公式）确定这个文档所属的路由分片。
第二：主节点根据确定的路由分片所属的节点，将请求转发到那个节点，获取到对应ID的文档。
第三：节点将获取到的文档返回给主节点，然后返回给客户端
在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。
在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的

局部更新文档

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

基于文档的复制

当主分片把更改转发到副本分片时， 它不会转发更新请求。 相反，它转发完整文档的新版本。请记住，这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。 如果Elasticsearch仅转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档。就是说，只有当主分片的文档更改完成后会异步将更改完的文档转发至对应的副本分片，对原文档进行覆盖，而且由于是异步请求，所以文档到达的时间不是按照发送的顺序到底的，而是看资源而定。

多文档模式

mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。 它将整个多文档请求分解成 每个分片 的多文档请求，并且将这些请求并行转发到每个参与节点
协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返回给客户端
以下是使用单个 mget 请求取回多个文档所需的步骤顺序：
客户端向 Node 1 发送 mget 请求。
Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客户端。
可以对 docs 数组中每个文档设置 routing 参数

bulk请求API
bulk API 按如下步骤顺序执行：
客户端向 Node 1 发送 bulk 请求。
Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。
主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端
bulk API 还可以在整个批量请求的最顶层使用 consistency 参数，以及在每个请求中的元数据中使用 routing 参数。
bulk请求的参数的规则：
在批量请求中引用的每个文档可能属于不同的主分片， 每个文档可能被分配给集群中的任何节点。这意味着批量请求 bulk 中的每个 操作 都需要被转发到正确节点上的正确分片
bulk操作中的请求体，每一个请求都有其相应的规则，这样的结构的好处就在于，我们可以让ES直接直接读取被网络缓冲区接收的原始数据。 它使用换行符字符来识别和解析小的 action/metadata 行来决定哪个分片应该处理每个请求这些原始请求会被直接转发到正确的分片。没有冗余的数据复制，没有浪费的数据结构。整个请求尽可能在最小的内存中处理，如果将bulk中的每一个请求的包装为单独的json的话，则会导致大量的需要大量的 RAM 来存储原本相同的数据的副本，并将创建更多的数据结构，Java虚拟机（JVM）将不得不花费时间进行垃圾回收，浪费大量的资源。