ElasticSearch集群数据读写流程

前言

本章作为ElasticSearch分布式集群的附属章节，主要讲解ElasticSearch集群环境下数据是如何读写的，既然讲到读写，那么ElasticSearch的更新就是基于二者的结合，顺带也讲一下！

ElasticSearch集群数据写流程

ElasticSearch集群的数据写流程大致如这样:假设客户端现在要发一条数据，这时客户端并不知道具体要连接到那台机器上的，客户端是先到达集群，然后通过路由计算得到具体要连接的ElasticSearch，(其实我们连接的时候可能连接的是Node-2，但是通过路由计算后，得到的可能是其他节点)，当我们通过路由得到具体的分片P0后，那么就开始往P0上写数据，当主分片P0数据写完后，开始往P0的副本上写数据，当副本R0写完数据了，会向主分片P0发送反馈，告诉主分片P0副本R0已经写完了，然后P0会先客户端进行反馈。那么整个写流程就是这样的。

在客户端收到成功响应时,文档变更已经在主分片和所有副本分片执行完成,变更是安全的。,有一些可选的请求参数允许影响这个过程,可能以数据安全为代价提升性能。这些选项很少使用,因为Elasticsearch已经很快,(其实也就是在主分片完成写操作后即可查询，不必要等到副本写完！)但是为了完整起见,参数设置请参考如下！

consistency： consistency,即一致性。在默认设置下,即使仅仅是在试图执行一个写操作之前,主分片都会要求必须要有规定数量(quorum) (或者换种说法,也即必须要有大多数)的分片副本处于活跃可用状态,才会去执行写-操作(其中分片副本可以是主分片或者副本分片),这是为了避免在发生网络分区故障(networ kpartition)的时候进行写-操作,进而导致数据不一致。一规定数量即:int( (primary + number_of_replicas) /2) +1 即(主分片+副本数)/2+1 consistency参数的值可以设为one (只要主分片状态ok就允许执行-写操作) ,all (必须要主分片和所有副本分片的状态没问题才允许执行写操作),或quorum 。默认值为quorum ,即大多数的分片副本状态没问题就允许执行写操作。 注意,规定数量的计算公式中number_of_replicas指的是在索引设置中的设定副本分片数,而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片,那规定数量的计算结果即:int( (primaly + 3 replicas)/2)+1 -3 如果此时你只启动两个节点,那么处于活跃状态的分片副本数量就达不到规定数量,也因此您将无法索引和删除任何文档。

timeout: 如果没有足够的副本分片会发生什么? Elasticsearch会等待,希望更多的分片出现。默认情况下,它最多等待1分钟。如果你需要,你可以使用timeout参数使它更早终止: | 100 100毫秒, 30s是30秒。

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

ElasticSearch集群数据读流程

集群如下，当我们要查询的数据只在P0和P0的副本R0上有数据，当客户端发起查询的时候还是一样的，不知道连接具体哪一个节点，那么就连接任意一个，即为协调节点，即连接Master节点，这时读取的数据正好在Master上的P0中有，这里并不一定会直接访问P0，而是去查找相同节点即P0和R0，然后在P0和R0两个节点轮询。这样是为了负载均衡！

更新流程

单条数据更新
部分更新一个文档结合了先前说明的读取和写入流程，当客户端发起更新操作时，请求到达任意节点如Node1 ，(即协调节点)，然后协调节点根据路由计算到达指定节点，如P0，也就是查询到需要更改的数据在P0上面，这是会不断的更新P0(不断更新，这是因为别的进程也在更新，这时可能由于抢占锁的这个概念需要不断尝试等待获取锁所以需要不断的更新抢占锁)，一旦抢占锁成功了那么就可以写了，当P0写入完成后，就会同步所有的副本R0

多数据批量更新
mget和bulk API的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。它将整个多文档请求分解成每个分片的多文档请求,并且将这些请求并行转发到每个参与节点。 协调节点一旦收到来自每个节点的应答,就将每个节点的响应收集整理成单个响应,返回给客户端