本文主要内容如下：
搜索引擎现在是用得越来越多了，比如我们日志系统中用到的 ELK 就用到了搜索引擎 Elasticsearch（简称 ES）。
那对于搜索这种技术来说，最看重的是搜索的结果的准确性和搜索的响应时间。ES 的准确性可以通过 倒排索引算法来保证，那响应时间就需要磁盘或缓存来支持了，那么磁盘和缓存会带来哪些坑呢？ ( 其实不论是分布式的，还是单机模式下的搜索引擎都会遇到这个问题。 )
(资料图片仅供参考)
一、ES 慢查询之坑
Elasticsearch 是现如今用的最广泛的搜索引擎。它是一个分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据。
1.1 工作原理：
ES 的工作原理：往 ES 里写数据时，实际是写到磁盘文件，查询时，操作系统会将磁盘文件里的数据自动缓存 filesystem cache里面。如果给 filesystem cache更多的内存，尽量让内存可以容纳所有的 idx segment file索引数据文件，则搜索的时候走内存，性能较好。
坑：首先如果访问磁盘那一定很慢，而走缓存会快很多。但如果很多没用的字段数据都丢到缓存里面，则会浪费缓存的空间，所以很多数据还是存在磁盘里面的，那么大部分查询走的数据库，则会带来性能问题。
1.2 案例
ES 节点 3 台机器，每台机器 32 G 内存，总内存 96 G，给 ES JVM 堆内存是 16 G，那么剩下来给 cache 的是 16 G，总共 ES 集群的的 cache 占用内存 48 G ，如果所有的数据占据磁盘空间 600 G，那么每台机器的数据量是 200 G，而查询时，有 150 G 左右的的数据是走磁盘查询的，那么走 cache 的概率是 48 G/ 600 G = 8%，也就是说大量查询是走磁盘的。
1.3 避坑指南：
1.3.1 存储关键信息
1.3.2 数据预热
将访问量高的数据或者即将访问量高的数据放到 filesystem cache 里面。每隔一段时间就从数据库访问下数据，然后同步到 filesystem cache 里面。1.3.3 冷热分离
不常访问的数据和经常访问的数据进行隔离。比如 3 台机器存放冷数据的索引，另外 3 台存放热数据的索引。1.3.4 避免使用关联查询
ES 中的关联查询是比较慢的，性能不佳，尽量避免使用。二、ES 架构之坑
通常情况下，我们会使用 ES 的集群模式，在集群规模不大的情况下，性能还算可以，但如果集群规模变得很大，则会遇到集群瓶颈，也就是说集群扩大，性能提升甚微，甚至不增反降。
ES 的集群也是采用中心化的分布式架构，整个集群只有一个是 Master 节点。而它的职责非常重要：负责整个集群的元数据管理，元数据包含全局的配置信息、索引信息、节点信息，如果元数据发生改变，则需要 master 节点将变更信息发布到集群的其他节点。
另外因为 master 节点的任务处理是单线程的，所以每次处理任务时，需要等待全部节点接收到变更信息，并处理完变更的任务后，才算完成了变更任务。
那么这样的架构会带来什么问题：
响应时间问题。如果元数据发生了改变，但某节点假死，比如 JVM 的内存爆了，但是进程还活着，那么响应 master 节点的时间会非常长，今而影响单个同步信息任务的完成时间。任务恢复问题。有大量恢复任务的时候，任务需要排队，恢复时间变长。任务回调问题。任务执行完成后，需要回调大量 listener 处理元数据变更。如果分片的数据很大，则处理时间会到 10 秒级，严重影响了集群的恢复能力。解决方案：采用 ES 的 tribe node 特性实现 ES 多集群。文中后面会介绍下 tribe node 的原理。
三、业务场景的坑
ES 的被广泛应用到多个场景，比如查询日志、查询商品资料、数据聚合等。而这些场景的需求又有非常大的差异，这也是一个坑。
场景一：前端首页搜索功能。比如搜索商品，数据实时写入的频率不高，但是读的频率很高。解决方案：按业务场景划分 ES 集群，同样采用 ES tribe node 功能。
四、ES Tribe Node 方案
ES tribe node 功能原理图如下所示：
标签： 文件存储
