Elasticsearch——读写文档

目录

1.介绍

2.基础写模型

故障处理

3.基础读模型

故障处理

4.一些简单的影响

5.故障

翻译源:Elasticsearch 6.4 文档


1.介绍

Elasticsearch中的每一个索引都会被切片然后每一个切片都会有多份复制。

这些复制被称作复制组,并且当文档被添加或移除时,复制组中的复制必须保证同步。

如果做不到这一点,从一个复制中读取的结果将与从其他复制中读取的结果有很大的不同。

保证切片复制之间的同步并且基于此提供读服务的过程称之为数据备份模型。

Elasticsearch的数据备份模型基于主-备份模型。

此模型基于让备份组中的一份单独复制作为主切片实现。其他的复制称为备份切片。

主切片作为所有索引操作的主进入点。它负责验证这些操作,以确保它们正确。

当一个索引操作被主切片接收后,主切片负责将这些操作复制给其他的备份切片。

2.基础写模型

Elasticsearch中的每一个索引操作通常基于文档ID解析给使用路由备份组。

一旦备份组被确认,此操作便会在内部转发给备份组的当前主切片。主切片负责验证操作并将其转发给其他的备份切片。

由于副本可以脱机,主切片不需要将操作复制给所有的备份切片。

相反,Elasticsearch维护一份应该接收操作的备份切片的列表。这个列表称为in-sync cpoies,由master结点维护。

这个列表中的切片保证完成用户承认的索引与删除操作。

由于主切片负责保证不变性,所以主切片会将操作复制给此列表中的每一个备份切片。

主切片遵从以下基本流:

  1. 验证进入的操作,如果结构上无效(例如:对象字段中设置了数字),拒绝操作。
  2. 本地执行操作,此时仍会验证字段内容陪,如果有必要(例如:关键字值对于Lucene索引过长),拒绝执行。
  3. 转发操作给当前in-sync副本集合中的每一个副本。如果存在多个副本,并行执行此操作。
  4. 一旦所有的副本全部执行成功并且响应主切片,主切片向客户端确认请求完成。

故障处理

在索引构建期间,许多事情都可能出现故障——硬盘可能损坏,结点可能失去与其他结点的连接或者一些错误的配置可能导致一个操作尽管在主切片上执行成功发但是在备份结点上执行失败。

这些错误较为罕见,但是主切片需要应对它们。

当主切片自身出错时,持有主切片的结点会向主服务器发送一条信息。

索引操作会等待一分钟左右,等待主服务器将一个备份切片提为主切片。

然后索引操作会被发给新的主切片进行执行。

注意主服务器还会监控结点健康状态,可能会主动给主切片降级。这通常发生在主切片因为网络问题从集群中独立时。

一旦操作在主切片上成功执行,主切片就不得不应对当将操作执行在备份切片上时潜在的执行失败问题。

这可能由于备份切片上实际执行失败,也可能由于网络问题,阻止了操作到达备份切片或阻止了备份切片的回应。

所有这些都导致了一个相同的结果:in-sync备份集合中的一个备份切片错过了一个即将被承认的操作。

为了防止损害不变性,主切片向主服务器发送了一条信息请求从in-sync备份集合中移除有问题的切片。

只有主服务器承认切片的移除,主服务器才会承认此操作。

注意,主服务器还会指示其他结点开始构建新的切片副本用以恢复系统的健康状态。

当主切片转发操作给备份切片时,主切片将会使用备份切片检验自身是否仍是活动主切片。

如果主切片由于网络分区或长GC从集群中脱离,在它意识到自身已经被降级之前,它可能会继续执行进入的索引操作。

来自过期主切片的操作将会被备份切片拒绝。

当主切片接收到由于自身不再是主切片而被备份切片拒绝请求的回应时,它将会向主服务器发出询问然后得知自身已经被取代。

操作已经按路径发送到新的主切片。

如果不存在备份切片会发生什么?

由于索引配置或只是因为所有的备份全部挂了,所以这是一个可能发生的有效场景。

在这种情况下,主切片在没有外部检验的情况下执行操作,这似乎存在问题。

另一方面,主切片不会在自身上的其他切片上执行操作失败,但是会请求主切片代替自身这样做。

这意味着,主服务器知道主切片时唯一的可用备份。

因此主服务器不会将其他(过期)切片备份提升为新的主切片,并且任何主切片执行的操作都不会丢失。

当然,因为在这时只有一份数据备份切片在工作,所以物理硬件问题将会造成数据丢失。

3.基础读模型

Elasticsearch中的读操作可以是通过ID实现的轻量级查找,也可以是调用CPU大量性能的伴随着复杂聚合的重量级搜索请求。

主-备份模型的一个优势就是它保持所有的切片副本相同。因此,单个in-sync备份足以服务度读请求。

当一个结点接收到一个读请求,此结点将会将其发送给持有相关切片的其他结点,整理回应,然后响应客户端。此节点称为协调结点。

基本流如下:

  1. 解析读请求到相关切片。注意由于搜索将会被发送给一个或多个索引,它们通常需要从多个切片中进行读操作,每个切片代表数据的不同子集。
  2. 从备份切片组中选出每份相关切片的活跃备份。这可以是主切片也可以是备份切片。默认情况下,Elasticseach将会在切片备份中循环。
  3. 发送切片级读请求到选出的备份。
  4. 结合请求与响应。注意在通过ID进行查找的情况下,只有一个切片相关并且这个步骤被跳过。

故障处理

当一个切片没能响应读请求时,协调结点将会从相同备份组中选出其他备份,并且将切片级请求发送给备份。

反复的失败可能导致没有切片备份可用。

在某些情况下,例如_search,Elastisearch倾向于快速响应,尽管只有部分结果,代替等待问题被解决(部分结果将会在响应的_shards首部表示)。

4.一些简单的影响

这些基础流决定了Elasticsearch应对读与写的行为。而且,由于读与写请求可以并发执行,这两个基本流互相影响彼此。

高效读

在正常操作下,每个读操作会在每个相关备份组上执行一次。只有在失败条件下,会在多分相同片的备份上执行相同搜索。

不被承认的读

由于主切片先本地执行索引操作,然后再复制请求,所以在写操作被承认之前,一个并发读操作可能看见这个变化。

默认两个备份

此模型同时维护两份备份便可以容错。这与基于合法数量的系统需要最少三分备份才能完成容错不同。

5.故障

单备份切片会降低索引速度

因为主切片在执行每一个操作期间都会等待in-sync备份集合中所有的切片完成操作,所以单个切片会减慢整个备份组的执行速度。当然,单切片的执行缓慢也会减缓路由到此切片的搜索操作。

脏读

脱机主切片可以暴露不被承认的写操作。这是因为只有当脱机主切片发送请求到备份副本或接触主服务器之后,脱机主机才会意识到自己已经脱机。此时,一个索引操作已经在此主切片上执行,并且可以被并发读读取。Elasticsearch通过每秒(默认)ping一次主机并且如果ping不到主服务器时拒绝索引操作来降低脏读的风险。


翻译源:Elasticsearch 6.4 文档

猜你喜欢

转载自blog.csdn.net/qq_32165041/article/details/82998616