黑马-SpringCloud微服务技术栈数据聚合。
项目涉及技术
1.知识点是按照集数依次整理，方便日后回来查找。
2.考虑到不是固定的联网方式，时而WiFi，时而热点，配置静态IP会导致每次网络变更后都需要重新配置，所以虚拟机使用的动态路由，当需要运行相关程序时，IP变化，需要修改yml文件 || test测试类 || 启动类里的配置即可。
3.将代码路径列举主要是为后续审查。
4.RestClient操作酒店索引库的代码路径E:\微服务\实用篇\day05-Elasticsearch01\资料\hotel-demo。
5.操作数据库+mq实现数据同步的代码路径E:\微服务\实用篇\day07-Elasticsearch03\资料\hotel-admin。
实用篇
1.聚合–对文档数据的统计、分析、计算。（P120）
2.聚合的常见种类
3.Bucket（桶聚合）：对文档数据分组；TermAggregation：按照文档字段分组；Date Histogram：按日期阶梯分组，如一周或一月为一组。
4.Metric（度量聚合或嵌套聚合）：对文档数据做计算，例如avg、min、max、status（同时求sum、min等）等；
5.Pipeline（管道聚合）：基于其它聚合结果再做聚合。
6.参与聚合的字段类型必须为：keyword、数值、日期、布尔。
7.DSL实现Bucket聚合（P121）
8.aggs代表聚合，与query同级；query的作用：限定聚合的的文档范围。
9.聚合必须的三要素：聚合名称、聚合类型、聚合字段。
10.聚合可配置属性有：size：指定聚合结果数量；order：指定聚合结果排序方式；field：指定聚合字段。
11.DSL实现Metrics聚合（P122）
12.ResrClient实现聚合（P123）
# 统计所有数据中的酒店品牌有几种，此时可以根据酒店品牌的名称做聚合 # size-设置size为0，结果中不包含文档，只包含聚合结果 # aggs-定义聚合 brandAgg-给聚合起个名字 # terms-聚合的类型，按照品牌值聚合，所以选择 # field-参与聚合的字段 size- 希望获取的聚合结果数量 GET /hotel/_search { "size": 0, "aggs": { "brandAgg": { "terms": { "field":"brand", "size": 10 } } } } # Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序 GET /hotel/_search { "size": 0, "aggs": { "brandAgg": { "terms": { "field":"brand", "size": 10, "order": { "_count": "asc" } } } } } # Bucket聚合是对索引库的所有文档做聚合，我们可以限定要聚合的文档范围，只要添加query条件 GET /hotel/_search { "query": { "range": { "price": { "lte": 200 } } }, "size": 0, "aggs": { "brandAgg": { "terms": { "field":"brand", "size": 10 } } } } # 获取每个品牌的用户评分的min、max、avg等值. # aggs-brands聚合的子聚合，也就是分组后对每组分别计算 # scoreAgg-聚合名称 # stats-聚合类型，这里stats可以计算min、max、avg等 # field-聚合字段，这里是score GET /hotel/_search { "size": 0, "aggs": { "brandAgg": { "terms": { "field":"brand", "size": 10, "order": { "scoreAgg.avg": "desc" } }, "aggs": { "scoreAgg": { "stats": { "field": "score" } } } } } }
1.自动补全（P126）
2.安装拼音分词器，测试。
3.自定义分词器–elasticsearch中分词器（analyzer）的组成包含三部分：
4.character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符。
5.tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik_smart。
6.tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等。
# 安装pinyin分词器 # 查看数据卷elasticsearch的plugins目录位置 docker volume inspect es-plugins # 到这个目录下 cd /var/lib/docker/volumes/es-plugins/_data # 使用FileZillar直接传输Windows下解压的pinyin分词器的文件夹，结果是成功的 # 重启es容器 docker restart es # 查看es日志 docker logs -f es # 测试拼音分词器 GET /_analyze { "text": ["如家酒店还不错"], "analyzer": "pinyin" } # 删除索引库 DELETE /test # 自定义拼音分词器,创建索引库时，通过settings来配置自定义的analyzer（分词器）;拼音分词器适合在创建倒排索引的时候使用，但不能在搜索的时候使用。--导致多音字都被搜出来 # 创建倒排索引时应该用my_analyzer分词器 -- analyzer； # 字段在搜索时应该使用ik_smart分词器 -- search_analyzer; PUT /test { "settings": { "analysis": { "analyzer": { "my_analyzer": { "tokenizer": "ik_max_word", "filter": "py" } }, "filter": { "py": { "type": "pinyin", "keep_full_pinyin": false, "keep_joined_full_pinyin": true, "keep_original": true, "limit_first_letter_length": 16, "remove_duplicated_term": true, "none_chinese_pinyin_tokenize": false } } } }, "mappings":{ "properties":{ "name": { "type": "text", "analyzer": "my_analyzer", "search_analyzer": "ik_smart" } } } } # 测试自定义分词器 GET /test/_analyze { "text": ["如家酒店还不错"], "analyzer": "pinyin" }
- 1.自动补全–
completion suggester查询-实现自动补全功能。（P128） - 2.自动补全对字段的要求：类型是
completion类型；字段值是多词条的数组。 - 3.案例：酒店数据自动补全–实现hotel索引库的自动补全、拼音搜索功能。（P130）
# 自动补全的索引库 PUT test1 { "mappings":{ "properties":{ "title": { "type": "completion" } } } } # 示例数据 POST test1/_doc { "title":["Sony", "WH-1000XM3"] } POST test1/_doc { "title":["SK-II", "PITERA"] } POST test1/_doc { "title":["Nintendo", "switch"] } # 自动补全查询 POST /test1/_search { "suggest": { "title_suggest": { "text": "s", # 关键字 "completion": { "field": "title", # 补全字段 "skip_duplicates": true, # 跳过重复的 "size": 10 # 获取前10条结果 } } } }
1.数据同步–elasticsearch与mysql之间的数据同步（P132）
2.问题：微服务中，负责酒店管理（操作mysql ）的业务与负责酒店搜索（操作elasticsearch ）的业务可能在两个不同的微服务上，数据同步该如何实现呢？ 解决办法：
3.方式一：同步调用；优点：实现简单，粗暴；缺点：业务耦合度高。
4.方式二：异步通知；优点：低耦合，实现难度一般；缺点：依赖mq的可靠性。
5.方式三：监听binlog；优点：完全解除服务间耦合；缺点：开启binlog增加数据库负担、实现复杂度高。–使用canal中间件。
6.ES集群结构(P138)
7.单机的elasticsearch做数据存储，必然面临两个问题：
8.海量数据存储问题–将索引库从逻辑上拆分为N个分片（shard），存储到多个节点。
9.单点故障问题–将分片数据在不同节点备份（replica ）。
10.每个索引库的分片数量、副本数量都是在创建索引库时指定的，并且分片数量一旦设置以后无法修改。
11.elasticsearch中集群节点有不同的职责:
12.master eligi（主节点）–备选主节点：主节点可以管理和记录集群状态、决定分片在哪个节点、处理创建和删除索引库的请求。
13.data（数据节点）–数据节点：存储数据、搜索、聚合、CRUD。
14.ingest–数据存储之前的预处理。
15.coordinating（协调节点）–路由请求到其它节点合并其它节点处理的结果，返回给用户。
16.ES集群的脑裂–当主节点与其他节点网络故障时，可能发生脑裂问题。
17.协调节点的作用
18.分布式新增如何确定分片–coordinating node根据id做hash运算，得到结果对shard数量取余，余数就是对应的分片。
19.分布式查询的两个阶段。
20.分散阶段： coordinating node将查询请求分发给不同分片。
21.收集阶段：将查询结果汇总到coordinating node ，整理并返回给用户。
22.故障转移–master宕机后，EligibleMaster选举为新的主节点；master节点监控分片、节点状态，将故障节点上的分片转移到正常节点，确保数据安全。
