ES集群的状态有哪些，为什么主分片数目是固定的，副本分片却能动态调节，快看看这些关于ES的问题你都知道吗?

1. ES集群的状态 green 最健康的状态，说明所有的分片包括备份都可用

yellow 基本的分片可用，但是备份不可用(或者是没有备份)

red 部分的分片可用，表明分片有一部分损坏。此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好

2. ES主分片数目为什么索引创建的时候就要确定？主分片数目如何确定

ES根据数据ID路由到分片方式为: shard = hash % primary_shard_num 。因此主分片的数目必须在索引创建之前确定好。

由于新加入节点，ES会自动对节点进行负载均衡，因此，主分片的数目主理想的数目是每个节点上一个主分片，数目与节点个数一样。

3. 新节点加入，节点故障会发生什么

新节点加入， Elasticsearch 将自动在可用节点间进行分片均衡，集群中的节点之间互相拷贝分片数据。原节点把迁移到其他节点分片的数据进行删除。

节点故障(主节点)，状态为red

集群选举出新的主节点

将对应丢失的主分片的副本分片提升为主分片(yellow)

等待delayed_timeout (默认1min)，如果故障节点还没回复，则在当前健康节点重建副本节点(green)

4. 主，副分片不同

每个分片都能独立执行数据搜索。ES集群中，每个节点都能处理任意请求。每个节点都知道任意文档的位置。

分片分为主分片与副本分片。主分片数目在索引创建的时候就确定好了，这个数目定义了这个索引能够 存储 的最大数据量。

读操作——搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。副本分片数目可以动态调节

5. 数据插入的过程 shard_num = hash(\routing) % num_primary_shards,计算出文档要分配到的分片，在从集群元数据中找出对应主分片的位置

请求接着会发送给Primary Shard，在Primary Shard上执行成功后

从Primary Shard上将请求同时发送给多个Replica Shard，请求在多个Replica Shard上执行成功并返回给Primary Shard后，写入请求执行成功

返回结果给客户端。

Elasticsearch为了减少磁盘IO保证读写性能，一般是每隔一段时间(比如5分钟)才会把Lucene的Segment写入磁盘持久化。为了保证写入Lucene内存的数据不丢失，引入Translog

在每一个Shard中，写入流程分为两部分，先写入Lucene，再写入TransLog。写入请求到达Shard后，先写Lucene文件，创建好索引，此时索引还在内存里面，接着去写TransLog，写完TransLog后，刷新TransLog数据到磁盘上，写磁盘成功后，请求返回给用户。

关于TranseLog两个点: 先写内存，最后才写TransLog，

每隔一段比较长的时间，比如30分钟后，Lucene会把内存中生成的新Segment刷新到磁盘上，刷新后索引文件已经持久化了，历史的TransLog就没用了，会清空掉旧的TransLog。 Elasticsearch内核解析 - 写入篇

6. 数据查询流程 协调节点将检索请求广播到每个分片上

每个分片本地执行检索请求，构建检索匹配的优先队列(返回数据ID)

协调节点整合全局搜索结果集数据ID

协调节点通过数据ID，提交多个获取数据的请求

每个节点将数据返回给协调节点，协调节点返回给客户端