02.elasticsearch_read_write模型基础

文章目录

1. Introduction（介绍）
2. Basic write model（基础的写模型）
- 1.主分片遵循以下基本流程 :
- 2. Failure handling（故障处理）
3. Basic read model（基础的读取模型）
- 1. 基本流程
- 2. Failure handling（故障处理）
- 3. A few simple implications（一些简单的含义）
- 4. Failures（故障）
- - 1. A single shard can slow down indexing（单个分片可以降低索引速度）
  - 2. Dirty reads（脏读）
4. The Tip of the Iceberg（部分建议）

1. Introduction（介绍）

在 Elasticsearch 中的每个索引都会被拆分成分片，并且每个分片都有多个副本。这些副本称为 replication group（副本组）并且在删除或者添加文档的时候必须同步到各个副本。如果我们做不到这点，从不同副本中读取的数据会不一致。我们把保持分片和副本之间的同步以及从中读取的过程就是我们所说的 data replication model（数据复制模型）。

Elasticsearch 的 data replication model（数据复制模型）是基于primary-backup model （主备模型）的，并且在Microsoft Research 的 PacificA paper 中描述得非常好。该模型以来自 replication group（副本组，实际是主分片）的单个副本为基础。其它副本叫做 replica shards（副本分片）。主分片是所有索引操作的入口。它负责验证索引操作是否有效。一旦主分片接受一个索引操作，主分片的副本分片也会接受该操作。

本节的目的是给出 Elasticsearch replication model 的高级概述(非细节的)，并讨论它对写操作和读操作之间的各种交互的影响。

2. Basic write model（基础的写模型）

每个索引操作首先会使用 routing 参数解析到 replication group（分片组，包含主分片和副本分片），通常基于文档 ID。一旦确定 replication group，就会内部地转发该操作到分片组的主分片中。主分片负责验证操作和转发它到其他副本分片。Elasticsearch 维护一个可以接收该操作的分片的副本列表。这个列表叫做 in-sync copies（同步中的副本）并由 master 节点维护。正如名字那样，保证这些分片都会处理所有的索引和删除操作，这些操作都会经过用户确认。主分片负责维护不变性（各个副本保持一致），因此必须复制这些操作到列表中的每个副本。

1.主分片遵循以下基本流程 :

验证操作，如果它的结构有错就拒绝该操作（例如，对 object 字段指定一个数字值）
在本地执行操作。即索引或删除相关文档。这也会验证字段的内容，如果不通过就拒绝操作（例如，字段串的长度超出 Lucene 的定义的长度）
转发该操作到当前 in-sync 副本组的所有副本分片。如果有多个副本分片，会并行转发。
一旦所有的副本分片成功执行该操作就会返回给主分片，主分片把请求的成功执行的信息返回给用户。

2. Failure handling（故障处理）

索引期间会发生很多错误 - 硬盘坏了，节点丢失和其他节点的连接，或者某些配置错误会导致不能在副本分片上执行某个操作，尽管该操作成功在主分片上执行。虽然这是罕见的，但是主分片必须汇报这些错误信息。

对于主分片自身错误的情况，它所在的节点会发送一个消息到 master 节点。这个索引操作会等待（默认最多一分钟）master 节点提升一个副本分片为主分片。这个操作会被转发给新的主分片处理。注意 master 同样会监控节点的健康，并且可能会主动降级主分片。这通常发生在主分片所在的节点和集群失去联系的时候。

一旦在主分片执行的操作成功，该主分片必须处理在副本分片上潜在发生的错误。错误发生的原因可能是，在副本分片上执行操作时发生的错误，也可能是因为网络阻塞，导致主分片无法转发操作到副本分片，或者副本分片无法返回结果给主分片。这些错误都会导致相同的结果 : in-sync replica set 中的一个分片丢失一个即将要确认的操作。为了避免出现不一致，主分片会发送一条消息到 master 节点，要求它把有问题的分片从 in-sync replica set 中移除。一旦 master 确认移除了该分片，主分片就会确认这次操作。注意 master 也会指导另一个节点建立一个新的分片副本，以便把系统恢复成健康状态。

在转发请求到副本分片时，主分片会使用副本分片来验证它是否仍是一个活跃的主分片。如果主分片因为网络原因（或很长的 GC）被隔离了，在它被降级之前它会继续处理传入的索引操作。来自陈旧的主分片的操作将会被副本分片拒绝。当主分片接收到来自拒绝其请求的响应时，因为它不再是主节点，所以它将会访问到主节点，并且将会知道它已被替换。然后将操作路由到新的主分片。

