二十四 Elasticsearch

1 Elasticsearch 的倒排索引

  传统的检索方式是通过文章，逐个遍历找到对应关键词的位置。 倒排索引，是通过分词策略，形成了词和文章的映射关系表，也称倒排表，这种词典 + 映射表即为倒排索引。

  其中词典中存储词元，倒排表中存储该词元在哪些文中出现的位置。 有了倒排索引，就能实现 O(1) 时间复杂度的效率检索文章了，极大的提高了检索效率。

  倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。Lucene 从 4+ 版本后开始大量使用的数据结构是 FST。FST 有两个优点： 1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间； 2）查询速度快。O(len(str)) 的查询时间复杂度。

2 字典树介绍

  Elasticsearch中的字典树（Trie Tree）或称为前缀树（Prefix Tree）是一种用于处理字符串数据的高效数据结构。特别是在其倒排索引的构建中，字典树发挥了重要作用。其核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有 3 个基本性质：

  ① 根节点不包含字符，除根节点外每一个节点都只包含一个字符。
  ② 从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。
  ③ 每个节点的所有子节点包含的字符都不相同。或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度。

  对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度 O(1)，实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树

3 Elasticsearch 索引文档过程

  索引文档指文档写入 ES，创建索引的过程。
  第一步：客户端向集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，请求的节点扮演协调节点的角色。）

  第二步：协调节点接受到请求后，默认使用文档 ID 参与计算（也支持通过routing），得到该文档属于哪个分片。随后请求会被转到另外的节点。复制

java">// 路由算法：根据文档 id 或路由计算目标的分片 id
shard = hash(document_id) % (num_of_primary_shards)

  第三步：当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔 1 秒）写入到 F ilesystem Cache，这个从 Momery Buffer 到 Filesystem Cache 的过程就叫做 refresh；

  第四步：当然在某些情况下，存在 Memery Buffer 和 Filesystem Cache 的数据可能会丢失，ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystem cache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；

  第五步：在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。

  第六步：flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512 M）时。

4 Elasticsearch 搜索的过程

  搜索拆解为“query then fetch” 两个阶段。

  query 阶段的目的：定位到位置，但不取。
  步骤拆解如下：
  ① 假设一个索引数据有 5 主+1 副本 共 10 分片，一次请求会命中（主或者副本分片中）的一个。
  ② 每个分片在本地进行查询，结果返回到本地有序的优先队列中。
  ③ 第②步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。

  fetch 阶段的目的：取数据。路由节点获取所有文档，返回给客户端

5 Elasticsearch 更新和删除文档的过程

  ① 删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更；

  ② 磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del 文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。

  ③ 在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del 文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉

6 Elasticsearch 写数据底层原理

  ① 先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入translog 日志文件。如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 refresh 到一个新的 segment file 中，但是此时数据不是直接进入 segment file 磁盘文件，而是先进入os cache。这个过程就是 refresh。每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file，每秒钟会写入一个新的 segment file，这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。

  ② 但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作，如果 buffer里面有数据，默认 1 秒钟执行一次 refresh 操作，刷入一个新的 segment file 中。操作系统里面，磁盘文件其实都有一个东西，叫做 os cache，即操作系统缓存，就是说数据写入磁盘文件之前，会先进入 os cache，先进入操作系统级别的一个内存缓存中去。只要 buffer 中的数据被 refresh 操作刷入 os cache 中，这个数据就可以被搜索到了。

  ③ 为什么叫 es 是准实时的？NRT，全称 near real-time。默认是每隔 1 秒 refresh 一次的，所以 es 是准实时的，因为写入的数据 1s 之后才能被看到。可以通过 es 的 restful api 或者 java api，手动执行一次 refresh 操作，就是手动将 buffer 中的数据刷入 os cache 中，让数据立马就可以被搜索到。只要数据被输入 os cache 中，buffer 就会被清空了，因为不需要保留 buffer 了，数据在 translog 里面已经持久化到磁盘去一份了。

  ④ 重复上面的步骤，新的数据不断进入 buffer 和 translog，不断将 buffer 数据写入一个又一个新的 segment file 中去，每次 refresh 完 buffer 清空，translog保留。随着这个过程的推进，translog 会变得越来越大。当 translog 达到一定长度的时
