一、系统架构

        一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者 从集群中移除节点时，集群将会重新平均分布所有的数据。 

        当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、 删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操 作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节 点都可以成为主节点。

        作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道 任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论 我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将 最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

 二、单节点集群

如上图，集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在 node-1 。 

当前集群是正常运行的，但是在硬件故障时有丢失数据的风险。

 一、故障转移

        当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。

        当你在同一台机器上启动了第二个节点 时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。 但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播 主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上 运行的节点才会自动组成集群。

 这里只是说任何一个节点出问题，数据都完好无损。但是如果是这两个节点所在的同一个机器出了问题，数据将会丢失。原因就是这两个节点是在同一台服务器上。

 二、水平扩容

 当启动了第三个节点，我们的集群（一台服务器上）将 会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配。

 

动态调整副本数目： 

主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够 存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。）但是，读操作—— 搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片 时，也将拥有越高的吞吐量。

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把 副本数从默认的 1 增加到 2 。

put http://loacalhost:9200/users/_settings

{

         "number_of_replicas" : 2

}

users 索引现在拥有 9 个分片：3 个主分片和 6 个副本分片。 这意味着我们可以将集群 扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍。

        当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每 个分片从节点上获得的资源会变少。 你需要增加更多的硬件资源来提升吞吐量。 但是更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去 2 个节点 的情况下不丢失任何数据。 

三、应对故障

        当一个主节点挂掉了，而集群必须拥有一个主节点来保证正常工作，所以发生 的第一件事情就是选举一个新的主节点。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。由于在其它节点上存在着这两个主分片的完整副本，所以新的主节点将会从其他节点上选举出来。此时集群的状态将会为 yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

        而这个时候，虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应 2 份副本分片，而此 时只存在一份副本分片。 所以集群不能为 green 的状态。但这，并不影响我们的程序运行。

        当挂掉的主节点从新恢复后，集群的状 态也将恢复成之前的状态，但是master将不会是刚开始的那个节点了，而是选举出来的节点。

三、路由计算 

        当索引一个文档的时候，文档会被存储到一个主分片中。Elasticsearch 如何知道一个 文档应该存放到哪个分片中呢？（或者说当我们创建文档时，它如何决定这个文档应当被存储在那个分片中呢？）

而这就涉及到一个公式了。

routing： 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。

routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数。

        这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求 的文档所在分片的位置。

        这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变 这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

注意：所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一 个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定 义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被 存储到同一个分片中。 

四、分片控制 

        假设有一个集群由三个节点组成。 它五包含一个叫 emps 的索引，有两个主分片， 每个主分片有两个副本分片。相同分片的副本不会放在同一节点。

        我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知 道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将 所有的请求发送到 Node 1，我们将其称为 协调节点(coordinating node) 。 

注意：当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。

一、写流程

新建、索引和删除 请求都是 写 操作， 必须在主分片上面完成之后才能被复制到相关 的副本分片。

新建，索引和删除文档所需要的步骤顺序： 亮的是主分片，暗的是副本

1. 客户端向 Node 1 发送新建、索引或者删除请求。

2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的 主分片目前被分配在 Node 3 上。

3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调 节点向客户端报告成功。

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。

而在上述过程中，有一些参数可以影响到这个过程：

consistency：

        即一致性。在默认设置下，即使仅仅是在试图执行一个_写_操作之 前，主分片都会要求 必须要有 规定数量(quorum)（或者换种说法，也即必须要 有大多数）的分片副本处于活跃可用状态，才会去执行_写_操作(其中分片副本 可以是主分片或者副本分片)。这是为了避免在发生网络分区故障（network partition）的时候进行_写_操作，进而导致数据不一致。_规定数量_即： int( (primary + number_of_replicas) / 2 ) + 1 consistency 参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_操 作）,all（必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_ 操作。 注意，规定数量 的计算公式中 number_of_replicas 指的是在索引设置中的设定 副本分片数，而不是指当前处理活动状态的副本分片数。如果你的索引设置中指

定了当前索引拥有三个副本分片，那规定数量的计算结果即： int( (primary + 3 replicas) / 2 ) + 1 = 3 如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数 量，也因此您将无法索引和删除任何文档。

