1.2.3 Elasticsearch的工作流程
本节我们将探索一些关键的Elasticsearch特性，如启动、故障检测、数据索引和查询等。
1. 启动过程
当Elasticsearch节点启动时，它使用发现（discovery）模块来发现同一个集群中的其他节点（这里的关键是配置文件中的集群名称）并与它们连接。默认情况下，Elasticsearch节点会向网络中发送广播请求，以找到拥有相同集群名称的其他节点。读者可以通过下图的描述来了解相关的处理。
集群中有一个节点被选为主（master）节点。该节点负责集群的状态管理以及在集群拓扑变化时做出反应，分发索引分片至集群的相应节点上去。
请记住，从用户的角度来看，Elasticsearch中的管理节点并不比其他节点重要，这与其他的某些分布式系统不同（例如数据库）。在实践中，你不需要知道哪个节点是管理节点，所有操作可以发送至任意节点，Elasticsearch内部会自行处理这些不可思议的事情。如果有需要，任意节点可以并行发送子查询给其他节点，并合并搜索结果，然后返回给用户。所有这些操作并不需要经过管理节点处理（请记住，Elasticsearch是基于对等架构的）。
管理节点读取集群的状态信息，如果有必要，它会进行恢复（recovery）处理。在该阶段，管理节点会检查有哪些索引分片，并决定哪些分片将用作主分片。此后，整个集群进入黄色状态。
这意味着集群可以执行查询，但是系统的吞吐量以及各种可能的状况是未知的（这种状况可以简单理解为所有的主分片已经被分配了，但是副本没有被分配）。下面的事情就是寻找到冗余的分片用作副本。如果某个主分片的副本数过少，管理节点将决定基于某个主分片创建分片和副本。如果一切顺利，集群将进入绿色状态（这意味着所有主分片以及副本均已分配好）。
2. 故障检测
集群正常工作时，管理节点会监控所有可用节点，检查它们是否正在工作。如果任何节点在预定义的超时时间内不响应，则认为该节点已经断开，然后错误处理过程开始启动。这意味着可能要在集群–分片之间重新做平衡，选择新的主节点等。对每个丢失的主分片，一个新的主分片将会从原来的主分片的副本中选出来。新分片和副本的放置策略是可配置的，用户可以根据具体需求进行配置。更多的信息可以在第7章了解到。
为了描述故障检测(failure detection)是如何工作的，我们用一个只有3个节点的集群作为例子，将会有一个管理节点，两个数据节点。管理节点会发送ping请求至其他节点，然后等待响应。如果没有响应（实际上多少次ping请求无响应可以确认节点失败取决于配置），则该节点会被从集群中移除出去。相反地，所有节点也会向主节点发送ping请求来检查主节点是否在正常工作。节点之间的相互探测如下图所示。
3. 与Elasticsearch通信
前面已经讨论过Elasticsearch是如何构建的了，然而，对普通用户来说，最重要的部分是如何向Elasticsearch推送数据以及构建查询。为了提供这些功能，Elasticsearch对外公开了一个设计精巧的API。如果我们说，基本上每个Elasticsearch功能模块都有一个API，这将是令人鼓舞的。这个主API是基于REST的（REST细节请参考http://en.wikipedia.org/wiki/Representational_state_transfer），并且在实践中能轻松整合到任意支持HTTP协议的系统中去。
Elasticsearch假设数据由URL携带或者以JSON（JSON细节请参考(http://en.wikipedia.org/wiki/JSON）文档的形式由HTTP消息体携带。使用Java或者基于JVM语言的用户，应该了解一下Java API，它除了REST API提供的所有功能以外还有内置的集群发现功能。
值得一提的是，Elasticsearch在内部也使用Java API进行节点间通信。因此，Java API提供了所有可被REST API调用的功能。
（1）索引数据
Elasticsearch提供了多种索引数据的方式。最简单的方式是使用索引API，它允许用户发送一个文档至特定的索引。例如，使用curl工具（curl细节请参考http://curl.haxx.se/），可以使用如下命令创建一个文档:
第2种方式允许用户通过bulk API或UDP bulk API一次发送多个文档至集群。两者的区别在于网络连接方式，前者使用HTTP协议，后者使用UDP协议。后者速度快，但是不可靠。还有一种方式使用被叫作河流（river）的插件来发送数据。不过在这里我们不需要了解这种河流插件，因为它们将在Elasticsearch未来版本中被移除。
有一件事情需要记住，建索引操作只会发生在主分片上，而不是副本上。当一个索引请求被发送至一个节点上时，如果该节点没有对应的主分片或者只有副本，那么这个请求会被转发到拥有正确的主分片的节点。然后，该节点将会把索引请求群发给所有副本，等待它们的响应（这一点可以由用户控制），最后，当特定条件具备时（比如说达到规定数目的副本都完成了更新时）结束索引过程。
下图展示了我们刚刚探讨的索引处理过程。
（2）查询数据
查询API占据了Elasticsearch API的大部分。使用查询DSL（基于JSON的可用于构建复杂查询的语言），我们可以做下面这些事情：
- 使用各种查询类型，包括，简单的词项查询，短语查询，范围查询，布尔查询，模糊查询，区间查询，通配符查询，空间查询，以及具备人类可读的打分控制功能的函数查询，等等。
- 组合简单查询构建复杂查询。
- 文档过滤，在不影响评分的前提下抛弃那些不满足特定查询条件的文档。- 这一点可以提升性能。
- 查找与特定文档相似的文档。
- 查找特定短语的查询建议和拼写检查。
- 使用切面构建动态导航和计算各种统计量。
使用预搜索（prospective search）和查找与指定文档匹配的query集合。
谈到查询操作，读者应该了解一个很重要的事实：查询并不是一个简单的、单步骤的操作。一般来说，查询分为两个阶段：分散阶段（scatter phase）和合并阶段（gather phase）。在分散阶段将查询分发到包含相关文档的多个分片中去执行查询，而在合并阶段则从众多分片中收集返回结果，然后对它们进行合并、排序，进行后续处理，然后返回给客户端。该机制可以由下图描述。
Elasticsearch对外提供了6个系统参数，通过使用其中之一来定制分散/合并机制。在本书的姐妹版《Elasticsearch Server, Second Edition》（Packt出版社）中已经讨论过这个问题了。