一. Elasticsearch架构原理
1、Elasticsearch的节点类型
在Elasticsearch主要分成两类节点，一类是Master(主节点)，一类是DataNode(数据节点)，还有一种叫客户端节点。
在配置文件中体现为：
主节点选举资格：node.master：true
数据节点选举资格: node.data: true
默认两个配置都为true，代表都有被选举为主节点和数据节点的资格。
1.1 Master节点
在Elasticsearch启动时，会选举出来一个Master节点。当某个节点启动后，然后使用Zen Discovery机制找到集群中的其他节点，并建立连接。(ES启动时，也可以在elasticsearch.yml配置中指定当前节点是什么类型）
发现机制前提每个节点的集群名字要一样，这就是为什么集群名要一样。
Master节点主要负责：
- 管理索引（创建索引、删除索引）、分配分片：操作索引，决定哪些分片分配给相关的节点
- 维护元数据（就是mapping等信息）
- 管理集群节点状态
- 不负责数据写入和查询，比较轻量级
一个Elasticsearch集群中，只有一个Master节点。在生产环境中，内存可以相对小一点，但机器要稳定。（索引的操作）
1.2 DataNode节点
在Elasticsearch集群中，会有N个DataNode节点。DataNode节点主要负责：文档写入、文档检索，大部分Elasticsearch的压力都在DataNode节点上。所以在生产环境中，内存最好配置大一些（4个G）。（文档的操作）
1.3 客户端节点
当主节点和数据节点配置都设置为false的时候，代表该节点即没有选举主节点的资格，也没有选举数据节点的资格，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。
独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。
经验：
在生产架构中，至少要三台机器有可以竞选主节点的资格。在实际生产环境中，可能节点的功能会比较细化。可能会有几台指定为主节点，有另外几台专门作为数据节点。一般建议至少三台，都设为true或保持默认。
在一个生产集群中我们可以对这些节点的职责进行划分，建议集群中设置3台以上的节点作为master节点，这些节点只负责成为主节点，维护整个集群的状态。再根据数据量设置一批data节点，这些节点只负责存储数据，后期提供查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大，所以在集群中建议再设置一批client节点(node.master: false node.data: false)，这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。
二 、分片和副本机制
1 、分片（Shard）
Elasticsearch是一个分布式的搜索引擎，索引的数据也是分成若干部分，分布在不同的服务器节点中。分布在不同服务器节点中的索引数据，就是分片（Shard）。Elasticsearch会自动管理分片，如果发现分片分布不均衡，就会自动迁移。
一个索引（index）由多个shard（分片）组成，而分片是分布在不同的服务器上的
2、副本
为了对Elasticsearch的分片进行容错，假设某个节点不可用，会导致整个索引库都将不可用。所以，需要对分片进行副本容错。每一个分片都会有对应的副本。
在Elasticsearch中，默认（7.x版本）创建的索引为1个分片、每个分片有1个主分片和1个副本分片。但是都是可以设置的，如果指定了多个主分片，则写入数据的时候可能就写入其中一个分片中，然后同步备份到若干个副分片中。如果几个主分片分布于不同的节点，则同一个索引库的数据自然而然就分布在不同的节点中。
每个分片都会有一个Primary Shard（主分片）和若干个Replica Shard（副本分片），Primary Shard和Replica Shard不在同一个节点上。如下面的0、1、2，有一个主分片，两个副本分片。
（在创建索引库的时候可以通过settings来指定主分片分数量以及每个主分片有几个副分片）
（这里表示job_idx_shar这个索引库有三个主分片，每个主分片又会有两个副分片。粗的是主分片，细框是副分片）
如果node-1挂掉了，则0、1主分片就挂掉了，那就会在node-2和node-3中的两个0副分片中选一个作为0的主分片；两个1副分片中选一个作为1的主分片。这样还是会有一个套主分片和一套副分片，会比较安全。
3、指定分片、副本数量
#创建指定分片数量、副本数量的索引PUT /job_idx_shard_temp{ "mappings":{ "properties":{ "id":{"type":"long","store":true}, "area":{"type":"keyword","store":true}, "exp":{"type":"keyword","store":true}, "edu":{"type":"keyword","store":true}, "salary":{"type":"keyword","store":true}, "job_type":{"type":"keyword","store":true}, "cmp":{"type":"keyword","store":true}, "pv":{"type":"keyword","store":true}, "title":{"type":"text","store":true}, "jd":{"type":"text"} } }, # 如下配置会有9个分片，三个主分片六个副本分片 "settings":{ # 指定三个主分片 "number_of_shards":3, # 指定一个主分片会有两个副本分片 "number_of_replicas":2 }}#查看分片、主分片、副本分片GET/_cat/indices?v三、Elasticsearch重要工作流程
1、Elasticsearch文档写入原理
1）选择任意一个DataNode发送请求，例如：node2。此时，node2就成为一个coordinating node（协调节点）
2）计算得到文档要写入的分片，至于写入哪个分片中是由下面算法计算出来的，routing可以指定，默认是文档的id，算法的结果必定是在分片数量之间。
shard = hash(routing) % number_of_primary_shards3)coordinating node会进行路由，将请求转发给对应的primary shard所在的DataNode（假设primary shard在node1、replica shard在node2）
4)node1节点上的Primary Shard处理请求，写入数据到索引库中，并将数据同步到Replica shard
5)Primary Shard和Replica Shard都保存好了文档，返回client
2、Elasticsearch检索原理
1）client发起查询请求，某个DataNode接收到请求，该DataNode就会成为协调节点（Coordinating Node）。
2）协调节点（Coordinating Node）将查询请求广播到每一个数据节点，这些数据节点的分片会处理该查询请求。
3）每个分片进行数据查询，将符合条件的数据放在一个优先队列中，并将这些数据的文档ID、节点信息、分片信息返回给协调节点；协调节点将所有的结果进行汇总，并进行全局排序。（协调汇总，从这里也能看出数据节点压力大一些，要多分配一些内存）
4）协调节点向包含这些文档ID的分片发送get请求，对应的分片将文档数据返回给协调节点，最后协调节点将数据返回给客户端
由此可见，分片越多，查询的效率肯定会有一定影响的。
四、Elasticsearch准实时索引实现
1、写入实现
1）溢写到文件系统缓存
当数据写入到ES分片时，会首先写入到内存中，然后通过内存的buffer生成一个segment，并刷到文件系统缓存中，数据可以被检索（注意不是直接刷到磁盘）
ES中默认1秒，refresh一次
2）写translog保障容错
在写入到内存中的同时，也会记录translog日志，在refresh期间出现异常，会根据translog来进行数据恢复
等到文件系统缓存中的segment数据都刷到磁盘中，清空translog文件
3）flush到磁盘
ES默认每隔30分钟会将文件系统缓存的数据刷入到磁盘
4）segment合并
Segment太多时，ES定期会将多个segment合并成为大的segment，减少索引查询时IO开销，此阶段ES会真正的物理删除（之前执行过的delete的数据）
总结：
1、实时搜索与准实时搜索
实时搜索：刚刚加进去的数据就能被查询出来。
ES准实时：数据先被写入内存里面去，（内存中的数据能不能被读取呢？es底层基于lucence，lucence是不能够直读取内存中的数据的，只能读取磁盘，相对速度较慢）。写入到内存中后这个时候是不能被查询的，每隔一秒中会刷新到文件缓存系统中去（不是磁盘，属于高速缓冲区，在里面读数据是很快的），这里面查询速度是很快的，那就意味着每一秒中都会被查询到的，所以说是准实时的，然后每隔三十分钟刷新到磁盘中去。solr就不行，实时性差。
2、面试点：如果中间（内存刷文件缓存系统/文件缓存系统刷磁盘）宕机了怎么办？
translog，如果中间宕机了，会根据translog这个日志进行数据恢复。