timeout： 

如果没有足够的副本分片会发生什么？ Elasticsearch 会等待，希望更多的分片出 现。默认情况下，它最多等待 1 分钟。 如果你需要，你可以使用 timeout 参数 使它更早终止： 100 100 毫秒，30s 是 30 秒。

新索引默认有 1 个副本分片，这意味着为满足规定数量应该需要两个活动的分片副本。 但是，这些 默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题，要求只有当 number_of_replicas 大 于 1 的时候，规定数量才会执行。

二、读流程 

我们可以从主分片或者从其它任意副本分片检索文档。

从主分片或者副本分片检索文档的步骤顺序： 

1. 客户端向 Node 1 发送获取请求。

2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个 节点上。 在这种情况下，它将请求转发到 Node 2 。

3. Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。

在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均 衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分 片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一 旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

三、更新流程 

部分更新一个文档结合了先前说明的读取和写入流程：

部分更新一个文档的步骤如下： 

1. 客户端向 Node 1 发送更新请求。

2. 它将请求转发到主分片所在的 Node 3 。

3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片 的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次 后放弃。

4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的 副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回 成功，协调节点向客户端返回成功。

        当主分片把更改转发到副本分片时， 它不会转发更新请求。 相反，它转发完整文档的新版本。这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。 如果 Elasticsearch 仅 转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档。

四、多文档操作流程 

        mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于 哪个分片中。它将整个多文档请求分解成 每个分片 的多文档请求，并且将这些请求并行转 发到每个参与节点。 协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返 回给客户端。

用单个 mget 请求取回多个文档所需的步骤顺序: 

1. 客户端向 Node 1 发送 mget 请求。

2. Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的 主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客 户端。 

bulk API， 允许在单个批量请求中执行多个创建、索引、删除和更新请求。

 bulk API 按如下步骤顺序执行：

1. 客户端向 Node 1 发送 bulk 请求。

2. Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节 点主机。

3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或 删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功， 该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。

五、文档搜索 

倒排索引的不可变性：这点主要是因为 Elasticsearch 的底层是基于 Lucene，而在 Lucene 中提出了按段搜索的概念，将一个索引文件拆分为多个子文件，则每个子文件叫作段，每个段都是一个独立的可被搜索的数据集，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修改。

段 的概念提出主要是因为：在早期全文检索中为整个文档集合建立了一个很大的倒排索引，并将其写入磁盘中。如果索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大时效率很低，并且由于创建一次索引的成本很高，所以对数据的更新不能过于频繁，也就不能保证时效性。

而且在底层采用了分段的存储模式，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能。有点类似于ConcurrentHashMap 的分段锁 的概念

不变性有重要的价值：

1、不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。

2、一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够 的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。 

3、其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为 数据不会变化。

4、写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

六、动态更新索引 

        当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如 果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的 数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。

       如何在保留不变性的前提下实现倒排索引的更新？

       通过增加新的补充索引来反映新近的修改，而不是直接重写整 个倒排索引。每一个倒排索引都会被轮流查询到，从最早的开始查询完后再对结果进行合并。

每一个段本身都是一个倒排索引，但索引在 Lucene 中除表示所有段的集合外，还增加了提交点的概念。
为了提升写的性能，Lucene并没有每新增一条数据就增加一个段，而是采用延迟写的策略，每当有新增的数据时，就将其先写入内存中，然后批量写入磁盘中。若有一个段被写到硬盘，就会生成一个提交点，提交点就是一个列出了所有已知段和记录所有提交后的段信息的文件。

 按段搜索会以如下流程执行：

1、 新文档被收集到内存索引缓存

2、新的数据被写入缓存，然后Lucene采用了延迟写入的策略，超过 1 秒（默认）时就会触发一次 Refresh， 然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。然后批量写入（flush）磁盘（一个新的包含新段名字的 提交点 被写入磁盘。Flush：主要目的是把文件缓存系统中的段持久化到硬盘）

3、新的段被开启，让它包含的文档可见，以被搜索

