primary怎么读

elasticarch读写⽂档--写模型

本⽂档基于es7.1版本。较新或交旧的版本可能在个别地⽅有出⼊。

es中的每⼀个index，都被切分成多个shards存储，这每⼀个shard称之为primaryshard，并且每⼀个shard可能没有，或者有⼀个或多

个copy，这些个copy称之为replicate。primaryshard与其对应的replicate⼀起合称为replicationgroup。replicationgroup内部必须

保证同步，也既各个shard内容⼀致。否则在读数据的时候，从不同的shard会获得不同的内容，这是任何⼀个系统都不能容忍的。keep

sync的过程称之为datareplicationmodel。es使⽤primary-backup的复制模型，关于这个模型的详细介绍，可以参考微软的⼀篇论⽂。

这个我们后⾯再说。下⾯先来看看es写模型的简图：

上⾯这个是正常流程下，es的写流程，⾸先

1，客户端向es集群中某个节点发送⼀个indexdocument的请求，这个请求可能是CUD中的任⼀种。

2，接收到这个请求的节点作为coordinator，根据请求⽂档的_id或者routing值以及其他设置，计算对应的shard号，这个过程会得到⼀个

replicationgroup。因为任何的写操作必须在primaryshard上进⾏，所以还要得到primaryshard所在的节点。

3，然后coordinator会将请求转发给对应的primaryshard处理。

4，primaryshard接收到请求后，会验证变更内容的有效性，例如字段类型，长度等。

5，验证成功后，会向集群的master节点请求当前active的replicate的集合，称为in-synct。

6.

7，每个索引会有⼀个_for_active_shards的参数。表⽰primary在处理更新请求之前，需要确保有对应数量的replicate

处于active状态，⼀定程度上可以确保更新在适当数量上replicatecopy成功应⽤。如果此时active的replicatecopy数量⼩于设置值，则

请求会⼀直等待，直到超时。也就是说这个更新请求不会得到处理。

8，

9，primaryshard在本节点上处理更新，更新的过程⼤致为按照内容索引（⽣成）新记录，增加version，q_no，并标记旧的记录为

delete的，等待后台merge进程清理。如果请求携带了refresh参数的话，也会⽴即进⾏。默认情况下，refresh过程每隔

h_interval时间进⾏⼀次，refresh后，在此之前更新的记录可以被读请求获取。这⾥也会涉及到translog、gment、

commit等⼀系列概念，留在后⾯单独说明。

10，primary处理完成后，会将更新parallell发送到各个replicatecopy进⾏。

11，in-synct中可能全部成功，也可能有个别replicatecopy失败。

12，primary需要把失败的copy通知到master，由master将这些copy从in-synct中除去。同时，如果集群中有其他多余的

node，master可能会在后台挑选⼀个node，迁移copy到其上。

13，master响应已从in-sync中除去失败的copy。

14，更新请求处理完成，primaryshard返回成功到coordinator节点。

15，coordinator返回成功到客户端。

16，如果集群中有其他多余的node，master可能会在后台挑选⼀个node，迁移copy到其上。

以上，是正常流程下的写模型。

下⾯来看看异常情况:，

异常1：

这⾥的异常从第11步开始，当前处理请求的primaryshard因为⽹络分区，或其他原因造成primary⽆法连接到集群中其他replicate

copy或者master节点，此时集群已从in-synct中promote了新的primaryshard。promote的过程后⾯单独开篇。因为新的primary

shard已在集群内取得⼀致，所以in_synct中的replicatecopy拒绝reject了当前oldprimaryshard的同步请求。然后oldprimary

shard通过master得知新的primaryshard（到master的⽹络通），将请求转发到新的primaryshard上重新进⾏之前的步骤。或者old

primary停⽌处理更新请求（到master的⽹络不通）。

这个异常会导致dirtyread的并发读问题，读者可思考⼀下。

还有另外⼀种异常，异常2：

这⾥，在第9步的时候，primaryshard因为⾃⾝的原因处理失败，例如资源异常等，会主动通知master，由masterpromote新的

primaryshard出来接收请求继续处理。在这个过程中，请求会等待默认1分钟。

⼤家可以想⼀想，如果只有⼀个primaryshard，没有replicatecopy的情况下是怎样的。

总结，由上⾯两个处理模型可以看出来，es并不是⼗分的健壮，会出现只写⼀个shard的情况，以及幻读问题。同时，客户端的写请求需要

等待in-synct中的replicatecopy处理完成，降低了写性能。并且，存在⽊桶效应，整个系统的replicationgroup的写性能由最慢的那

个shard决定。