ES集群的状态有哪些，为什么主分片数目是固定的，副本分片却能动态调节，快看看这些关于ES的问题你都知道吗?
1. ES集群的状态
- green 最健康的状态，说明所有的分片包括备份都可用
- yellow 基本的分片可用，但是备份不可用（或者是没有备份）
- red 部分的分片可用，表明分片有一部分损坏。此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好
2. ES主分片数目为什么索引创建的时候就要确定？主分片数目如何确定
ES根据数据ID路由到分片方式为: shard = hash % primary_shard_num 。因此主分片的数目必须在索引创建之前确定好。 由于新加入节点，ES会自动对节点进行负载均衡，因此，主分片的数目主理想的数目是每个节点上一个主分片，数目与节点个数一样。
3. 新节点加入，节点故障会发生什么
新节点加入， Elasticsearch 将自动在可用节点间进行分片均衡，集群中的节点之间互相拷贝分片数据。原节点把迁移到其他节点分片的数据进行删除。
节点故障(主节点)，状态为read 集群选举出新的主节点 将对应丢失的主分片的副本分片提升为主分片（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，提交多个获取数据的请求
- 每个节点将数据返回给协调节点，协调节点返回给客户端
