ElasticSearch

一、es基本概述

es是基于lucene的开源分布式查询和分析的搜索引擎，可以通过简单的restful api轻松实现搜索功能，可以进行大规模的横向扩展，以支撑pb级的结构化和分结构化海量数据的处理。所谓的全文索引指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找

二、es适用场景

1、站内搜索，主要和solr竞争

2、文档数据库，和Mongo抢占市场，读写性能高于Mongo,同时也支持地理位置查询

3、监控：统计，日志类时间序的数据存储和分析，可视化

4、提供全文搜索并高亮显示关键字

三、es内置rest接口

/index/_search                               搜索指定索引下的数据

/_aliases                                        获取或操作索引的别名

/index/                                            查看指定索引的详细信息

/index/type/                                    创建或操作类型

/index/_mapping                            创建或操作mapping

/index/_setting                               创建或操作设置(但分片一经创建无法更改)

/index/_open                                  打开被关闭的索引

/index/_close                                  关闭指定的索引

/index/refresh                                  刷新指定的索引，保证新增的索引可见，不保证数据持久化

/index/fresh                                     刷新索引触发提交

四、集群的状态

green:健康状态，指所有主副分片都正常分配

yellow:指所有主分片都正常分配，副本未正常分配

red：有主分片未分配 

1.  增加节点是否能够提高索引的数据容量?                                                                                                                                   如果说索引的分片数目和当前es的节点数量一样，则不能提高，因为3个分片分布到三个节点上，新增的节点显然无法利用，如果分片数目大于当前的节点数量，新增节点的话，会提高索引的数据容量
2.  增加副本的数目能否提高索引的读取吞吐量？                                                                                                                           不能，因为新增的副本还是分布在3个节点上，还是利用了同样的资源，如果要增加吞吐量，那么就需要增加新的节点

      注意：分片数的设定非常重要，需要提前就要规划好；分片数太少，导致后续无法通过增加节点实现水平扩容；分片数过大，导致一个节点上分布多个分片，造成资源浪费，同时也会影响查询性能

五、故障转移

node1所在的机器宕机导致服务器终止，此时就需要故障转移，从而达到可用的目的

1、node2,node3发现主节点node1无法响应一段时间后会发起master选举，选举node2为主节点，此时由于主分片p0下线，集群状态变为red

2、node2发现主分片P0未分配，将R0提升为主分片，此时由于所有主分片都正常分配，集群状态变为yellow

3、node2发现主分片P0和P1生成新的副本，集群状态变为green

六、脑裂问题 

一个正常的es集群中只有一个主节点 ，主节点负责管理整个集群，集群的所有节点都选择同一个节点作为主节点。脑裂问题的出现主要是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点，从而使得集群分裂。

可能导致脑裂的原因：

1. 网络：由于是内网通信，网络通信问题造成某些节点认为master死掉;当出现网络风暴，IO大面积阻塞、爬虫等现象的时候，
就会造成master宕机 
2. 节点负载：**由于master节点与data节点都是混合在一起的**，所以当工作节点的负载较大（确实也较大）时，导致对应的
ES实例停止响应，而这台服务器如果正充当着master节点的身份，那么一部分节点就会认为这个master节点失效了，故重新
选举新的节点，这时就出现了脑裂；同时由于data节点上ES进程占用的内存较大，较大规模的内存回收操作也能造成ES进程
失去响应。所以，这个原因的可能性应该是最大的。

解决方案一：将master节点和data节点分离

通过配置文件中,node.master：true;node.data：false这俩个配置，将该节点只是单纯的设置为master节点，不存储数据。业务上我们可以设置俩台机器单纯设置为master节点，实现可用性，master选举只在这俩台机器上选举，对数据不会影响，从而不会产生脑裂问题，再设置多台机器为data节点，将node.master：false;node.data：true

解决方案二：修改相关参数

discovery.zen.ping_timeout：3 这个配置是当master接待你如果在3秒之内没有响应，那么其他节点就任务这个master节
点死掉，从而进行选举，所以可以把这个时间设置大一点，一定程度上减少误判
discovery.zen.minimum_master_nodes：3 共3个master节点，目的是达到(n/2)+1等于2的要求，这样挂掉一台master后，满足参数，其他俩个master节点都会认为当前master节点挂掉，开始重新选举