elasticsearch 增删改查底层原理-轻识

点击上方蓝色“迈莫coding”，选择“设为星标”

一、预备知识

在对document的curd进行深度分析之前，我们不得不了解以下几个小的知识点，不了解一下几个知识点我们将很难理解document是如何进行增删改查的。

11.1、路由（索引）与primary shard不可变

大家有没有考虑过这个问题，当你索引一个文档，它被存储在单独一个主分片上。

Elasticsearch是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片1还是分片2上的呢？进程不能是随机的，因为我们将来要检索文档。事实上，它根据一个简单的算法决定：

shard = hash(routing) % number_of_primary_shards

routing值是一个任意字符串，它默认是 _id 但也可以自定义。这个 routing 字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是 0 到 number_of_primary_shards - 1 ，这个数字就是特定文档所在的分片。

这也解释了为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。

我们演示一下这个路由的过程。假设我们有三个节点，一个student索引，对应有三个primary shard和一个replica shard。此时集群如图1所示

向该节点中插入一个document，并且我们指定_id（在es中_id可以自定义es也可以自动生成）假如_id = 1000，根据我们上面描述，此时会按照如下算法计算其会命中哪个shard。假设此时hash（1000）= 13;

shard = hash(routing) % number_of_primary_shards

即：

shard = 13 % 3 = 1；（假设hash（1000） = 13）

注：因为es的hash函数具体是怎么计算的不得而知，也不重要，我们主要是关注其原理。

根据计算可得该插入请求会命中P1，shard此时会将该document插入到P1。是不是很简单。

以上也可就是es路由的过程，也可称为es索引（这个索引是动词，理解一下）过程。

11.2、shard负载均衡与节点对等

在es集群中每个节点，每个shard（包括primary shard和replica shard）都具备处理任何请求的能力。这意味着在es集群中节点间是高度的负载均衡的，即并不是只有主节点是流量的入口，每个节点都具备处理请求的能力。primary shard和replica shard也是高度负载均衡的，因为并不是只有primary shard才具备处理curd的能力，replica shard可处理检索的请求。这也是es的性能为什么表现这么好的原因之一。

二、document增、删、改

12.1、增删改过程分析

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

关于新增document索引过程可以参考

elasticsearch document的索引过程分析
公众号：迈莫codingelasticsearch document的索引过程分析

如上图所示，从客户端发起请求到es集群向客户端响应大致可以分为以上6个阶段。

阶段1：

客户端向node1发起增、删、改请请求。node1将作为协调节点（coordinate node）进行相关工作。

阶段2：

node1根据文档 _id 计算出命中的primary shard为P1，然后将请求转发到node2，P1分片位于node2上面。

阶段3：

node2在P1上处理该请求。如果请求处理成功，node2将会把请求继续转发到其副本R1上。R1位于node3。

阶段4：

node3在R1上处理完该请求，如果成功，node3会将处理成功的消息返回给node2。

阶段5：

node2收到P1副本处理成功的消息，也就意味着该请求已经处理完成。然后将处理结果返回给node1节点。

阶段6：

协调节点node1收到响应结果后，将该结果返回给客户端。

整个过程就完成了。

看到这里大家是不是也在思考一个请求进来，我还要等待所有的分片都处理完成这个操作才算是完成，这样是不是很影响响应速度。基于这个思考，es同样也给我们提供了自定义参数的支持，比如我们可以使用replication参数来指定primary shard是不是要等到replica shard处理完成后才能响应到客户端。但是，该配置配置参数并不推荐使用，大家知道有这么个东西就行了。

replication：默认值为 sync 该值意味着primary shard需要等到其所有的副本分片都完成后才会响应客户端。如果我们将该值设置为 async ，意味着primary shard完成后就会返回给客户端，但是并不意味着其不会将请求转发到副本上，主分片依然会将请求转发到replica shard上，只不过我们不再确定副本是不是也完成了该请求，这样将不能保证数据的一致性。

12.1、写一致性保障

首先需要说明的一点，增删改其实都是一个写操作，所以这里的写指的是增删改三个操作。

这里我们所说的写一致性指的是primary shard和replica shard上数据的一致性。es API为我们提供了一个可自定的参数consistency。该参数可以让我们自定义处理一次增删改请求，是不是必须要求所有分片都是active的才会执行。

该参数可选的值有三个：one，all，quorum（default，默认）。

1 one：要求我们这个写操作，只要有一个primary shard是active活跃可用的，就可以执行。2 all：要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作3 quorum：默认的值，要求所有的shard中，必须是大部分的shard都是活跃的，可用的，才可以执行这个写操作

上面三点其实很好理解，只有quorum所谓的“大部分”感觉不是那么的明确。下面有个公式，当集群中的active（可用）分片数量达到如下公式结果时写操作就是可以执行的。否则该操作将无法进行。

int( (primary + number_of_replicas) / 2 ) + 1

依然用我们上面的例子，假设我们创建了一个student索引，并且设置primary shard为3个，replica shard有1个（这个1个是相对于索引来说的，对于主分片该数字1意味着每个primary shard都对应的存在一个副本）。也就意味着primary=3，number_of_replicas=1（依然是相对于索引）。shard总数为6。

此时计算上面公式可知：

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

也就是说当集群中可用的shard数量>=3写操作就是可以执行的。

说了这么多好像还没解释以上跟写一致性有什么关系。es对写一致性的保证就是通过quorum来保证的，以为quorum要求es集群中的可用shard数量达到一定要求才能执行。也就间接保证了shard的数据一致性。

具体使用也很简单

PUT /index/type/id?consistency=quorum

当然如果我们不指定就是使用默认的，也就是quorum。

三、document检索

document的检索过程和增删改略有不同：文档能够从主分片（primary shard）或任意一个复制分片（replicashard）被检索。

检索过程大致可以分为4个阶段

阶段1：

客户端向node1发送检索请求。node1将作为协调节点（coordinate node）进行相关工作。

阶段2：

node1根据文档 _id 计算出命中的primary shard为P1，node1会找到P1的所有副本，然后通过round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡。假如此时随机选取的是P1，node1会将该请求转发到P1对应的节点上。