1.elasticsearch架构体系中的gateway
是ES索引中的持久化存储方式。es默认是先把索引存放到内存中，当内存满了再持久化到硬盘。当这个ES集群关闭再重新启动时就会从gateway中读取数据。
分类：
LocalFileSystem（默认）、SharedFileSystem、Hadoop HDFS、Amazon S3
2.Elasticsearch搜索问题
①返回数据排名问题
如果数据分散在默认的5个分片上，ES会向5个分片同时发出请求，每个分片都返回10条数据，最终会返回总数据为：5*10=50条数据，远远大于用户请求
②返回数据排名问题
每个分片计算符合条件的前10条数据都是基于自己分片的数据进行打分计算的。计算分值（score）使用的词频和文档频率等信息都是基于自己分片的数据进行的，而ES进行整体排名是基于每个分片计算后的分值进行排序的(打分依据就不一致，最终对这些数据统一排名的时候就不准确了)
解决思路:
①返回数据数量问题
第一步：先从每个分片汇总查询的数据id，进行排名，取前10条数据
第二步：根据这10条数据id，到不同分片获取数据
②返回数据排名问题
将各个分片打分标准统一。
3.SearchType类型
①query and fetch
向索引的所有分片（shard）都发出查询请求，各分片返回的时候把元素文档（document）和计算后的排名信息一起返回。
优点：
这种搜索方式是最快的。因为相比后面的几种搜索方式，这种查询方法只需要去shard查询一次。
缺点：
各个shard返回的结果的数量之和可能是用户要求的size的n倍。
②query then fetch（es默认的搜索方式）
实现原理
第一步，先向所有的shard发出请求，各分片只返回文档id(注意，不包括文档document)和排名相关的信息(也就是文档对应的分值)，然后按照各分片返回的文档的分数进行重新排序和排名，取前size个文档。
第二步，根据文档id去相关的shard取document。这种方式返回的document数量与用户要求的大小是相等的。
优点：
返回的数据量是准确的。
缺点：
数据排名不准确且性能一般。
③DFS query and fetch
这种方式比第一种类型多了一个DFS步骤，它可以更精确控制搜索打分和排名。
实现原理
第一步：先对所有分片发送请求，把所有分片中的词频和文档频率等打分依据全部汇总到一块。
第二步：然后再执行后面的操作后续操作
优点：
数据排名准确。
缺点：
搜索性能一般，且返回的数据量不准确，可能返回(N*分片数量)的数据。
④DFS query then fetch
比第2种方式多了一个DFS步骤。
实现原理
第一步：先对所有分片发送请求，把所有分片中的词频和文档频率等打分依据全部汇总到一块。
第二步：然后再执行后面的操作后续操作
优点：
返回的数据量是准确的，数据排名也是准确的。
缺点：
性能最差【这个最差只是表示在这四种查询方式中性能最慢，也不至于不能忍受，如果对查询性能要求不是非常高，而对查询准确度要求比较高的时候可以考虑这个】。
4.curl命令PUT和POST的区别
PUT是幂等方法，而POST并不是。所以PUT用于更新操作、POST用于新增操作比较合适。
PUT，DELETE操作是幂等的。所谓幂等是指不管进行多少次操作，结果都一样。比如我用PUT修改一篇文章，然后在做同样的操作，每次操作后的结果并没有不同，DELETE也是一样。
POST操作不是幂等的，比如常见的POST重复加载问题：当我们多次发出同样的POST请求后，其结果是创建出了若干的资源。
还有一点需要注意的就是，创建操作可以使用POST，也可以使用PUT，区别在于POST是作用在一个集合资源之上的（/articles），而PUT操作是作用在一个具体资源之上的（/articles/123），比如说很多资源使用数据库自增主键作为标识信息，而创建的资源的标识信息到底是什么只能由服务端提供，这个时候就必须使用POST。