Elasticsearch文档读写模型实现原理

  1. 在主分片上执行操作(例如索引、更新或删除一个文档)。如果执行过程中出错,直接返回错误。

  2. 将操作转发到当前同步副本集的每个副本。如果有多个副本,则并行执行。(in-sync当前可用、激活的副本)。

  3. 一旦所有的副本成功地执行了操作并对主服务器进行了响应,主服务器就会承认对客户机的请求的成功完成。写请求的流程如下图所示(图片来源于《Elasticsearch权威指南》):

在这里插入图片描述

错误处理:

在索引过程中,许多事情可能会出错——磁盘可能会被破坏,节点可以彼此断开,或者一些配置错误可能导致一个副本的操作失败,尽管它在主服务器上是成功的。这些都是罕见的,但主要的是要对它们做出反应。

另外一种情况是如果主服务器不可用,托管主节点的节点将向master发送一条消息。索引操作将等待(默认情况下最多1分钟),以便master服务器将其中一个副本提升为一个新的主节点。然后,该操作将被转发到新的主服务器进行处理。请注意,主服务器(master)还监控各个节点的健康状况,并可能决定主动降级主节点。这通常发生在持有主节点的节点通过网络问题与集群隔离的情况下。为了更好的理解master服务器与主分片所在服务器的关系,下面给出一个ElasticSearch的集群说明图:

在这里插入图片描述

其中NODE1为整个集群的master服务器,而第一个复制组(P0,R0,RO,其主分片所在服务器NODE3),第二个复制组(P1,R1,R1,其主分片所在服务器NODE1)。

一旦在主服务器上成功执行了操作,主服务器就必须确保数据最终一致,即使由于在副本上执行失败或由于网络问题导致操作无法到达副本(或阻止副本响应)造成的。为了避免数据在复制组内数据的不一致性(例如在主分片中执行成功,但在其中一两个复制分片中执行失败),主分片在如果未在指定时间内(默认一分钟)未收到复制分片的成功响应或是收到错误响应,主分片会向Master服务器发送一个请求,请求从同步副本中删除有问题的分片,当主分片确认删除有问题的副本时,Master会指示删除有问题的副本。同时,master还会指示另一个节点开始构建新的分片副本,以便将系统恢复到一个健康状态。

主分片将一个操作转发到副本时,首先会使用副本数来验证它仍然是活动的主节点。如果由于网络分区(或长GC)而被隔离,那么在意识到它已经被降级之前,它可能会继续处理传入的索引操作并转发到从服务器。来自陈旧的主服务器的操作将会被副本拒绝。当主接受到来自副本的响应为拒绝它的请求时,此时的主分片会向Master服务器发送请求,最终将知道它已经被替换了,后续操作将会路由到新的主分片服务器上。

如果没有副本,那会发生什么呢?

这是一个有效的场景,可能由于配置而发生,或者是因为所有的副本都失败了。在这种情况下,主分片要在没有任何外部验证的情况下处理操作,这可能看起来有问题。另一方面,主分片服务器不能自己失败其他的分片(副本),而是请求master服务器代表它这样做。这意味着master服务器知道主分片是该复制组唯一的可用拷贝。因此,我们保证master不会将任何其他(过时的)分片副本提升为一个新的主分片,并且任何索引到主分片服务器的操作都不会丢失。当然这样意味着我们只使用单一的数据副本,物理硬件问题可能导致数据丢失。请参阅Wait For Active Shards,以获得一些缓解选项,(该参数项将在下一节中详细描述)。

注:在一个ElasticSearch集群中,存在两个维度的选主。Master节点的选主、各个复制组主分片的选主。详细的原理分析将在源码分析篇深入学习。

3、基本读模型

在Elasticsearch中,可以通过ID进行非常轻量级的查找,也可以使用复杂的聚合来获取非平凡的CPU能力。主备份模型的优点之一是它使所有的分片副本保持相同(除了异常情况恢复中)。通常,一个同步副本就足以满足读取请求。

