谷粒商城项目|es的应用场景及常见问题

es是什么

es多被用于搜索聚合分析引擎
是分布式的可以高性能查询的引擎

es应用场景

为什么不用MYSQL而用es
es将数据存在内存中且可以分布式的存储数据
商品上架
商品在es中的保存
1.在es中建立索引
spu sku
spu sku保存在一起防止分布查询
为了防止对象数组扁平化，商品属性字段类型设为nested类型。
es数组的扁平化处理：es存储对象数组时，它会将数组扁平化，也就是说将对象数组的每个属性抽取出来，作为一个数组。因此会出现查询紊乱的问题。

2.将商品数据发送给es进行保存
使用bulk对商品数据进行批量保存实现上架

商品检索DSL语句
1.全文匹配关键字
使用bool查询 布尔查询是一个或多个查询子句的组合
must：必须匹配每个子查询，类似“与”。一般搭配match匹配，查text类型。
使用match语句
不用term term不进行分词
2.通过分类进行检索
使用filter对分类进行匹配
3.复杂查询 排序（价格排序）、过滤（区间）
区间检索 使用range 排序使用sort
使用search对商品进行查询

es相关面试题

1. 倒排索引流程：
分词：将每一个文档的数据利用算法分词，得到一个个词条；
映射关系表：创建分词和文档id的映射关系表；
词条–>id–>文档：搜索词条时，根据映射关系表找到它对应的所有文档id，然后根据文档id正向索引查到文档。
2. 怎么保证MySQL和ES一致性
使用消息队列：
使用消息队列（如Kafka、RabbitMQ）作为数据更新的中间件。
当对MySQL进行写操作时，将相同的数据变更事件发送到消息队列。然后，使用一个消费者服务从队列读取这些事件并更新到ES。
3.ElasticSearch为什么是近实时不是实时？如何保证实时？
当数据添加到索引后并不能马上被查询到，等到索引刷新后才会被查询到。 refresh_interval 配置的刷新间隔。默认是1s。
解决办法：
修改刷新间隔
设置刷新策略为立即刷新
说说ES集群的节点和分片
一个集群里有多个节点，每个节点都是一个es实例， 每个节点保存了自己的分片和一个其他节点备份的分片。
集群（cluster）：一组拥有共同的 集群名 的 节点。
节点（node) ：集群中的一个 Elasticearch 实例
分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在每次读写数据时，会根据文档ID%分片数量，得出具体访问分片的序号。在集群环境下，一个索引的不同分片可以拆分到不同的节点中。
解决问题：数据量太大，单点存储量有限、高可用的问题。
主分片（Primary shard）：相对于副本分片的定义。主分片和副本分片会自动分配在各节点，
副本分片（Replica shard）：每个主分片可以有一个或者多个副本，数据和主分片一样。主分片副本数 <= 节点数 - 1 。例如3个节点，则主分片有3个，每个主分片最多有2个副本，副本数可以动态扩展。
集群职责划分：实际场景，每个节点要细化角色，当然只搭建备选主节点也是可以的，默认情况下，集群中的任何一个节点都同时具备上述四种角色。
候选主节点（master eligible）：管理集群状态，处理索引库增删请求。
数据节点（data）：对记录的增删改查。
接待节点（ingest）：数据存储前的预处理。
协作节点（coordinating）：将请求路由其他节点，合并处理结果并返回。这样用户访问任何一个节点都能请求路由到数据实际存储分片所在节点。
集群脑裂问题以及为什么会出现
脑裂：master故障，集群选举出新master后旧master又恢复了，导致集群出现了两个master。

脑裂原因：

网络延迟导致误判：集群间的网络延迟导致一些节点访问不到master, 认为master 挂掉了从而选举出新的master,并对master上的分片和副本标红，分配新的主分片
主节点负载过高导致误判：主节点的角色既为master又为data,访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点
主节点故障。
解决：
1.调大超时时间
2.将master与数据分离
6.什么是mapper
mapper包含字段名称、类型、是否创建索引等字段基本信息
7 全文检索
搜索时明确范围的搜索
检索是指检索相关性的内容
直接用like检索会扫描表 很慢
8.为什么不用B+树索引做全文检索
树的每一层查找都涉及磁盘IO比较慢

2.用%like% 不符合最左匹配原则 会失效