Note（注意）:

如果没有副本会发生什么？

这是一个有效的场景，由于索引配置或因为所有副本故障时会发生。这时候在没有任何外部验证的情况下处理该操作，可能会导致问题。另一方面，主分片不能使它的分片失效，但它会请求 master 使它们失效。这意味着，master 知道只有主分片才是一个可用的副本。因此我们确保 master 不会提升任何其他分片副本（过时）为主分片，并且索引到主分片上的任何操作都不会丢失。当然，由于在这一点上，我们只运行单个的数据副本，因此物理硬件问题可能会导致数据丢失。有关缓解这些问题的选项，请参阅 “等待活动分片” 一节。

3. Basic read model（基础的读取模型）

通过 id 查找是非常轻量级的，一个巨大的复杂的聚合查询请求需要消耗大量 cpu 资源。 primary-backup model 一个好处是保证所有的分片副本都是一致（正在执行的操作例外）。因此，单个 in-sync 副本也可以服务请求。

1. 基本流程

当一个读请求被节点接收，这个节点负责转发它到其他涉及相关分片的节点，并整理响应结果，发送给客户端。我们叫这个节点为这个请求的 coordinating node（协调节点）。基本流程如下 :

把读请求发送到相关分片。注意，因为大多数搜索都会发送到一个或多个索引，通常需要从多个分片读取，每个分片都保存这些数据的一部分。
从 shard replication group 选择一个相关分片的活跃副本。它可以是一个主分片或者副本分片。默认情况下，Elasticsearch 会简单地循环遍历这些分片。
发送一个分片级别的读请求到被选中的副本中。
合并结果和响应。注意针对通过 id 查找的 get 请求，会跳过这个步骤，因为只有一个相关的分片。

2. Failure handling（故障处理）

当分片不能响应一个读请求，协调节点会从 replication group 中选择另一个副本，并发送请求到该副本代替不可用的副本。没有可用的分片副本会导致重复的错误。某些情况下，Elasticsearch 更喜欢尽早响应，即使只有部分的结果，而不是等待问题解决（你可以在响应结果的 _shards 字段，检查本次结果是完整的还是部分的）
对于一些请求，responsehi尽快返回，同时给出失败的shard
Search
Multi Search
Bulk
Multi Get

3. A few simple implications（一些简单的含义）

每一个这样的基础流决定了 Elasticsearch 作为一个系统在读和写之间是如何表现的。此外，由于可以同时执行读写请求，所以这两个基本流彼此相互作用。这有一些固有的含义 :

Efficient reads（高效读取）

在正常操作下，每个相关复制组执行一次读取操作一次。只有在故障条件下，同一个分片的多个副本才能执行相同的搜索。

Read unacknowledged

由于主分片首先在本地进行索引，然后复制请求，所以并发读取可以在确认之前已经看到更改。

Two copies by default

该模型可以容错，同时只保留两个数据副本。这与 quorum-based 的系统相反，其中容错的最小副本为 3。

4. Failures（故障）

一下情况都有可能是发生故障的原因

1. A single shard can slow down indexing（单个分片可以降低索引速度）

因为在每次操作时该主分片会等待所有在 in-sycn（同步中的）副本集合中的副本。所以单个 slow shard（缓慢的副本）可以减慢整个副本组的速度。这是我们为上述读取效率付出的代价。当然，单个缓慢的分片也会减慢已经路由给它的 unlucky searches（不利的搜索）。

2. Dirty reads（脏读）

隔离的主分片可以暴露不被确认的写入。这是由于隔离的主要设备只有在向其副本发送请求或者向 master 发送请求时才会被隔离。在这一点上，操作已经被索引到主分片并且可以通过并发读取获得。Elasticsearch 通过每秒钟（默认情况下）ping master 来降低这种风险，如果没有 master，则拒绝索引操作。

4. The Tip of the Iceberg（部分建议）

本文档提供了 Elasticsearch如何处理数据的高级概述。当然，真实情况还要更复杂。考虑下主要的术语，集群状态发布和 master 选举等都起到了保持系统正常运行的作用。本文档不包括已知和重要的错误（已关闭和打开）。我们认识到 GitHub 很难跟上。为了帮助这些人，我们在我们的网站上维护一个专用的 resiliency page 。我们强烈建议您阅读。