当数据被写入分片时，它会定期发布到磁盘上的不可变的 Lucene 分段中用于查询。随着分段数量的增长，这些分段会定期合并为更大的分段。 此过程称为合并。 由于所有分段都是不可变的，这意味着所使用的磁盘空间通常会在索引期间波动，因为需要在删除替换分段之前创建新的合并分段。 合并可能非常耗费资源，特别是在磁盘I / O方面。

分片是 Elasticsearch 集群分发数据的单元。 Elasticsearch 在重新平衡数据时可以移动分片的速度，例如发生故障后，将取决于分片的大小和数量以及网络和磁盘性能。

注1：避免使用非常大的分片，因为这会对群集从故障中恢复的能力产生负面影响。 对分片的大小没有固定的限制，但是通常情况下很多场景限制在 50GB 的分片大小以内。

注2：当在ElasticSearch集群中配置好你的索引后, 你要明白在集群运行中你无法调整分片设置. 既便以后你发现需要调整分片数量, 你也只能新建创建并对数据进行重新索引(reindex)(虽然reindex会比较耗时, 但至少能保证你不会停机).
    主分片的配置与硬盘分区很类似, 在对一块空的硬盘空间进行分区时, 会要求用户先进行数据备份, 然后配置新的分区, 最后把数据写到新的分区上。

注3：尽可能使用基于时间的索引来管理数据保留期。 根据保留期将数据分组到索引中。 基于时间的索引还可以轻松地随时间改变主分片和副本的数量，因为可以更改下一个要生成的索引。

节点类型

1. 候选主节点（Master-eligible node）
  一个节点启动后，就会使用Zen Discovery机制去寻找集群中的其他节点，并与之建立连接。集群中会从候选主节点中选举出一个主节点，主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch中的主节点的工作量相对较轻，用户的请求可以发往任何一个节点，由该节点负责分发和返回结果，而不需要经过主节点转发。
  正常情况下，集群中的所有节点，应该对主节点的选择是一致的，即一个集群中只有一个选举出来的主节点。然而，在某些情况下，比如网络通信出现问题、主节点因为负载过大停止响应等等，就会导致重新选举主节点，此时可能会出现集群中有多个主节点的现象，即节点对集群状态的认知不一致，称之为脑裂现象。为了尽量避免此种情况的出现，可以通过discovery.zen.minimum_master_nodes来设置最少可工作的候选主节点个数，建议设置为(候选主节点数 / 2) + 1, 比如，当有三个候选主节点时，该配置项的值为(3/2)+1=2，也就是保证集群中有半数以上的候选主节点。
  候选主节点的设置方法是设置node.mater为true，默认情况下，node.mater和node.data的值都为true，即该节点既可以做候选主节点也可以做数据节点。由于数据节点承载了数据的操作，负载通常都很高，所以随着集群的扩大，建议将二者分离，设置专用的候选主节点。当我们设置node.data为false，就将节点设置为专用的候选主节点了。

node.master = true
node.data = false
2. 数据节点（Data node）
  数据节点负责数据的存储和相关具体操作，比如CRUD、搜索、聚合。所以，数据节点对机器配置要求比较高，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统CPU、Memory和IO的性能消耗都很大。通常随着集群的扩大，需要增加更多的数据节点来提高可用性。
  前面提到默认情况下节点既可以做候选主节点也可以做数据节点，但是数据节点的负载较重，所以需要考虑将二者分离开，设置专用的数据节点，避免因数据节点负载重导致主节点不响应。

node.master = false
node.data = true
3. 客户端节点（Client node）
  按照官方的介绍，客户端节点就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等等，也就是下面要说到的协调节点的角色。这样的工作，其实任何一个节点都可以完成，单独增加这样的节点更多是为了负载均衡。

node.master = false
node.data = false
4. 协调节点（Coordinating node）
  协调节点，是一种角色，而不是真实的Elasticsearch的节点，你没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点，都可以充当协调节点的角色。当一个节点A收到用户的查询请求后，会把查询子句分发到其它的节点，然后合并各个节点返回的查询结果，最后返回一个完整的数据集给用户。在这个过程中，节点A扮演的就是协调节点的角色。毫无疑问，协调节点会对CPU、Memory要求比较高。

工作原理

以几个场景介绍一下Elasticsearch的工作原理。

启动过程

当Elasticsearch的node启动时，默认使用广播寻找集群中的其他node，并与之建立连接，如果集群已经存在，其中一个节点角色特殊一些，叫coordinate node（协调者，也叫master节点），负责管理集群node的状态，有新的node加入时，会更新集群拓扑信息。如果当前集群不存在，那么启动的node就自己成为coordinate node。

应用程序与集群通信过程

虽然Elasticsearch设置了Coordinate Node用来管理集群，但这种设置对客户端（应用程序）来说是透明的，客户端可以请求任何一个它已知的node，如果该node是集群当前的Coordinate，那么它会将请求转发到相应的Node上进行处理，如果该node不是Coordinate，那么该node会先将请求转交给Coordinate Node，再由Coordinate进行转发，搓着各node返回的数据全部交由Coordinate Node进行汇总，最后返回给客户端。

