es 怎么解决查询慢的问题？

1、只存关键数据，其他数据存入hbase,查询的时候根据id 查询一批数据，然后根据id的范围去hbase中查询，效率会相当高。

2、因为es有一个file system cache ,第一次查询数据时，其实是去磁盘读，然后刷进缓存的，所以缓存要存热点数据，内存容量有限，，我们可以先预热一下，比如后台有一个刷到缓存的数据进程，，这样每次查询都会去缓存中查询。。

倒排索引？

字典表（内存中 hash表形式存储）

倒排列表 磁盘中以跳表的形式存储（链表+索引的形式）

es 写数据过程：

1、写数据过程

1. 客户端通过hash选择一个node发送请求，这个node被称做coordinating node（协调节点），

2. 协调节点对docmount进行路由，将请求转发给到对应的primary shard

3. primary shard 处理请求，将数据同步到所有的replica shard

4. 此时协调节点，发现primary shard 和所有的replica shard都处理完之后，就反馈给客户端。

2、写数据的底层原理

1. 在到达primary shard的时候 ，数据先写入内存buffer ， 此时，在buffer里的数据是不会被搜索到的同时生成一个translog日志文件 ， 将数据写入translog里

2. 如果内存buffer空间快man满了，就会将数据refresh到一个新的segment file文件中，而且es里每隔1s就会将buffer里的数据写入到一个新的segment file中，这个segment file就存储最最近1s中buffer写入的数据，如果buffer里面没有数据，就不会执行refresh操作，当建立segment file文件的时候，就同时建立好了倒排索引库。

3. 在buffer refresh到segment之前 ，会先进入到一个叫os cache中，只要被执行了refresh操作，就代表这个数据可以被搜索到了。数据被输入os cache中，buffer就会被清空了，所以为什么叫es是准实时的？NRT，near real-time，准实时。默认是每隔1秒refresh一次的，所以es是准实时的，因为写入的数据1秒之后才能被看到。还可以通过es的restful api或者java api，手动执行一次refresh操作，就是手动将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。

4. 就这样新的数据不断进入buffer和translog，不断将buffer数据写入一个又一个新的segment file中去，每次refresh完buffer清空，translog保留。随着这个过程推进，translog会变得越来越大。当translog达到一定长度的时候，就会触发commit操作。translog也是先进入os cache中，然后每隔5s持久化到translog到磁盘中，

5. commit操作，第一步，就是将buffer中现有数据refresh到os cache中去，清空buffer 每隔30分钟flush

6. es也有可能会数据丢失 ，有5s的数据停留在buffer、translog os cache, segment file os cache中，有5s的数据不在磁盘上，如果此时宕机，这5s的数据就会丢失，如果项目要求比较高，不能丢失数据，就可以设置参数，每次写入一条数据写入buffer，同时写入translog磁盘文件中，但这样做会使es的性能降低。

7. 如果是删除操作，commit操作的时候就会生成一个.del文件，将这个document标识为deleted状态，在搜索的搜索的时候就不会被搜索到了。

8. 如果是更新操作，就是将原来的document标识为deleted状态，然后新写入一条数据

9. buffer每次refresh一次，就会产生一个segment file，所以默认情况下是1秒钟一个segment file，segment file会越来越多，当躲到一定程度的时候，es就会自动触发merge(合并)造作，将所有segment file文件 merge成一个segment file，并同时物理删除掉标识为deleted的doc，

3、es读取过程

1. 客户端发送get请求到任意一个node节点，然后这个节点就称为协调节点，

2. 协调节点对document进行路由，将请求转发到对应的node，此时会使用随机轮询算法，在primary shard 和replica shard中随机选择一个，让读取请求负载均衡，

3. 接收请求的node返回document给协调节点，

4. 协调节点，返回document给到客户端

4、 搜索过程

1. 客户端发送请求到协调节点，

2. 协调节点将请求大宋到所有的shard对应的primary shard或replica shard ；

3. 每个shard将自己搜索到的结果返回给协调节点，返回的结果是dou.id或者自己自定义id，然后协调节点对数据进行合并排序操作，最终得到结果。

4. 最后协调节点根据id到个shard上拉取实际 的document数据，左后返回给客户端。

es 怎么保证高可用？

index -> type -> mapping -> document -> field

类比Mysql:

index：类比mysql里的一张表

type：类比Hibernate 中多个同类Class同时映射到一个表中的情境，type就是各个Class。index里可以有多个type。

mapping：类比Hibernate的映射。这个type的表结构的定义，定义了这个type中每个字段名称，字段是什么类型的，然后还有这个字段的各种配置

document：类比表中的一条条记录。

field: 类比一条记录的各个字段。

 

shard

一个索引，这个索引可以拆分成多个shard，每个shard存储部分数据。

这个shard的数据实际是有多个备份，就是说每个shard都有一个primary shard，负责写入数据，但是还有几个replica shard。

primary shard写入数据之后，会将数据同步到其他几个replica shard上去。

 

Master

es集群多个节点，会自动选举一个节点为master节点。

这个master节点其实就是干一些管理的工作的，比如维护索引元数据拉，负责切换primary shard和replica shard身份 之类的。

要是master节点宕机了，那么会重新选举一个节点为master节点。

 如果是非master节点宕机了，那么会由master节点，让那个宕机节点上的primary shard的身份转移到其他机器上的replica shard。

急着你要是修复了那个宕机机器，重启了之后，master节点会控制将缺失的replica shard分配过去，同步后续修改的数据之类的，让集群恢复正常