深度解析：Elasticsearch写入请求处理流程

版本 Elasticsearch 8.x

原文链接：https://mp.weixin.qq.com/s/hZ_ZOLFUoRuWyqp47hqCgQ

今天来看下 Elasticsearch 中的写入流程。

不想看过程可以直接跳转文章末尾查看总结部分。最后附上个人理解的一个图。

从我们发出写入请求，到 Elasticsearch 接收请求，处理请求，保存数据到磁盘，这个过程中经历了哪些处理呢？Elasticsearch 又做了哪些操作？对于 Elasticsearch 写入一篇文档相信大家不陌生，但是Elasticsearch 的底层究竟是如何处理的呢，让我们一起来一探究竟。

写入流程

1、客户端发送写请求时，发送给任意一个节点，这个节点就是所谓的协调节点（coordinating node）。（对应图中的序号1）

2、计算文档要写入的分片位置，使用 Hash 取模算法（最新版 Hash 算法）(对应图中序号2)。

routing_factor = num_routing_shards / num_primary_shards
shard_num = (hash(_routing) % num_routing_shards) / routing_factor

3、协调节点进行路由，将请求转发给对应的 primary sharding 所在的 datanode(对应图中序号2)。

4、datanode 节点上的 primary sharding 处理请求，写入数据到索引库，并且将数据同步到对应的 replica sharding(对应图中序号3)。

5、等 primary sharding 和 replica sharding 都保存好之后返回响应(对应图中序号 4,5,6)。

路由分片算法

在7.13版本之前，计算方式如下：

shard_num = hash(_routing) % num_primary_shards

从7.13 版本开始，不包括 7.13 ，计算方式就改为了上述步骤2的计算方式。

routing_factor = num_routing_shards / num_primary_shards
shard_num = (hash(_routing) % num_routing_shards) / routing_factor

• num_routing_shards 就是配置文件中 index.number_of_routing_shard 的值。

• num_primary_shard 就是配置文件中 index.number_of_shard 的值。

• _routing 默认就是文档的 ID，但是我们可以自定义该路由值。

等待激活的分片

此处以 Create index API 举例说明，其中有一个请求参数 wait_for_active_shards。
该参数的作用就是写入请求发送到ES之后，需要等待多少数量的分片处于激活状态后再继续执行后续操作。如果所需要数量的分片副本不足，则写入操作需等待并重试，直到所有的分片副本都已经启动或者发生超时。

默认情况下，写入操作仅等待主分片处于活动状态后继续执行（即 wait_for_active_shard=1）。

• （可选）的字符串值