集群内node有效性检测

正常工作时，Coordinate Node会定期与拓扑结构中的Node进行通信，检测实例是否正常工作，如果在指定的时间周期内，Node无响应，那么集群会认为该Node已经宕机。集群会重新进行均衡：

1. 重新分配宕机的Node，其他Node中有该Node的replica shard，选出一个replica shard，升级成为primary shard。
2. 重新安置新的shard。
3. 拓扑更新，分发给该Node的请求重新映射到目前正常的Node上。

分片与集群状态
  分片（Shard），是Elasticsearch中的最小存储单元。一个索引（Index）中的数据通常会分散存储在多个分片中，而这些分片可能在同一台机器，也可能分散在多台机器中。这样做的优势是有利于水平扩展，解决单台机器磁盘空间和性能有限的问题，试想一下如果有几十TB的数据都存储同一台机器，那么存储空间和访问时的性能消耗都是问题。

前面提到，中心节点(master)是从一组候选人(master-eligible)中选举出来的，那设置多少个候选人是合理的？原则是要保证任何时候系统只有一个确定的master节点。考虑到一致性，只有被半数以上候选节点都认可的节点才能成为master节点，否则就会出现多主的情况。只有1个候选节点显然不能保证高可用；有2个时，半数以上（n/2+1）的个数也是2，任何一个出现故障就无法继续工作了；有3个时，半数以上的值仍然是2，恰好可以保证master故障或网络故障时系统可以继续工作。因此，3个dedicated master-eligible节点是最小配置，也是目前业界标配。

通过API（ http://localhost:9200/_cluster/health?pretty ）可以查看集群的状态，通常集群的状态分为三种：

Red，表示有主分片没有分配，某些数据不可用。
Yellow，表示主分片都已分配，数据都可用，但是有复制分片没有分配。
Green，表示主分片和复制分片都已分配，一切正常。

 Elasticsearch以REST API形式对外提供服务，数据写入与查询都会发送HTTP(S)请求到服务端，由负载均衡将请求分发到集群中的某个节点上（任何非dedicated master-eligible节点）。如下图所示，节点1收到请求后，会根据相关的元信息将请求分发到shard所在的节点（2和3）上进行处理，处理完成后，节点2和3会将结果返回给节点1，由节点1合并整理后返回给客户端。这里的节点1扮演着协调者的角色，称为coordinate节点，任何节点在收到请求后就开始发挥协调者的角色，直到请求结束。在实际使用中，可以根据需要增加一些专用的coordinate节点，用于性能调优。

数据写入：

1）客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）
2）coordinating node，对document进行路由，将请求转发给对应的node（有primary shard）
3）实际的node上的primary shard处理请求，然后将数据同步到replica node
4）coordinating node，如果发现primary node和所有replica node都搞定之后，就返回响应结果给客户端。

Elasticsearch写数据的底层原理

1）先写入buffer，在buffer里的时候数据是搜索不到的；同时将数据写入translog日志文件。

2）如果buffer快满了，或者到一定时间，就会将buffer数据refresh到一个新的segment file中，但是此时数据不是直接进入segment file的磁盘文件的，而是先进入os cache的。这个过程就是refresh。

每隔1秒钟，es将buffer中的数据写入一个新的segment file，每秒钟会产生一个新的磁盘文件，segment file，这个segment file中就存储最近1秒内buffer中写入的数据。

但是如果buffer里面此时没有数据，那当然不会执行refresh操作咯，每秒创建换一个空的segment file，如果buffer里面有数据，默认1秒钟执行一次refresh操作，刷入一个新的segment file中。

操作系统里面，磁盘文件其实都有一个东西，叫做os cache，操作系统缓存，就是说数据写入磁盘文件之前，会先进入os cache，先进入操作系统级别的一个内存缓存中去。

只要buffer中的数据被refresh操作，刷入os cache中，就代表这个数据就可以被搜索到了。

为什么叫es是准实时的？NRT，near real-time，准实时。默认是每隔1秒refresh一次的，所以es是准实时的，因为写入的数据1秒之后才能被看到。

可以通过es的restful api或者java api，手动执行一次refresh操作，就是手动将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。

只要数据被输入os cache中，buffer就会被清空了，因为不需要保留buffer了，数据在translog里面已经持久化到磁盘去一份了。

数据读取

Elasticsearch读取数据的过程

1）客户端发送请求到任意一个node，成为coordinate node
2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡
3）接收请求的node返回document给coordinate node
4）coordinate node返回document给客户端

1.写入document时，每个document会自动分配一个全局唯一的id即doc id，同时也是根据doc id进行hash路由到对应的primary shard上。也可以手动指定doc id，比如用订单id，用户id。

2.读取document时，你可以通过doc id来查询，然后会根据doc id进行hash，判断出来当时把doc id分配到了哪个shard上面去，从那个shard去查询

Elasticsearch搜索数据过程

es最强大的是做全文检索

1）客户端发送请求到一个coordinate node
2）协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard也可以
3）query phase：每个shard将自己的搜索结果（其实就是一些doc id），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果
4）fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，最终返回给客户端

搜索的底层原理：倒排索引