Elasticsearch: 在主分片和复制分片上执行写、检索、局部更新的必要步骤

写操作

新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。

集群结构

 

集群包含三个节点，同一集群中每个节点均知道请求的文档存在哪个节点上，均可接受请求、转发请求。 

 请求流描述：

1.  客户端给 Node 1 发送新建、索引或删除请求。
2.  节点使用文档的 _id 确定文档属于分片 0 。它转发请求到 Node 3 ，分片 0 位于这个节 点上。
3.  Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和 Node 2 的 复制节点上。当所有的复制节点报告成功, Node 3 报告成功到请求的节点，请求的节点 再报告给客户端。

节点确定文档所属分片的方式：

依据_id或自定义方式，生成hash值，然后除以主切片的数量得到一个余数(remainder)，余数即其所在分片。故主分片的数 量只能在创建索引时定义且不能修改，否则其他路由值失效了。

---

检索

文档能够从主分片或任意一个复制分片被检索。

集群结构

就上图检索流描述:

1. 客户端给node1(请求节点，任何节点均可接受请求) 发送检索请求。
2. node1通过请求文档的_id或其他计算出hash值，除以主分片后的余数得到该文档所在分片0，每个节点都有分片0，此时node1将检索请求转发给node2(对于检索请求，为了负载均衡，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。就个人理解：因为node1自身有分片0，若是第一次对分片0的请求，node1应该不会转发请求到其他节点吧？)
3. node 2 返回文档(document)给 Node 1， 然后返回给客户端。

可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。

---

局部更新文档

先读后写模式，首先主分片操作，再同步到复制分片上。

 更新流描述：

1. 客户端给 node 1 发送更新请求。
2. node1通过_id计算所在分片0，将更新请求转发到主分片所在的node3上。
3. node 3 从主分片检索出文档，修改 _source 字段的JSON，然后在主分片上重建索引。如果有其他进程修改了文档，它以 retry_on_conflict 设置的次数重复步骤3，都未成功则放弃。
4. 如果 Node 3 成功更新文档，它同时转发文档的新版本到 Node 1 和 Node 2 上的复制节点以重建索引(因为修改转发到复制分片是异步的，若操作到达顺序不对，则得到的也是损坏的文档)。当所有复制节点报告成功， Node 3 返回成功给请求节点，然后返回给客户端。