候，就会触发 commit 操作。

  ⑤ commit 操作发生的第一步，就是将 buffer 中现有的数据 refresh 到 os cache中去，清空 buffer。然后将一个 commit point 写入磁盘文件，里面标识者这个commit，point 对应的所有 segment file，同时强行将 os cache 中目前所有的数据都 fsync到磁盘文件中去。最后清空现有 translog 日志文件，重启一个 translog，此时commit 操作完成。

  ⑥ 这个 commit 操作叫做 flush。默认 30 分钟自动执行一次 flush，但如果 translog过大，也会触发 flush。flush 操作就对应着 commit 的全过程，我们可以通过 esapi，手动执行flush 操作，手动将 os cache 中数据 fsync 强刷到磁盘上去。

  ⑦ translog 日志文件的作用是什么？
  执行 commit 操作之前，数据要么是停留在 buffer 中，要么是停留在 os cache中，无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。
  所以需要将数据对应的操作写入一个专门的日志文件 translog 中，一旦此时机器宕机了，再次重启的时候，es 会自动读取 translog 日志文件中的数据，恢复到内存 buffer和 os cache 中去。

  ⑧ translog 其实也是先写入 os cache 的，默认每隔 5 秒刷一次到磁盘中去，所以默认情况下，可能有 5s 的数据会仅仅停留在 buffer 或者 translog 文件的 oscache 中，如果此时机器挂了，会丢失 5 秒钟的数据。但是这样性能比较好，最多丢 5 秒的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘，但是性能会差很多。

  ⑨ es 第一是准实时的，数据写入 1 秒后就可以搜索到：可能会丢失数据的。有5 秒的数据，停留在 buffer、translog os cache 、segment file os cache 中，而不在磁盘上，此时如果宕机，会导致 5 秒的数据丢失。

  ⑩ 总结：：数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入到 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 达到一定程度，或者默认每隔 30min，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。数据写入 segment file 之后，同时就建立好了倒排索引

7 Elasticsearch 如何实现 Master 选举

  Elasticsearch的Master选举机制是确保集群高可用性和稳定性的关键部分。以下是Elasticsearch实现Master选举的主要步骤和机制：

  启动和初始化：当Elasticsearch节点启动时，它会尝试发现集群中的其他节点。这通常通过配置文件中的discovery.seed_hosts设置来实现，该设置指定了一组用于启动发现过程的初始主机列表。节点会向这些主机发送ping请求，以检测哪些节点是活动的并确定集群的初始状态。

  节点发现和Ping过程：节点通过发送ping请求来发现集群中的其他成员。响应ping请求的节点将被视为集群的一部分，并参与到后续的选举过程中。这个过程有助于节点了解集群的拓扑结构和当前状态。

  选举算法：Elasticsearch使用基于Zen Discovery模块的自定义选举机制来确定哪个节点应该成为Master。具体来说，这个机制包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）两部分。

  对所有可以成为master的节点（即node.master: true的节点）根据nodeId字典排序。每次选举时，每个节点都会把自己所知道的节点排一次序，然后选出第一个（即排序后的第0位）节点，暂且认为它是master节点。

  如果对某个节点的投票数达到一定的值（通常是可以成为master的节点数n/2+1）并且该节点自己也选举自己，那么这个节点就会成为Master。否则，将重新进行选举直到满足上述条件。

  候选者列表：当有节点想要成为Master节点时，它会将自己添加到候选者列表中。这个列表包含了所有参与选举的节点。

  故障检测和恢复：如果某个节点在一段时间内没有发送心跳信号，那么它就会被认为已经死亡或失效。在这种情况下，剩余的节点会再次进行选举以选出新的Master节点。这确保了集群在节点故障时能够自动恢复并继续提供服务。

  总的来说，Elasticsearch的Master选举机制是通过Zen Discovery模块、自定义选举算法、节点发现和Ping过程以及故障检测和恢复机制来实现的。这个机制确保了集群的高可用性和稳定性，使得Elasticsearch能够在分布式环境中提供可靠的数据存储和搜索服务。

8 Elasticsearch 该如何调优

① 设计阶段调优
  （1）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；
  （2）使用别名进行索引管理；
  （3）每天凌晨定时对索引做 force_merge 操作，以释放空间；
  （4）采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink 操作，以缩减存储；
  （5）采取 curator 进行索引的生命周期管理；
  （6）仅针对需要分词的字段，合理的设置分词器；
  （7）Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。
② 写入调优
  （1）写入前副本数设置为 0；
  （2）写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
  （3）写入过程中：采取 bulk 批量写入；
  （4）写入后恢复副本数和刷新间隔；
  （5）尽量使用自动生成的 id。
③ 查询调优
  （1）禁用 wildcard；
  （2）禁用批量 terms（成百上千的场景）；
  （3）充分利用倒排索引机制，能 keyword 类型尽量 keyword；
  （4）数据量大时候，可以先基于时间敲定索引再检索；
  （5）设置合理的路由机制。
④ 其他调优 部署调优，业务调优等。