一、核心概念二、环境依赖三、索引管理
1.创建索引和分片副本数目2.集群管理工具
2.1 chrome插件 elasticsearch-head
下载地址操作界面 四、水平扩容
1.当前集群2个节点2.增加节点进行水平扩容，可以提高索引的最大数据存储量3.增加副本数目进行水平扩容，可以提供搜索操作吞吐量 五、故障处理
1.故障演练2.恢复节点 六、读写原理
1.路由计算2.分片控制
2.1 协调节点2.2 写文档流程2.3 读文档流程2.4 更新文档流程 七、索引原理
1.全文索引2.lucene3.倒排索引
一、核心概念 二、环境依赖
环境案例
三、索引管理 1.创建索引和分片副本数目工具用postman创建索引logs:
put方式请求url:http://fileos2:9200/logs
body内容:
{
"settings":{
"number_of_shards":3, //分片数目
"number_of_replicas":1 //每个分片的副本数目
}
}
图示：
通过chrome插件(elasticsearch-head)简单管理集群
2.1 chrome插件 elasticsearch-head 下载地址下载链接
操作界面 四、水平扩容 1.当前集群2个节点分片和副本分布情况如下
新节点elasticsearch.yml配置文件中要配置已有节点到发现节点列表参数
discovery.seed_hosts: ["fileOS1:9300","fileOS2:9300","fileOS3:9300"]
启动新节点后，分片和副本会重新分布，以达到均匀部署，提供系统吞吐量
修改索引的副本数量
http://fileos2:9200/logs/_settings
{"number_of_replicas":2}
修改完后，分片和副本会重新分布：
关闭集群中一台节点后，该节点的分片和副本下线，其他节点分片和副本重新分布，集群仍然能提供服务
操作类似水平扩容，详细见四.2操作
恢复后状态:
es底层使用的是lucene这个全文索引引擎工具包，其数据结构包含索引和文档两部分，es通过lucene的API先将数据处理成文档进行保存，然后将文档内容进行分词，对分词建立索引，形成索引库。
1.路由计算文档存在哪个分片上，有一套路由规则，是通过哈希算法相关的公式实现的，默认的算法公式：
shard = hash(文档参数) % number_of_primary_shards
默认文档参数是文档的id，通过函数得到值，再与主分片个数number_of_primary_shards取模得到余数，这个数就是主分片的序号值，从而得到该文档要存储在哪个分片上。
这就是为什么创建索引时就要确定好主分片数目不能再修改，因为number_of_primary_shards一旦变化，文档的位置就要发生变化，之前路由的值就无效了,也就找不到文档了。
所有文档API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一
个叫做 routing 的路由参数，通过这个参数我们可以自定义文档到分片的映射。一个自定
义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被
存储到同一个分片中。
类似redis集群下的读写寻址，客户端请求es集群操作文档时，先随机连上集群内任意一个节点A，然后在该节点上会计算要操作的文档所属分片以及确定该分片所在节点B，然后将该请求转发到该目的地节点B进行实际的文档操作，该节点A被称之为协调节点。
es集群中任意节点都有所有文档的位置信息，所以任意节点都可以做协调节点。
- 客户端连接集群节点1，请求新增/删除文档,此时节点1成为协调节点通过文档id确定要操作的主分片，转发请求到主分片所在节点2节点2执行请求，主分片操作成功后，将请求并行转发给副本所在节点Node1、Node3副本执行成功后，将结果反馈给节点2，节点2将结果反馈给协调节点1此时主分片和副本均执行完操作，数据是安全的，协调节点1将结果反回给客户端
处理写请求时，默认要求超过一半数量的主副分片状态可用，才会允许执行写操作，可以配置一致性参数consistency值来改变这个规则,实现牺牲数据安全性而提高性能的效果:
quorum是默认值,表示大多数，达到 (primary+replicas) / 2 +1 值才允许操作；
one值代表只要主分片状态可用就可以执行写操作；
all值表示必须主分片和所有副本状态均可用，才允许执行写操作
- 客户端连接集群节点1，发送搜索请求，节点1成为协调节点query阶段：协调节点将请求转发给该索引的所有主分片和副本所在节点query阶段：该索引主副分片涉及的节点通过倒排索引搜索出所有结果的文档id，反馈给协调节点query阶段：协调节点对结果文档id列表进行合并排序fetch阶段：协调节点通过计算结果文档id，得出文档所在分片，请求该分片所在节点查询文档记录详情fetch阶段：文档分片所在节点将查询出的文档内容反馈给协调节点fetch阶段：协调节点包装文档结果，统一数据结果返回给客户端
- 客户端连接集群节点1，发送修改某文档的请求，节点1成为协调节点协调节点计算出文档所在主分片，将请求转发到该主分片所在节点2节点2处理更新请求，先查出该文档详情，修改_source中要修改的字段，得到新的文档内容，将旧的文档状态置为deleted，并新增新文档节点2不断执行更新操作，因为有可能其他进程也在执行更新操作，这时本次操作的进程会因为得不到锁而更新失败，失败后进行重试，如果重试超过配置的retry_on_conflict次数，就会放弃节点2执行更新成功，将新版本的文档并行转发给副本所在节点，在副本上重新建立文档，副本操作成功后反馈给节点2节点2将结果反馈给协调节点1，节点1返回结果给客户端
