ElasticSearch（七）：分片控制

目录

分片控制

写流程

 读流程

更新流程

多文档操作流程

分片控制

我们假设有一个集群由三个节点组成。 它包含一个叫 emps 的索引&＃xff0c;有两个主分片&＃xff0c;每个主分片有两个副本分片。相同分片的副本不会放在同一节点。

通过elasticsearch-head插件查看集群情况&＃xff0c;所以我们的集群是一个有三个节点和一个索引的集群。

我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置&＃xff0c;所以可以直接将请求转发到需要的节点上。 在下面的例子中&＃xff0c;将所有的请求发送到 Node 1&＃xff0c;我们将其称为 协调节点(coordinating node) 。

&＃xff1a;当发送请求的时候&＃xff0c; 为了扩展负载&＃xff0c;更好的做法是轮询集群中所有的节点。

写流程

新建、索引和删除 请求都是 写 操作&＃xff0c; 必须在主分片上面完成之后才能被复制到相关的副本分片

新建&＃xff0c;索引和删除文档所需要的步骤顺序&＃xff1a;

1. 客户端向 Node 1 发送新建、索引或者删除请求。
2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3&＃xff0c;因为分片 0 的主分片目前被分配在 Node 3 上。
3. Node 3 在主分片上面执行请求。如果成功了&＃xff0c;它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功&＃xff0c;协调节点向客户端报告成功。

在客户端收到成功响应时&＃xff0c;文档变更已经在主分片和所有副本分片执行完成&＃xff0c;变更是安全的。

有一些可选的请求参数允许您影响这个过程&＃xff0c;可能以数据安全为代价提升性能。这些选项很少使用&＃xff0c;因为Elasticsearch已经很快&＃xff0c;但是为了完整起见&＃xff0c;请参考下面表格&＃xff1a;

新索引默认有 1 个副本分片&＃xff0c;这意味着为满足规定数量应该需要两个活动的分片副本。 但是&＃xff0c;这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题&＃xff0c;要求只有当 number_of_replicas 大于1的时候&＃xff0c;规定数量才会执行。

 读流程

我们可以从主分片或者从其它任意副本分片检索文档

从主分片或者副本分片检索文档的步骤顺序&＃xff1a;

1. 客户端向 Node 1 发送获取请求。
2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。 在这种情况下&＃xff0c;它将请求转发到 Node 2 。
3. Node 2 将文档返回给 Node 1 &＃xff0c;然后将文档返回给客户端。

在处理读取请求时&＃xff0c;协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。在文档被检索时&＃xff0c;已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下&＃xff0c;副本分片可能会报告文档不存在&＃xff0c;但是主分片可能成功返回文档。 一旦索引请求成功返回给用户&＃xff0c;文档在主分片和副本分片都是可用的。

更新流程

部分更新一个文档结合了先前说明的读取和写入流程&＃xff1a;

部分更新一个文档的步骤如下&＃xff1a;

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

当主分片把更改转发到副本分片时&＃xff0c; 它不会转发更新请求。 相反&＃xff0c;它转发完整文档的新版本。请记住&＃xff0c;这些更改将会异步转发到副本分片&＃xff0c;并且不能保证它们以发送它们相同的顺序到达。 如果Elasticsearch仅转发更改请求&＃xff0c;则可能以错误的顺序应用更改&＃xff0c;导致得到损坏的文档。

多文档操作流程

mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。它将整个多文档请求分解成 每个分片 的多文档请求&＃xff0c;并且将这些请求并行转发到每个参与节点。

协调节点一旦收到来自每个节点的应答&＃xff0c;就将每个节点的响应收集整理成单个响应&＃xff0c;返回给客户端

用单个 mget 请求取回多个文档所需的步骤顺序:

1. 客户端向 Node 1 发送 mget 请求。
2. Node 1 为每个分片构建多文档获取请求&＃xff0c;然后并行转发这些请求到托管在每个所需的主分片或者副本分片的节点上。一旦收到所有答复&＃xff0c; Node 1 构建响应并将其返回给客户端。

可以对 docs 数组中每个文档设置 routing 参数。

bulk API&＃xff0c; 允许在单个批量请求中执行多个创建、索引、删除和更新请求。

bulk API 按如下步骤顺序执行&＃xff1a;

1. 客户端向 Node 1 发送 bulk 请求。
2. Node 1 为每个节点创建一个批量请求&＃xff0c;并将这些请求并行转发到每个包含主分片的节点主机。
3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时&＃xff0c;主分片并行转发新文档&＃xff08;或删除&＃xff09;到副本分片&＃xff0c;然后执行下一个操作。 一旦所有的副本分片报告所有操作成功&＃xff0c;该节点将向协调节点报告成功&＃xff0c;协调节点将这些响应收集整理并返回给客户端。