ES集群操作原理

路由

当你索引一个文档，它被存储在单独一个主分片上。Elasticsearch 是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片 1 还是分片 2 上的呢？

　　进程不能是随机的，因为我们将来要检索文档。

 

算法决定：

　　shard = hash(routing) % number_of_primary_shards

　　routing 值是一个任意字符串，它默认是_id 但也可以自定义。

 

为什么主分片的数量只能在创建索引时定义且不能修改？

　　如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。

所有的文档 API（get、index、delete、bulk、update、mget）都接收一个 routing参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档——例如属于同一个人的文档——被保存在同一分片上。

 

操作数据节点工作流程

每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。

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

　　1. 客户端给 Node 1 发送新建、索引或删除请求。

　　2. Node1 节点使用文档的_id 确定文档属于分片 0。它转发请求到 Node 3，分片0 主分片位于这个节点上。

　　3. Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和Node 2 的复制节点上。当所有的复制节点报告成功，Node 3 报告成功到请求的节点，请求的节点再报告给客户端。

 

replication

　　复制默认的值是 sync。这将导致主分片得到复制分片的成功响应后才返回。

　　如果你设置 replication 为 async，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。

　　上面的这个选项不建议使用。默认的 sync 复制允许 Elasticsearch 强制反馈传输。async 复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch 过载。

 

检索流程

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

1. 客户端给 Node 1 发送 get 请求。

2. Node 1 节点使用文档的_id 确定文档属于分片 0。分片 0 对应的复制分片在三个节点上都有。此时，它转发请求到 Node 2。

3. Node 2 返回文档(document)给 Node 1 然后返回给客户端。

　　　对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。

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