单节点集群
我们在包含一个空节点的集群内创建名为 users 的索引，为了演示目的，我们将分配 3个主分片和一份副本（每个主分片拥有一个副本分片）
{ "settings": { "number_of_shards": 3, "number_of_replicas": 1 } }
我们的集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在 node-1 。
通过 elasticsearch-head 插件查看集群情况
当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。
故障转移
当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
如果启动了第二个节点，我们的集群将会拥有两个节点的集群 : 所有主分片和副本分片都已被分配
通过 elasticsearch-head 插件查看集群情况
水平扩容
怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配
但是如果我们想要扩容超过 6 个节点怎么办呢？
主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。） 但是，读操作——搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。
在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2
{ "number_of_replicas" : 2 }
users索引现在拥有9个分片：3个主分片和6个副本分片。这意味着我们可以将集群扩容到9个节点，每个节点上一个分片。相比原来3个节点时，集群搜索性能可以提升3 倍。
应对故障
我们关闭第一个节点，这时集群的状态为:关闭了一个节点后的集群。
我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点：Node 2 。在我们关闭Node 1 的同时也失去了主分片1 和2 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为red ：不是所有主分片都在正常工作。
幸运的是，在其它节点上存在着这两个主分片的完整副本，所以新的主节点立即将这些分片在Node 2 和Node 3 上对应的副本分片提升为主分片，此时集群的状态将会为yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。
为什么我们集群状态是yellow 而不是green 呢？
虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。所以集群不能为green 的状态，不过我们不必过于担心：如果我们同样关闭了Node 2 ，我们的程序依然可以保持在不丢任何数据的情况下运行，因为Node 3 为每一个分片都保留着一份副本。
如果我们重新启动Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。如果Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是Master节点切换了。
路由计算
当索引一个文档的时候，文档会被存储到一个主分片中。Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片1 还是分片2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
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 将向协调节点报告成功，协调节点向客户端报告成功。
在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很少使用，因为Elasticsearch已经很快，但是为了完整起见，请参考下面参数：
consistency：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 构建响应并将其返回给客户端。
可以对docs 数组中每个文档设置routing 参数。 bulkAPI，允许在单个批量请求中执行多个创建、索引、删除和更新请求。
bulkAPI 按如下步骤顺序执行：
1、客户端向Node 1 发送bulk 请求。
2、Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。
3、主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。
分片原理
分片是Elasticsearch最小的工作单元。但是究竟什么是一个分片，它是如何工作的？
传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需要被搜索，对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值需求的数据结构是倒排索引。
Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索。
见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引（forward index），反向索引（inverted index）更熟悉的名字是倒排索引。
所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件ID，搜索时将这个ID和搜索关键字进行对应，形成K-V对，然后对关键字进行统计计数
但是互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回排名结果的要求。所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词。
一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。例如，假设我们有两个文档，每个文档的 content 域包含如下内容
The quick brown fox jumped over the lazy dog
Quick brown foxes leap over lazy dogs in summer
为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：
现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档：
两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单相似性算法，那么我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。
但是，我们目前的倒排索引有一些问题：
Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词
fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。
jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。
使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含quick fox ，第二个文档包含 Quick foxes 。
我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。
如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：
Quick 可以小写化为 quick 。
foxes 可以 词干提取 --变为词根的格式-- 为 fox 。类似的， dogs 可以为提取为 dog 。
jumped 和 leap 是同义词，可以索引为相同的单词 jump
现在索引看上去像这样：
这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询+quick +fox，这样两个文档都会匹配！分词和标准化的过程称为分析
这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。
文档搜索
早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。
倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。
不变性有重要的价值：
不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化
写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。
当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。
