一文轻松图解搞懂Elasticsearch原理！-电子发烧友网

认识倒排索引
分布式架构原理
写入数据的工作原理
写数据底层原理
读取数据的工作原理
搜索工作原理
删除/更新数据底层原理

ES 的集群模式和 kafka 很像，kafka 又和 redis 的集群模式很像。总之就是相互借鉴！

不管你用没用过 ES，今天我们一起聊聊它。就当扩展大家的知识广度了！

认识倒排索引

「正排索引 VS 倒排索引：」

正排索引 VS 倒排索引

「倒排索引包括两个部分：」

单词词典（Term Dictionary）：记录所有文档的单词，记录单词到倒排列表的关联关系

❝

单词词典一般比较大，可以通过 B+ 树或哈希拉链法实现，以满足高性能的插入与查询

❞
倒排列表（Posting List）：记录了单词对应的文档结合，由倒排索引项（Posting）组成：
- 文档 ID
词频 TF：该单词在文档中出现的次数，用于相关性评分
位置（Position）：单词在文档中分词的位置。用于语句搜索（Phrase Query）
偏移（Offset）：记录单词的开始结束位置，实现高亮显示

倒排索引

「ElasticSearch 的倒排索引：」

ElasticSearch 的 JSON 文档中的每个字段，都有自己的倒排索引

可以针对某些字段不做索引
- 优点：节省存储空间
- 缺点：字段无法被搜索

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

视频教程：https://doc.iocoder.cn/video/

分布式架构原理

「分片 shard：一个索引可以拆分成多个 shard 分片。」

主分片 primary shard：每个分片都有一个主分片。
备份分片 replica shard：主分片写入数据后，会将数据同步给其他备份分片。

将 ES 集群部署在 3个机器上（esnode1、esnode2、esnode3）：

「创建个索引，分片为 3 个，副本数设置为 1：」

PUT/sku_index/_settings
{
"settings":{
"number_of_shards":3,
"number_of_replicas":1
}
}

响应：
{
"acknowledged":true
}

分布式架构原理

「ES 集群中有多个节点，会自动选举一个节点为 master 节点，如上图的 esnode2节点：」

主节点（master）：管理工作，维护索引元数据、负责切换主分片和备份分片身份等。
从节点（node）：数据存储。

「集群中某节点宕机：」

主节点宕机：会重新选举一个节点为主节点。
从节点宕机：由主节点，将宕机节点上的主分片身份转移到其他机器上的备份分片上。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud

视频教程：https://doc.iocoder.cn/video/

写入数据的工作原理

「写单个文档所需的步骤：」

客户端选择一个 Node 发送请求，那么这个 Node 就称为 「协调节点（Coorinating Node）」 。
Node 使用文档 ID 来确定文档属于分片 0，通过集群状态中的内容路由表信息获知分片0 的主分片在 Node1 上，因此将请求转发到 Node1 上。
Node1 上的主分片执行写操作。如果写入成功，则将请求并行转发到 Node3 的副分片上，等待返回结果。

当所有的副分片都报告成功，Node1 将向 Node （协调节点）报告成功。

写入数据的工作原理

「Tips：客户端收到成功响应时，意味着写操作已经在主分片和所有副分片都执行完成。」

写数据底层原理

「写操作可分为 3 个主要操作：」

写入新文档： 这时候搜索，是搜索不到。

将数据写入内存

将这操作写入 translog 文件中

refresh 操作： 默认每隔 1s ，将内存中的文档写入文件系统缓存（filesystem cache）构成一个 segment

❝

这时候搜索，可以搜索到数据。

❞

「1s 时间：ES 是近实时搜索，即数据写入 1s后可以搜索到。」

flush 操作： 默认每隔 30 分钟或者 translog 文件 512MB ，将文件系统缓存中的 segment 写入磁盘，并将 translog 删除。

「translog 文件：」 来记录两次 flush(fsync) 之间所有的操作，当机器从故障中恢复或者重启，可以根据此还原

translog 是文件，存在于内存中，如果掉电一样会丢失。
「默认每隔 5s 刷一次到磁盘中」

读取数据的工作原理

「读取文档所需的步骤：」

客户端选择一个 Node 发送请求，那么这个 Node 就称为 「协调节点（Coorinating Node）」 。
Node 使用文档 ID 来确定文档属于分片 0，通过集群状态中的内容路由表信息获知分片0 有 2 个副本数据（一主一副），会使用随机轮询算法选择出一个分片，这里将请求转发到 Node1
Node1 将文档返回给 Node，Node 将文档返回给客户端。

读取数据的工作原理

「在读取时，文档可能已经存在于主分片上，但还没有复制到副分片，这种情况下：」

读请求命中副分片时，可能会报告文档不存在。
读请求命中主分片时，可能成功返回文档。

搜索工作原理

「搜索数据过程：」

客户端选择一个 Node 发送请求，那么这个 Node 就称为 「协调节点（Coorinating Node）」 。
Node 协调节点将搜索请求转发到所有的分片（shard）：主分片或副分片，都可以。
「query 阶段」 ：每个分片 shard 将自己的搜索结果（文档 ID）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
「fetch 阶段」 ：由协调节点根据文档 ID 去各个节点上拉取实际的文档数据。

搜索工作原理

举个栗子： 有 3 个分片，查询返回前 10 个匹配度最高的文档

每个分片都查询出当前分片的 TOP 10 数据
「协调节点」 将 3 * 10 = 30 的结果再次排序，返回最终 TOP 10 的结果。

删除/更新数据底层原理

「删除操作」 ：commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。
「更新操作」 ：就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。

「底层逻辑是：」

Index Buffer 每次 refresh 操作，就会产生一个 segment file。（默认情况：1秒1次）
定制执行 merge 操作：将多个 segment file 合并成一个，同时将标识为 deleted 的 doc 「物理删除」 ，将新的 segment file 写入磁盘，最后打上 commit point 标识所有新的 segment file。