2.1搜索引擎提炼2

（1）es的分布式架构原理能说一下么（es是如何实现分布式的啊）？

（2）es写入数据的工作原理是什么啊？es查询数据的工作原理是什么啊？ （1）es写数据过程 1）客户端发送请求到node，node成为coordinating node（协调节点） 2）coordinating node，对document进行路由，将请求转发给对应的node（有primary shard） 3）路由到的node上的primary shard处理请求，然后将数据同步到replica node 4）coordinating node，如果发现primary node和所有replica node都同步后，返回响应给客户端   （2）es读数据过程 1）客户端发送请求到任意一个node，成为coordinate node 2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用负载均衡round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡 3）接收请求的node返回document给coordinate node 4）coordinate node返回document给客户端   （3）es全文检索   1）客户端发送请求到个coordinate node 2）协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard 3）query phase：每个shard将搜索结果（doc id）返回给协调节点，协调节点进合并、排序、分页等操作，产出最终结果 4）fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，给客户端   es删除更新操作 10）删除操作，commit时候会生成.del文件，将某个doc标识为deleted状态，搜索时排除.del文件中的doc   11）更新操作，将原doc标识为deleted状态，新写入一条数据   12）buffer默认1秒refresh产生一个segment file，segment file文件增多，es会定期执行merge   13）merge，会合并多个segment file成一个，将标识为deleted的doc给物理删除掉，将新的segment file写入磁盘，写一个commit point，标识所有新的segment file，然后打开segment file供搜索使用，同时删除旧的segment file。     primary shard处理请求 1先写入buffer，默认每隔1秒数据refresh 到os cache的segment file中，数据就可以被而是搜索到。 所以es是准实时的 可手动refresh  2数据在写入buffer，同时写入oscache 的translog中，每隔5秒刷一次到磁盘translog文件中 （es默认值情况下会有5s数据的丢失 ，可设置但会导致写入性能下降数量级）。当translog达到一定长度，触发commit commit操作：1、写commit point；2、将os cache数据fsync强刷到磁盘上去；3、清空translog日志文件 默认每隔30分钟会自动执行一次commit，整个commit的过程，叫做flush操作，可手动执行。 其实es第一是准实时的，数据写入1秒后可以搜索到；可能会丢失数据的，你的数据有5秒的数据，停留在buffer、translog os cache、segment file os cache中，有5秒的数据不在磁盘上，此时如果宕机，会导致5秒的数据丢失。 当translog长度达到一定程度的时候，会触发flush操作，否则默认每隔30分钟也会定时flush，其主要过程： 4.1. 执行refresh操作将mem buffer中的数据写入到新的segment并写入os cache，然后打开本segment以供search使用，最后再次清空mem buffer。 4.2. 一个commit point被写入磁盘，这个commit point中标明所有的index segment。 4.3. filesystem cache（os cache）中缓存的所有的index segment文件被fsync强制刷到磁盘os disk，当index segment被fsync强制刷到磁盘上以后，就会被打开，供查询使用。 4.4. translog被清空和删除，创建一个新的translog。   es是准实时的，数据写入1秒后可以搜索到；可能会丢失数据的，默认有5秒的数据，停留在buffer、translog os cache、segment file os cache中，有5秒的数据不在磁盘上，此时如果宕机，会导致5秒的数据丢失。

（3）es在数据量很大的情况下（数十亿级别）如何提高查询性能啊？ Es 在海量数据下如何保证高性能 Es 在海量数据下如何性能优化 1 机器剩余的fielesystem cache 能够达到es存储数据量的一半以上 2 对热数据用预热系统定时访问预热 3 冷热数据分离 使用es 各用不同机组 4 模型设计字段尽量少，冗余字段而不是关联查询 5 es尽量少深翻页，用scroll快照游标顺序加载下一页 可用es+mysql / es+hbase 查全量数据   （1）性能优化的杀手锏——filesystem cache es搜索引擎依赖于底层的filesystem cache内存，让机器的filesystem cache内存容纳更多的indx segment file索引数据文件，搜索走内存的，性能会非常高。最好容纳总数据量的一半，甚至全部 性能差距大，走磁盘秒级的，走内存基本上就是毫秒级的，几毫秒到几百毫秒不等。 写入es的数据小于等于，es所在机器的filesystem cache的内存容量   es数据拆分，将大量不搜索的字段，拆分到别的存储中去，单条查询字段越少 缓存的条数就越多。 elastcisearch仅放用于搜索的几个关键字段；如es + hbase架构通过doc id等到hbase里，或mysq查找全量数据。   （2）数据预热 对于高访问的热数据，用缓存预热子系统，对热数据每隔1分钟，让系统自动提前访问一下，让数据进入filesystem cache里面去   （3）冷热分离 将数据冷热分离各写es索引，假设你有6台机器，2个索引，3台机器放热数据index；另外3台机器放冷数据index。 将热数据单独写一个索引尽量放在缓存中，其余80%的冷数据用另一个索引 。这样热数据访问就快了     （4）document模型设计 es里面的复杂的关联查询尽量别用 主表索引 和子表索引独立，  子表es模型中直接写入关联后的冗余主表字段的数据   （5）分页性能优化 es的分页是较坑的，你翻页的时候，翻的越深，每个shard返回的数据就越多，而且协调节点处理的时间越长。 生产问题，es分页，前几页就几十毫秒，翻到10页之后，就要5~10秒才能查出来一页数据了。 分页性能优化思路 1）不允许深度分页（风险回避） /  默认深度分页性能很惨（风险接受） 你系统不允许他翻那么深的页，，默认翻的越深，性能就越差 2）下拉加载翻页，可以用scroll api。 scroll会一次性给你生成所有数据的一个快照，然后每次翻页就是通过游标移动，获取下一页性能比es分页高很多 适合于下拉翻页，不能随意跳页。

（4）es生产集群的部署架构是什么？每个索引的数据量大概有多少？每个索引大概有多少个分片？ Eg生产经验 （1）es生产集群我们部署了5台机器，每台机器是6核64G的，集群总内存是320G   （2）我们es集群的日增量数据大概是2000万条，每天日增量数据大概是500MB，每月增量数据大概是6亿，15G。目前系统已经运行了几个月，现在es集群里数据总量大概是100G左右。   （3）目前线上有5个索引（这个结合你们自己业务来，看看自己有哪些数据可以放es的），每个索引的数据量大概是20G，所以这个数据量之内，我们每个索引分配的是8个shard，比默认的5个shard多了3个shard。