ES集群查询稳定性优化（一）

如果将 Elasticsearch（ES）作为线上C端服务的查询引擎，那么 search query 的响应时间则至关重要。因为毕竟面向C端用户，如果一个搜索请求 1 秒内（端到端）还未返回，那么用户将不可接受。

因此，C端服务对ES的性能稳定性做了许多工程上的优化，比如：

1. 强制将分片的段文件设置为1，也即每个分片只有一个段文件。
2. 禁用swap，这在ES官方文档也有提及：https://www.elastic.co/guide/en/elasticsearch/reference/current/_memory_lock_check.html
   （这篇文章也提到了mlock）
3. ES 节点启动时预热（预加载）

本文介绍，通过 memory lock 锁住“倒排索引”，避免搜索的核心数据结构被 swap 到磁盘上。
首先看背景：大神的文章：https://blog.mikemccandless.com/2010/07/lucenes-ram-usage-for-searching.html 讲了 lucene 在检索时，若“索引文件”被 swap 到磁盘上，则会存在严重的查询性能问题。
而我们可通过 linux 的 mlock 命令，（参考：https://man7.org/linux/man-pages/man2/mlock.2.html ）将“倒排索引”文件 Lock 在内存，保障这些核心数据结构不被 swap out。
那 lock 哪些文件呢？主要有3类：

1. .tim 文件。这是：词典/字典/Term：存储所有的Term的地方，另外在.tim文件中还存储了该term在.doc、.pos、.pay文件中的偏移量，我们可以快速定位到term关联的doc链表、Pos位置、Payload相关信息。

2. .tip文件。字典索引/Term索引：为了加速查找Term在.tim中的位置，需要对字典做索引，Lucene使用FST作为Term的前缀索引，这个存储在.tip文件中。

3. 倒排链：倒排链存放在.doc文件中，是一系列的有序doc的集合，另外为了快速做查找和遍历 .doc中还存储了跳表，方便快速定位到doc。

因此，在 ES索引构建成功后，通过 快照 将索引恢复(snapshot restore)到内存后，就可以将这3类文件通过：linux mlock 命令 lock 住，进一步保障在线C端查询服务依赖的ES 查询性能更稳定。

具体实现是：基于 ES 插件机制，开发一个 rest 处理插件，该插件接收 mlock 命令，然后通过 JNA 方式调用 libc 函数库，从而执行 mlock命令，将此 ES节点 的倒排索引文件 lock 住。

此外，该插件也可以 implements org.elasticsearch.index.shard.IndexEventListener 的 afterIndexShardClosed方法，当 shard 关闭的时候，就可以 unlock 文件。

原文链接：https://www.cnblogs.com/hapjin/p/17678086.html

参考：ES集群查询稳定性优化（二）