当一个节点接收到read请求时,该节点根据路由规则负责将其转发给相应的数据节点,对响应进行整理,并对客户端作出响应。我们称该节点为该请求的协调节点。基本流程如下:

  1. 将读请求路由到到相关的分片节点。注意,由于大多数搜索条件中不包含分片字段,所以它们通常需要从多个分片组中读取数据,每个分片代表一个不同的数据子集(默认5个数据子集,因为ElasticSearch默认的主分片个数为5个)。

  2. 从每个分片复制组中选择一个副本。读请求可以是复制组中的主分片,也可以是其副本分片。在默认情况下,ElasticSearch分片组内的读请求负载算法为轮询。

  3. 根据第二步选择的各个分片,向选中的分片发送请求。

  4. 汇聚各个分片节点返回的数据,然后返回个客户端,注意,如果带有分片字段的查询,将之后转发给一个节点,该步骤可省略。

异常处理:

当一个碎片不能响应一个read请求时,协调节点将从同一个复制组中选择另一个副本,并将碎片级搜索请求发送给该副本。重复的失败会导致没有碎片副本可用。在某些情况下,比如搜索,ElasticSearch会更倾向于快速响应,返回成功的分片数据给客户端 ,并在响应包中指明哪些分片节点发生了错误。

4、Elasticsearch主备模型隐含含义

  • 在正常操作下,每个读取操作一次为每个相关的复制组执行一次。只有在失败条件下,同一个复制组的多个副本执行相同的搜索。

  • 由于数据首先是在主分片上进行索引后,然后才转发请求到副本,在转发之前数据已经在主分片上发生了变化,所以在并发读时,如果读请求被转发到主分片节点上,那该数据在它被确认之前(主分片再等待所有副本全部执行成功)就已经看到了变化。【有点类似于数据库的读未提交】。

  • 主备模型的容错能力为两个分片(1主分片,1副本)。

5、ElasticSearch 读写模型异常时可造成的影响

在失败的情况下,以下是可能的:

  • 1个分片节点可能减慢整个集群的索引性能

因为在每次操作期间(索引),主分片在本地成功执行索引动作后,会转发请求到期复制分片节点上,此时主分片需要等待所有同步副本节点的响应,单个慢分片可以减慢整个复制组的速度。当然,一个缓慢的分片也会减慢那些被路由到它的搜索。

  • 脏读

一个孤立的主服务器可以公开不被承认的写入。这是由于一个孤立的主节点只会意识到它在向副本发送请求或向主人发送请求时被隔离。在这一点上,操作已经被索引到主节点,并且可以通过并发读取读取。Elasticsearch可以通过在每秒钟(默认情况下)对master进行ping来减少这种风险,并且如果没有已知的主节点,则拒绝索引操作。

难道这样就够了吗?不,远远不够!

提前多熟悉阿里往年的面试题肯定是对面试有很大的帮助的,但是作为技术性职业,手里有实打实的技术才是你面对面试官最有用的利器,这是从内在散发出来的自信。

备战阿里时我花的最多的时间就是在学习技术上,占了我所有学习计划中的百分之70,这是一些我学习期间觉得还是很不错的一些学习笔记

我为什么要写这篇文章呢,其实我觉得学习是不能停下脚步的,在网络上和大家一起分享,一起讨论,不单单可以遇到更多一样的人,还可以扩大自己的眼界,学习到更多的技术,我还会在csdn、博客、掘金等网站上分享技术,这也是一种学习的方法。

今天就分享到这里了,谢谢大家的关注,以后会分享更多的干货给大家!

阿里一面就落马,恶补完这份“阿里面试宝典”后,上岸蚂蚁金服

阿里一面就落马,恶补完这份“阿里面试宝典”后,上岸蚂蚁金服

image.png

2382)]

[外链图片转存中…(img-Oax9YxyR-1718694842382)]

[外链图片转存中…(img-ELcYSxKi-1718694842383)]

  • 4
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值