官网 www.itilzj.com 文件格式资料: wenku.itilzj.com
ES 的软件产业商业模式和 kafka 很像，kafka 又和 redis 的软件产业商业模式很像。总而言之是互相先进经验！
无论你用喷过 ES，那时他们一同谈谈它。就当扩充他们的科学知识深度了！
重新认识征迁检索
「ministers检索 VS 征迁检索：」
ministers检索 VS 征迁检索
「征迁检索主要包括三个部份：」
单字字典（Term Dictionary）：历史记录大部份文档的单字，历史记录单字到征迁列表的关联关系
❝ 单字字典通常较为大，能透过 B+ 树 或 基元鞋底法同时实现，以满足用户高效能的填入与查阅 ❞
征迁列表（Posting List）：历史记录了单字相关联的文件格式紧密结合，由征迁检索项（Posting）共同组成：
文件格式ID
加减TF：该单字在文件格式中再次出现的单次，用作关联性打分
边线（Position）：单字在文件格式中分词的边线。用作语句搜索（Phrase Query）
偏移（Offset）：历史记录单字的开始结束边线，同时实现高亮显示
征迁检索
「ElasticSearch的征迁检索：」
ElasticSearch的JSON文件格式中的每个字段，都有自己的征迁检索
能针对某些字段不做检索
优点：节省存储空间
缺点：字段无法被搜索
分布式架构基本原理
「分片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）：数据存储。
「软件产业中某节点宕机：」
主节点宕机：会重新选举一个节点为 主节点。
从节点宕机：由 主节点，将宕机节点上的 主分片身份转移到其他机器上的 备份分片上。
写入数据的工作基本原理
「写单个文件格式所需的步骤：」
客户端选择一个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。
IT架构师/技术大咖的交流圈子,为您提供架构体系科学知识、技术文章、流行实践案例、解决方案等，行业大咖分享交流/同行经验分享互动,期待你的加入!扫码即可加入哦，随着材料不断增多社群会不定期涨价早加入更优惠
免责声明：
本公众号部份分享的资料来自网络收集和整理，大部份文字和图片版权归属于原作者大部份，且仅代表作者个人观点，与本公众号无关，文章仅供读者学习交流使用，并请自行核实相关内容，如文章内容涉及侵权，请联系后台管理员删除。
