ElasticSearch核心概念

核心概念

• Cluster，服务节点集合，集群名称必须唯一，默认为”elasticsearch”。
• Node， 单服务节点，通过名称标识，默认为UUID，节点通过集群名加入集群中。
• Index，把一个或多个分片的分组在一起的逻辑空间，默认分为5个主分片和一个replica分片，全部小写。
• Type，索引的逻辑分区，在Index里可定义多个Type。
• Document，被索引的基本单元，JSON格式。
• Shards & Replicas 分片&副本，一个分片就是一个lucene实例，实际索引数据。
• Cluster Health: green, yellow, red, green表示集群所有功能都完正常的， yellow表示所有数据都是有效的，但是部分副本还没分配， red表示部分数据不是有效的。
• 提供REST API风格请求处理方式: REST请求URI和REST请求体。
• NRT Near Real Time， 索引文档到文档可被搜索到通常延时1s，故是准实时，时间可调节。（默认索引refresh时间，index.refresh_interval=1s）。

CURD

Term查询

term是代表完全匹配，也就是精确查询，搜索前不会再对搜索词进行分词，所以我们的搜索词必须是文档分词集合中的一个，如果搜索词不在文档分词中，即便搜索词是文档的子串也不行。

模式Mapping

类似于数据库中标表的定义。es已经不支持删除mapping了，可以添加新的字段，但是不能修改字段。如果要重建新的mapping，只能删除索引重新建立新的mapping。
ttl可以动态修改，但是已经索引的数据的ttl无法修改，只会对新索引的数据有效。

Zen Discovery发现机制

发现集群中其它节点；选举master。
master功能：维护整个集群的状态，通知其他节点；同时当有节点加入或离开集群时，负责重新分配shard。

对选主算法有个比较好的流程分析：http://www.easyice.cn/archives/164

选举算法 https://en.wikipedia.org/wiki/Leader_election

master的选举算法：
默认， 一个Node既可以是master节点，也可以是data节点。

只有具备成为master节点资格的候选节点才有可能成为master， 资格的配置通过node.master=true指定。

根据nodeId排序, 由小到达, 然后选择第一个node为master节点。

ping请求通过transport发出

es的默认发现机制zen，2.0以上的版本提供了unicast, 1.x的版本还提供了multicast。新版的multicast已经废弃了。很多服务，由于其安全性，如阿里云不支持多播，及时开启了多播，也只能找到本机上的节点。

ping和unicaset均使用transport通信模块来与其他节点通信。

手动指定transport.tcp.port时，需要配置unicast列表（只需集群中的一台节点配置即可，便可以相互发现，最好全部都配置，以免改服务器宕机）。

相互ping：
当master节点停止或者遇到问题之后集群节点会相互ping并且产生一个新的master节点，这种相互ping会阻止一个节点和master节点出现网络闪断后，就认为master停止的情况，因为它还可以从其他节点获取master节点是否是活跃的。

故障检测FD

es 跑了两个默认的感知线程，一个是master用来检测集群中的其他成员节点是否存活，另一个是其他成员节点检测master节点的存活（如果不存活，发起一个选举进程）。

集群状态更新

master节点是唯一能更新集群状态的节点，每次只处理一个状态的更新，之后再处理在队列中的下一个更新。它发布状态的更改给成员节点，成员节点收到通知，不会立刻更改状态，先回复消息给master节点，master会有一个等待超时（discovery.zen.publish_timeout ），等待至少discovery.zen.minimum_master_nodes个节点答复，否则拒绝更新状态。

无master阻塞：
当集群不能产生一个master的时候，discovery.zen.no_master_block 用来配置操作的策略，它有两个配置：
1. all (节点上的所有读写操作都被拒绝，这也包括了集群api状态的读写操作)
2. write(写操作会被拒绝，读操作能成功)

discovery.zen.no_master_block 配置的设置不影响节点基本的api,如节点信息和节点统计api。