微服务--数据聚合_多个微服务数据汇聚

黑马-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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

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节点监控分片、节点状态，将故障节点上的分片转移到正常节点，确保数据安全。