想想我们漏了什么
这篇文章已经是第四篇了，前面很多都只是讲了基础的使用，没有讲到内层的原理，所以这里就要补一下原理知识了。
回顾
先回顾一下我们前面学过了什么，再想想我们漏了什么。
第一篇我们认识了ElasticSearch，大概知道了ElasticSearch的作用--搜索，也了解了一些倒排索引和分词器的知识（需要补充），然后学习了如何搭建环境（需要补充一下关于基础的集群知识），然后讲了一些基础的ElasticSearch概念（重新讲述，加深了解）。
第二篇讲了索引和文档的CRUD，讲创建索引的时候，没有讲mapping，讲文档的时候没有讲文档的数据类型和元数据,这些都需要补充。
第三篇讲了文档的搜索，主要是语法方面的问题，但相关度分数是怎么计算出来的，我们并没有讲。
补回
所以下面将对前面漏了的基础知识进行补充：
- Json文档的数据格式？【我们之前只会弄一个简单的json，而不知道里面有什么区别】
- 集群的基础认识？【我们之前说了ElasticSearch是一个分布式的系统，但我们之前只讲了如何启动，如何使用kibana操作ElasticSearch，并没有讲ElasticSearch的集群式怎么建立的】
- 节点是怎么提供服务的？【我们之前只知道直接发请求，这个请求ElasticSearch是怎么处理的，我们并不知道】
- 索引的mapping？【之前创建索引的时候，没有说清楚mapping，mapping受文档的数据类型影响，mapping影响查询方式和分词方式】
- 相关度分数score是怎么算出来的？【我们知道score是相关度分数，但我们并不知道这个是怎么算出来的】
- 分词器的原理【第一篇讲了一点，现在加深】
集群的建立
我们说了，ElasticSearch是分布式的，但我们之前只说了如何启动ElasticSearch，然后使用Kibana操作ElasticSearch，并没有讲ElasticSearch的集群式如何建立的，所以下面将会讲一下集群的知识。但如何管理集群会单独做成一篇来讲。
集群发现机制
首先，每一个ElasticSearch服务端就是一个集群节点，当我们启动一个elasticsearch时，就相当于启动了一个集群节点。
那么，多个节点之间如何建立联系呢？当我们启动一个节点的时候，这个节点会自动创建一个集群，集群的名称默认为elasticsearch，当我们再次启动一个节点的时候，它首先会尝试寻找名称为elasticsearch的集群，然后加入其中，（所有的都是先尝试寻找，没有再自己创建）。【集群名称可以自行配置，下面讲】
当节点加入到集群中后，这个集群就算是建立起来了。
配置文件
上面讲了集群名称可以自行配置，下面讲一下怎么配置。
ElasticSearch的配置文件是config/elasticsearch.yml，里面有以下几个配置项：
【左边是配置项，右边是值，修改配置也就是修改右边的值】
- 集群名称：
cluster.name: my-application - 索引存储位置：
path.data: /path/to/data - 日志存储位置：
path.logs: /path/to/logs - 绑定的IP地址：
network.host: 192.168.0.1 - 绑定的http端口：
http.port: 9200 - 是否允许使用通配符来标识索引：
action.destructive_requires_name，true为禁止。
健康状态
当集群建立后，我们可以使用命令来查看集群状态：
GET /_cluster/health：以json方式显示集群状态
GET /_cat/health?v：行列式显示集群状态
返回结果解析：- epoch：时间戳
- timestamp：时间
- cluster：集群名
- status：状态
- 集群状态解析看下面。
- node.total：集群中的节点数
- node.data：集群中的数据节点数
- shards：集群中总的分片数量
- pri：主分片数量
- relo：副本分片数量
- init：初始化中的分片数？【不确定，英文是这样的：number of initializing nodes 】
- unassign：没有被分配的分片的数量
- pending_tasks：待处理的任务数
- max_task_wait_time：最大任务等待时间
- activeds_percent：active的分片数量
集群状态解析：
集群状态受当前的primary shared和replica shared的数量影响。
当每个索引的primary shared和replica shared都是active的时候，状态为green;【什么是active？shard是位于节点上的，一个shard被分配到了运行的节点上，那么此时就是active的，如果shard没有分配到节点上，那么就是inactive】
当每个索引的primary shared都是active的，但replica shared不完全是active的时候，状态为yellow;
当每个索引的primary shared不完全是active的时候，此时发生了数据丢失,状态为red。
为什么现在是yellow?
当我们第一次启动的时候，kibana会默认为我们创建一个名为kibana的索引，这个索引的primary shard和replica shard都为1，由于此时只有一个节点，所以会优先分配primary shard，而忽略replica shard(不要忘了基于备份的安全性的shard排斥考虑：主分片和副本分片不能位于同一个节点上)，所以此时就符合了“每个索引的primary shared都是active的，但replica shared不全是active的”，所以此时是yellow.
你可以尝试启动多一个elasticsearch节点来调整状态。【当然，我觉得你学到这里了，此时replica shard的数量可能已经变了，所以这里只启动多一个可能已经不够了，具体的下面“分片的管理”讲】
补充：
- 集群的知识还有很多，这里讲集群只是讲了个开头，对于深层的集群管理并没有涉及，将留到后面集群管理篇讲。
小节总结
上面讲了当启动了一个elasticsearch之后，这个节点先