1.简介
Elasticsearch中的每个索引都分为碎片 ，每个碎片可以有多个副本。这些副本称为复制组，在添加或删除文档时必须保持同步。
如果我们不这样做，将导致从一个副本中读取与从另一个副本中读取的数据截然不同的结果。
保持碎片副本同步并从中提供读取的过程就是我们所说的数据复制模型。
Elasticsearch的数据复制模型基于主备份模型，并在Pacific Research的论文中得到了很好的描述 。
该模型使用一个数据集作为主分片。其他数据集称为副本分片。主分片作为所有索引操作的主要入口点。它负责验证它们并确保它们是正确的。一旦主分片接受了索引操作，其负责将操作复制到其他副本。
本节的目的是对Elasticsearch复制模型进行高级概述，并讨论它对写入和读取操作之间的各种交互的影响。
2.基本的写模型
Elasticsearch中的每个索引操作首先使用路由解析到特定的复制组（分片），通常基于文档ID。
确定复制组后，操作将在内部转发到组的当前主分片。主分片负责验证操作并将其转发到其他副本。由于副本可以脱机，因此不需要将主分片复制到所有副本分片。
相反，Elasticsearch维护应该接收操作的副本分片列表。此列表称为同步副本并由主节点维护。顾名思义，这些是“好”分片副本的集合，保证已经处理了向用户确认的所有索引和删除操作。
主分片负责维护此不变量，因此必须将所有操作复制到此集合中的每个副本。
主分片遵循以下基本流程：
- 验证传入操作并在结构无效时拒绝它（例如：定义为数字字段，但是传过来的是一个对象类型）
- 在本地执行操作，即索引或删除相关文档。这也将验证字段的内容并在需要时拒绝（例如：关键字值太长，无法在Lucene中进行索引）。
- 将操作转发到当前同步副本集中的每个副本。如果有多个副本，则这是并行完成的。
- 一旦所有副本成功执行了操作并响应主服务器，主服务器就会确认成功完成对客户端的请求。
3.故障处理
在索引过程中可能会出现许多问题 - 磁盘可能会损坏，节点可能会相互断开连接，或者某些配置错误可能导致复制副本上的操作失败，尽管它在主服务器上成功。这些虽然很少见，但主分片必须处理它们。
在主分片本身发生故障的情况下，托管主分片的节点将向主节点(master)发送有关它的消息。
索引操作将等待（默认情况下最多1分钟），以便master将其中一个副本分片提升为新的主分片。然后，该操作将被转发到新的主分片处理。
请注意，主服务器还会监控节点的运行状况，并可能决定主动降级主服务器。通过网络问题发生时，通常会发生这种情况。
一旦在主分片上成功执行了操作，主服务器就必须处理在副本分片上执行它时潜在的故障。
这可能是由副本上的实际故障或由于网络问题导致操作无法到达副本（或阻止副本响应）引起的。
所有这些都具有相同的最终结果：作为同步副本集的一部分的副本错过了即将被确认的操作。为了避免违反不变量，主分片向master节点发送消息，请求从同步副本集中删除有问题的分片。
只有在master上确认要删除分片后，主分片才会应答此操作的结果。请注意，master还将指示另一个节点开始构建新的shard副本，以便将系统恢复到正常状态。
在将操作转发到副本时，主分片将使用副本来验证它仍然是有效主分片。如果主要由于网络分区（或长GC）而被隔离，则它可能会在意识到它已被降级之前继续处理传入的索引操作。来自过时主分片的操作将被副本分片拒绝。
当主分片收到来自副本的拒绝其请求响应时，因为它不再是主分片，那么它将联系master节点并将知道它已被替换。然后将操作路由到新主分片。
4.基本读模型
Elasticsearch中的读取可以是ID非常轻量级的查找，也可以是具有复杂聚合的大量搜索请求，这些聚合会占用很多的CPU能力。
主备份模型的一个优点是它使所有分片副本保持相同（除了正在进行的操作）。因此，单个同步副本足以提供读取请求。
当节点收到读取请求时，该节点负责将其转发到保存相关分片（根据路由）的节点，收集整理响应并响应客户端。我们将该节点称为该请求的协调节点。基本流程如下：
- 将读取请求解析为相关分片。请注意，由于大多数搜索将被发送到一个或多个索引，因此它们通常需要从多个分片中读取，每个分片代表数据的不同子集。
- 从分片复制组中选择每个相关分片的活动副本。这可以是主分片或副本分片。默认情况下，Elasticsearch将简单地在分片副本之间循环。
- 将分片级读取请求发送到所选副本。
- 收集整理结果并做出回应。请注意，在通过ID查找的情况下，只有一个分片是相关的，可以跳过此步骤。
5.故障处理
当分片无法响应读取请求时，协调节点将从同一复制组中选择另一个副本分片，并将分片级别搜索请求发送到该副本。
重复失败可能导致没有可用的分片副本。在某些情况下，例如_search，Elasticsearch更愿意快速响应，尽管有部分结果，而不是等待问题得到解决（部分结果显示在_shards响应的标题中）。
6.一些简单的含义
由于读取和写入请求可以同时执行，因此这两个基本流程彼此交互。这有一些固有的含义：
- 高效的读
- 在正常操作下，对每个相关复制组执行一次读取操作。只有在失败条件下，同一个分片的多个副本才会执行相同的搜索。
- 读未确认的
- 由于主分片先在本地索引然后复制请求，因此并发读取可能在确认之前（副本尚未完成）已经看到了更改。
- 默认情况下为两份
- 此模型可以容错，同时仅保留两个数据副本。这与基于法定数量的系统形成对比，其中容错的最小副本数为3。
7.失败
在失败的情况下，以下是可能的情况：
- 单个分片故障会减慢索引搜索速度
- 由于主分片在每个操作期间等待同步副本集中的所有副本，因此单个慢速分片可能会降低整个复制组的速度。这是我们为提高读效率付出的代价。当然，单个慢速分片也会减慢路由到它的搜索请求。
- 脏读
- 隔离的主分片可以暴露无法收到应答的写入入口。这是因为隔离的主分片只有在向其副本发送请求或向master node发送请求时才会意识到它是隔离的。
- 此时，操作已经索引到主分片中，并且可以通过并发读取来读取。Elasticsearch通过每秒ping一次master node（默认情况下）并在没有master应答的情况下拒绝索引操作来减轻这种风险。
8.冰山一角
本文档提供了Elasticsearch如何处理数据的高级概述。当然，还有很多事情要发生。term，集群状态和主选举等都可以在保持系统正常运行方面发挥作用。
为了帮助人们掌控这些，我们 在我们的网站上维护了一个专用的页面。我们强烈建议阅读它。