4、内存缓存被清空，等待接收新的文档

        当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以 保证每个词和每个文档的关联都被准确计算。 这种方式可以用相对较低的成本将新文档添 加到索引。

        段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档 的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档 的段信息。 当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的，文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：

        当一个文档被更新时，旧版本文档被标记删除，文档的新版 本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个 旧版本文档在结果集返回前就已经被移除。

 七、近实时搜索

        随着按段（per-segment）搜索的发展，一个新的文档从索引到可被搜索的延迟显著降低 了。新文档在几分钟之内即可被检索，但这样还是不够快。磁盘在这里成为了瓶颈。提交 （Commiting）一个新的段到磁盘需要一个 fsync （同步）来确保段被物理性地写入磁盘，这样在断 电的时候就不会丢失数据。 但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一 次的话会造成很大的性能问题。

        我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中 被移除。在 Elasticsearch 和磁盘之间是文件系统缓存。 像之前描述的一样， 在内存索引缓 冲区中的文档会被写入到一个新的段中。 但是这里新段会被先写入到文件系统缓存—这一 步代价会比较低，稍后再被刷新到磁盘—这一步代价比较高。不过只要文件已经在缓存中， 就可以像其它文件一样被打开和读取了。

        Lucene 允许新段被写入和打开，使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分 片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是 近 实时搜索: 文档的变化 并不是立即对搜索可见，但会在一秒之内变为可见。 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。

        这些行为可能会对新用户造成困惑: 他们索引了一个文档然后尝试搜索它，但却没有搜到。 这个问题的解决办法是用 refresh API 执行一次手动刷新: /users/_refresh

        尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候， 手动刷新很有用，但是不要 在生产环境下每次索引一个文档都去手动刷新。 相反，你的应用需要意识到 Elasticsearch 的近实时的性 质，并接受它的不足。

        并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件， 你可能想优化索引速度而不是近实时搜索， 可以通过设置 refresh_interval ， 降低每个索 引的刷新频率 

{

        "settings": {

                 "refresh_interval": "30s"

                }

}

refresh_interval 可以在既存索引上进行动态更新。

在生产环境中，当你正在建立一个大的 新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来

# 关闭自动刷新

PUT /users/_settings { "refresh_interval": -1 }

# 每一秒刷新

PUT /users/_settings { "refresh_interval": "1s" }

八、持久化变更 

1、原因：

        如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断 电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变 化被持久化到磁盘。在 动态更新索引，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提 交点来判断哪些段隶属于当前分片。

        即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确 保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数 据。

2、解决方式： 

Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行 操作时均进行了日志记录。

整个流程如下：

1. 一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog

2. 刷新（refresh）使分片每秒被刷新（refresh）一次：

a、这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。

b、 这个段被打开，使其可被搜索

c、内存缓冲区被清空 

 3. 这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志

4. 每隔一段时间，例如 translog 变得越来越大，索引被刷新（flush）；一个新的 translog 被创建，并且一个全量提交被执行。

a、所有在内存缓冲区的文档都被写入一个新的段（段是在操作系统的文件缓存中）。

b、缓冲区被清空。

c、一个提交点被写入硬盘。

d、文件系统缓存通过 fsync 被刷新（flush）。

e、老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时 候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最 后一次提交后发生的变更操作。（这里防止了es突然挂了，而提交点里面的数据还未持久化到磁盘导致数据丢失的情况）

执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush。分片每 30 分钟被自动刷新（flush），或者在 translog 太大的时候也会刷新。通常情况下，自动刷新就足够了。在 重启节点或关闭索引之前执行 flush 有益于你的索引。当 Elasticsearch 尝试恢复或重新打 开一个索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢复快。        

九、段合并 （段合并是在磁盘中发生，会大量消耗IO）

        由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段 数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要 的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。 Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大 的段再被合并到更大的段。

        段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的 旧版本）不会被拷贝到新的大段中。

启动段合并不需要你做任何事。进行索引和搜索时会自动进行。

1. 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。

2. 合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会 中断索引和搜索。

3. 一旦合并结束，老的段被删除

a、新的段被刷新（flush）到了磁盘。 写入一个包含新段且排除旧的和较小的段 的新提交点。 

b、新的段被打开用来搜索。

c、老的段被删除。

合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行。