SpringCloud全面学习笔记之初窥门径篇

刺骨的言语ヽ痛彻心扉 2023-09-29 21:23 1阅读 0赞

#### 目录 ####

*  前言
 *  Docker
 *   *  初见小鲸鱼
     *  Docker架构
     *  Docker的安装
     *  Docker基操
     *  Dockerfile自定义镜像
     *  Docker-Compose
     *  Docker镜像仓库
 *  异步通信
 *   *  初识MQ
     *   *  同步通讯
         *  异步通讯
         *  MQ常见框架
     *  RabbitMQ快速入门
     *   *  RabbitMQ概述和安装
         *  常见消息模型
         *  快速入门
     *  SpringAMQP
     *   *  Basic Queue 简单队列模型
         *  Work Queue 工作队列模型
         *  发布/订阅
         *  发布、订阅模型-Fanout
         *  发布、订阅模型-Direct
         *  发布、订阅模型-Topic
         *  消息转换器
 *  分布式搜索
 *   *  初识elasticsearch
     *   *  ES介绍
         *  倒排索引
         *  ES基本概念
         *  安装es、kibana
     *  索引库操作
     *   *  mapping映射属性
         *  索引库的CRUD
         *   *  创建索引库和映射
             *  查询和删除索引库
             *  修改索引库
     *  文档操作
     *   *  新增文档
         *  查询和删除文档
         *  修改文档
         *  小结
     *  RestAPI
     *   *  快速入门
         *  操作索引库
         *  操作文档
     *  elasticsearch搜索功能
     *   *  DSL查询文档
         *   *  DSL查询分类
             *  查询所有
             *  全文检索查询
             *  精准查询
             *  地理坐标查询
             *  复合查询
             *  布尔查询
         *  搜索结果处理
         *   *  排序
             *  分页
             *  高亮
             *  总结
         *  RestClient查询文档
         *   *  快速入门
             *  match查询
             *  精确查询
             *  布尔查询
             *  排序、分页
             *  高亮
     *  旅游项目案例
     *   *  酒店搜索和分页
         *  酒店结果过滤
         *  我周边的酒店
         *  酒店竞价排名
     *  数据聚合
     *   *  聚合的种类
         *  DSL实现聚合
         *  RestAPI实现聚合
     *  自动补全
     *  数据同步
     *   *  同步策略
         *  实现数据同步
         *   *  代码思路
             *  导入demo工程
             *  声明队列和交换机
             *  发送MQ消息
             *  接收MQ消息
     *  es集群搭建
     *   *  搭建ES集群
         *  集群脑裂问题
         *  集群分布式存储
         *  集群分布式查询
         *  集群故障转移

## 前言 ##

*本篇是记录黑马的SpringCloud学习过程中的笔记，该篇为实用篇的下篇，记录了Docker，MQ，ES等服务组件相关介绍原理和使用教程，最后感谢您的阅览，愿您终有所获*

--------------------

## Docker ##

Docker主要解决的**部署上**的问题与困难

--------------------

### 初见小鲸鱼 ###

***场景描述***

微服务虽然具备各种各样的优势，但服务的拆分通用给部署带来了很大的麻烦。

*  分布式系统中，依赖的组件非常多，不同组件之间部署时往往会产生一些冲突。
 *  在数百上千台服务中重复部署，环境不一定一致，会遇到各种问题

--------------------

由于大型项目组件较多，运行环境也较为复杂，部署时会碰到一些问题：

*  `依赖关系复杂，容易出现兼容性问题`
 *  `开发、测试、生产环境有差异`

其中依赖关系在繁琐服务组件下错综复杂，很容易就会发生冲突

例如一个项目中，部署时需要依赖于node.js、Redis、RabbitMQ、MySQL等，这些服务部署时所需要的函数库、依赖项各不相同，甚至会有冲突。给部署带来了极大的困难

--------------------

> Docker解决依赖兼容问题采取的方案

*  ①将应用的Libs（函数库）、Deps（依赖）、配置与应用一起打包
 *  ②将每个应用放到一个隔离**容器**去运行，避免互相干扰

![在这里插入图片描述][bec3f775feb5430dbe89735af5be3ac5.png]

打包好的应用包中，既包含应用本身，也保护应用所需要的Libs、Deps，无需再操作系统上安装这些，自然就不存在不同应用之间的兼容问题了。

虽然解决了不同应用的兼容问题，但是开发、测试等环境会存在差异，**操作系统版本也会有差异**

> *例如有的是用的Ubuntu，有的服务用的却是CentOS*

--------------------

*小鲸鱼的能耐才刚刚展示，这些问题自然不在话下*

> Docker解决操作系统环境差异

要解决不同操作系统环境差异问题，必须先了解**操作系统结构**。以一个Ubuntu操作系统为例

![在这里插入图片描述][b29ff82ab90342c7a4ecc774f2c64887.png]

结构包括：

*  计算机硬件：例如CPU、内存、磁盘等
 *  系统内核：所有Linux发行版的内核都是Linux，例如CentOS、Ubuntu、Fedora等。内核可以与计算机硬件交互，对外提供**内核指令**，用于操作计算机硬件。
 *  系统应用：操作系统本身提供的应用、函数库。这些函数库是对内核指令的封装，使用更加方便。

--------------------

**而应用与计算机交互的流程如下**：

1）应用调用操作系统应用（函数库），实现各种功能

2）系统**函数库**是对内核指令集的封装，会调用内核指令

3）内核指令操作计算机硬件

--------------------

Ubuntu和CentO都是基于Linux内核，**无非是系统应用不同，提供的函数库有差异**

如果将一个Ubuntu版本的MySQL应用安装到CentOS系统，MySQL在调用Ubuntu函数库时，会发现找不到或者不匹配，就会报错

解决方案如下

*  Docker将用户程序与**所需要调用的系统(比如Ubuntu)函数库一起打包**
 *  Docker运行到不同操作系统时，直接基于打包的函数库，借助于操作系统的Linux内核来运行

![在这里插入图片描述][db56dc40af2e4686b50cf808d75bb576.png]

--------------------

> 问题总结

Docker如何解决大型项目依赖关系复杂，不同组件依赖的兼容性问题？

*  Docker允许开发中将应用、依赖、函数库、配置一起**打包**，形成可移植镜像
 *  Docker应用运行在容器中，使用沙箱机制，相互**隔离**

--------------------

Docker如何解决开发、测试、生产环境有差异的问题？

*  Docker镜像中包含完整运行环境，包括系统函数库，仅依赖系统的Linux内核，因此可以在任意Linux操作系统上运行

--------------------

Docker是一个快速交付应用、运行应用的技术，具备下列优势：

*  可以将程序及其依赖、运行环境一起打包为一个镜像，可以迁移到任意Linux操作系统
 *  运行时利用沙箱机制形成隔离容器，各个应用互不干扰
 *  启动、移除都可以通过一行命令完成，方便快捷

--------------------

Docker和虚拟机的差异：

*  **Docker**仅仅是封装函数库，并没有模拟完整的操作系统
 *  docker是一个系统进程；虚拟机是在操作系统中的操作系统
 *  docker体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般

--------------------

### Docker架构 ###

Docker中有几个重要的概念：

**镜像（Image）**：Docker将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像。

**容器（Container）**：镜像中的应用程序运行后形成的进程就是**容器**，只是Docker会给容器进程做隔离，对外不可见。

![在这里插入图片描述][240ee487807642a09428ab8a9c8bda2a.png]

--------------------

**DockerHub**

开源应用程序非常多，打包这些应用往往是重复的劳动。为了避免这些重复劳动，人们就会将自己打包的应用镜像，例如Redis、MySQL镜像放到网络上，共享使用，就像GitHub的代码共享一样。

*  DockerHub：DockerHub是一个官方的Docker镜像的托管平台。这样的平台称为Docker Registry。
 *  国内也有类似于DockerHub 的公开服务，比如 [网易云镜像服务][Link 1]、[阿里云镜像库][Link 2]等。

一方面可以将自己的镜像共享到DockerHub，另一方面也可以从DockerHub拉取镜像：

![在这里插入图片描述][52d521333fa34f1c863a22ca018dfa8e.png]

--------------------

我们要使用Docker来操作镜像、容器，就必须要安装Docker。

Docker是一个CS架构的程序，由两部分组成：

*  服务端(server)：Docker守护进程，**负责处理Docker指令，管理镜像、容器**等
 *  客户端(client)：通过命令或RestAPI向Docker服务端发送指令。可以在本地或远程向服务端**发送指令。**

![在这里插入图片描述][50522041fdff47478e20a6adb7b936c8.png]

--------------------

### Docker的安装 ###

> **卸载（可选）**

如果之前安装过旧版本的Docker，可以使用下面命令卸载：

yum remove docker \
                      docker-client \
                      docker-client-latest \
                      docker-common \
                      docker-latest \
                      docker-latest-logrotate \
                      docker-logrotate \
                      docker-selinux \
                      docker-engine-selinux \
                      docker-engine \
                      docker-ce

--------------------

> **安装docker**

首先需要大家虚拟机联网，安装yum工具

yum install -y yum-utils \
               device-mapper-persistent-data \
               lvm2 --skip-broken

然后更新本地镜像源：

# 设置docker镜像源
    yum-config-manager \
        --add-repo \
        https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
        
    sed -i 's/download.docker.com/mirrors.aliyun.com\/docker-ce/g' /etc/yum.repos.d/docker-ce.repo
    
    yum makecache fast

然后输入命令：

yum install -y docker-ce

docker-ce为社区免费版本。稍等片刻，docker即可安装成功。

--------------------

> **启动docker**

Docker应用需要用到各种端口，逐一去修改防火墙设置。非常麻烦，因此建议大家直接关闭防火墙！

启动docker前，一定要关闭防火墙后！！或者开放它的2375端口

// 永久开放指定端口
    firewall-cmd --add-port=2375/tcp --permanent
    //重启防火墙
    firewall-cmd --reload

# 关闭
    systemctl stop firewalld
    # 禁止开机启动防火墙
    systemctl disable firewalld

(关闭防火墙和开放端口二选一）

通过命令启动docker：

systemctl start docker  # 启动docker服务
    
    systemctl stop docker  # 停止docker服务
    
    systemctl restart docker  # 重启docker服务

然后输入命令，可以查看docker版本：

docker -v

如图：

![在这里插入图片描述][e897c6775daf45088e92862317de1c8e.png]

--------------------

> **配置镜像加速**

和github同理，它的镜像仓库是国外的，访问速度很低，换成阿里的镜像或者网易的镜像都行

比如这里使用阿里云的镜像  
参考阿里云的镜像加速文档：[https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors][https_cr.console.aliyun.com_cn-hangzhou_instances_mirrors]

直接复制粘贴回车就行了  
配置镜像加速器  
针对Docker客户端版本大于 1.10.0 的用户

sudo mkdir -p /etc/docker
    sudo tee /etc/docker/daemon.json <<-'EOF'
    {
        
      "registry-mirrors": ["https://97wchhmj.mirror.aliyuncs.com"]
    }
    EOF
    sudo systemctl daemon-reload
    sudo systemctl restart docker

--------------------

### Docker基操 ###

> **镜像相关操作**

`镜像的名称组成`：

*  镜名称一般分两部分组成：\[repository\]:\[tag\]。
 *  在没有指定tag时，**默认是latest，代表最新版本的镜像**

![在这里插入图片描述][f57dc341fca14626a2d6e668b942f477.png]

--------------------

`镜像基本命令`

![在这里插入图片描述][73b8f4bac14a4120b51809b479e58013.png]

--------------------

**案例1从DockerHub拉取nginx镜像并查看镜像**  
1）首先去镜像仓库搜索nginx镜像，比如[DockerHub][]这个镜像仓库:  
有点慢很正常  
![在这里插入图片描述][1da9d74fd74f4b39a250e073a6dbc4bd.png]

![在这里插入图片描述][038588d7c84a46e3aaba26a55e03bc19.png]

--------------------

2）根据查看到的镜像名称，拉取自己需要的镜像，通过命令：docker pull nginx

不指定tag就默认最新版本

![在这里插入图片描述][8c056baace884daea11b967e9e140caa.png]

--------------------

3）通过命令：docker images 查看拉取到的镜像

![在这里插入图片描述][3234cca271d243e594a393b5f0b86a9c.png]

--------------------

**案例2利用docker save将nginx镜像导出磁盘，然后再通过load加载回来**

命令格式：

docker save -o [保存的目标文件名称] [镜像名称]

使用docker save导出镜像到磁盘

运行命令：

docker save -o nginx.tar nginx:latest

![在这里插入图片描述][4428d08388b646d7ac7a620a70f68b9d.png]

先删除本地的nginx镜像：

docker rmi nginx:latest

然后运行命令，加载本地文件：

docker load -i nginx.tar

结果：  
![在这里插入图片描述][5ca035bec85d49e180c15a1d97ce1e78.png]

--------------------

> **容器相关操作**

容器保护三个状态：

*  运行：进程正常运行
 *  暂停：进程暂停，CPU不再运行，进程挂起，并不释放内存
 *  停止：进程终止，回收进程占用的内存、CPU等资源  
    ![在这里插入图片描述][1d778606685e473e808a428e9a803f6b.png]  
    `docker run`：创建并运行一个容器，处于运行状态  
    `docker pause`：让一个运行的容器暂停  
    `docker unpause`：让一个容器从暂停状态恢复运行  
    `docker stop`：停止一个运行的容器  
    `docker start`：让一个停止的容器再次运行  
    `docker rm`：删除一个容器

--------------------

> **案例：创建并运行一个nginx容器**

![在这里插入图片描述][d41cf8800d32484fa7324373d1dc2588.png]  
最后后面两个参数含义

*  \-d：后台运行容器
 *  nginx：镜像名称，例如nginx

容器端口映射到主机端口，映射的主机端口可变，不一定非要和容器一致，这里也可以是8080

![在这里插入图片描述][0b98d32b00e54f98b02df5c88886680a.png]

docker ps #查看容器 加上-a可以查看停止的容器
    docker logs 容器名  #查看容器日志

查看容器日志，添加 -f 参数可以持续查看日志

--------------------

> **案例-进入容器**

进入容器。进入我们刚刚创建的nginx容器的命令为：

docker exec -it mn bash

命令解读：

*  docker exec ：进入容器内部，执行一个命令
 *  \-it : 给当前进入的容器创建一个标准输入、输出终端，允许我们与容器交互
 *  mn ：要进入的容器的名称
 *  bash：进入容器后执行的命令，bash是一个linux终端交互命令

![在这里插入图片描述][4320bdb1ef5c4fc4a6aceb63a249f7dd.png]

不建议在容器中修改文件

--------------------

练手demo

![在这里插入图片描述][90d5a51f214c49b3883144f4a2b649d2.png]

![在这里插入图片描述][711741ecd2a1467b9369004076ac0bdf.png]

![在这里插入图片描述][227485b254634aa7b841ad69a9663144.png]

进入redis客户端

![在这里插入图片描述][406a358c127641c69bccae7bfa504644.png]

存入键值

![在这里插入图片描述][2761efc7c531494f9b668b615c3b8a7a.png]

RDM软件连接该服务器ip，连接redis  
查看存入的键值

![在这里插入图片描述][f0b35f55b4624b2bb19757080c41d717.png]

--------------------

> **数据卷**

通过上面案例可以看出容器与数据耦合的一些问题，容器内部**没有vi编辑器**，修改文件很麻烦  
![853e1717f93143b687d158645513dfef.png][]  
要解决这些问题，必须将数据与容器解耦，这就要用到数据卷了。

--------------------

**什么是数据卷**

数据卷（volume）是一个虚拟目录，指向宿主机文件系统中的某个目录。

数据卷就是服务器主机和容器连接的桥梁

![在这里插入图片描述][93e1fae002ea4d2383fb9fbe6c09d4db.png]  
**一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。**  
这样，我们操作宿主机的/var/lib/docker/volumes/html目录，就等于操作容器内的/usr/share/nginx/html目录了  
而容器删除，数据卷不会删除，这样再次加入新的容器，挂载在数据卷下，就又连接起来了

--------------------

***数据卷的基本语法***  
数据卷操作命令是二级命令

数据卷操作的基本语法如下：

docker volume [COMMAND]

docker volume命令是数据卷操作，根据命令后跟随的command来确定下一步的操作：

*  create 创建一个volume
 *  inspect 显示一个或多个volume的信息
 *  ls 列出所有的volume
 *  prune 删除未使用的volume
 *  rm 删除一个或多个指定的volume

![在这里插入图片描述][3dcfe59d12e94e9cbd1d9017318c78fb.png]

> 小结

数据卷的作用：

`将容器与数据分离，解耦合，方便操作容器内数据，保证数据安全`

数据卷操作：

*  docker volume create：创建数据卷
 *  docker volume ls：查看所有数据卷
 *  docker volume inspect：查看数据卷详细信息，包括关联的宿主机目录位置
 *  docker volume rm：删除指定数据卷
 *  docker volume prune：删除所有未使用的数据卷

--------------------

**挂载数据卷实操**  
我们在创建容器时，可以通过 -v 参数来挂载一个数据卷到某个容器内目录，命令格式如下：

docker run \
      --name mn \
      -v html:/root/html \
      -p 8080:80
      nginx \

这里的-v就是挂载数据卷的命令：

*  `-v html:/root/htm` ：把html数据卷挂载到容器内的/root/html这个目录中

--------------------

**案例-给nginx挂载数据卷**  
**需求**：创建一个nginx容器，修改容器内的html目录内的index.html内容

**分析**：上个案例中，我们进入nginx容器内部，已经知道nginx的html目录所在位置/usr/share/nginx/html ，我们需要把这个目录挂载到html这个数据卷上，方便操作其中的内容。

**提示**：运行容器时使用 -v 参数挂载数据卷

步骤：

① 创建容器并挂载数据卷到容器内的HTML目录

docker run --name mn -v html:/usr/share/nginx/html -p 80:80 -d nginx

② 进入html数据卷所在位置，并修改HTML内容

# 查看html数据卷的位置
    docker volume inspect html
    # 进入该目录
    cd /var/lib/docker/volumes/html/_data
    # 修改文件
    vi index.html

![在这里插入图片描述][60616f739c12473fa9f4dbb61bfa66cf.png]

而且都不用重启容器，即时生效

注：我们在做容器的数据卷**挂载**时，如果数据卷不存在，Docker会自动帮我创建数据卷

--------------------

**案例-给MySQL挂载本地目录**  
容器不仅仅可以挂载数据卷，也可以直接挂载到宿主机目录上。关联关系如下：

*  带数据卷模式：宿主机目录 --> 数据卷 —> 容器内目录
 *  直接挂载模式：宿主机目录 —> 容器内目录

![在这里插入图片描述][e6d4a92c00374d889641452c6f829831.png]

**语法**：

目录挂载与数据卷挂载的语法是类似的：

*  \-v \[宿主机目录\]:\[容器内目录\]
 *  \-v \[宿主机文件\]:\[容器内文件\]

**需求**：创建并运行一个MySQL容器，将宿主机目录直接挂载到容器

实现思路如下：

1）在将课前资料中的mysql.tar文件上传到虚拟机，通过load命令加载为镜像

2）创建目录/tmp/mysql/data

3）创建目录/tmp/mysql/conf，将课前资料提供的hmy.cnf文件上传到/tmp/mysql/conf

4）去DockerHub查阅资料，创建并运行MySQL容器，要求：

① 挂载/tmp/mysql/data到mysql容器内数据存储目录

② 挂载/tmp/mysql/conf/hmy.cnf到mysql容器的配置文件

③ 设置MySQL密码

--------------------

***总结***

docker run的命令中通过 -v 参数挂载文件或目录到容器中：

*  \-v volume名称:容器内目录
 *  \-v 宿主机文件:容器内文件
 *  \-v 宿主机目录:容器内目录

数据卷挂载与目录直接挂载的

*  数据卷挂载耦合度低，由docker来管理目录，但是目录较深，不好找
 *  目录挂载耦合度高，需要我们自己管理目录，不过目录容易寻找查看

--------------------

### Dockerfile自定义镜像 ###

常见的镜像在DockerHub就能找到，但是我们自己写的项目就必须自己构建镜像了。

***镜像结构***  
镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。  
简单来说，镜像就是在系统函数库、运行环境基础上，添加应用程序文件、配置文件、依赖文件等组合，然后编写好启动脚本打包在一起形成的文件。

镜像是分层结构，每一层称为一个Layer  
`BaseImage层`：包含基本的系统函数库、环境变量、文件系统  
`Entrypoint`：入口，是镜像中应用启动的命令  
`其它`：在BaseImage基础上添加依赖、安装程序、完成整个应用的安装和配置

以MySQL为例，来看看镜像的组成结构：  
![在这里插入图片描述][c010947102a34d71a7f163f759a2baa7.png]

--------------------

构建自定义的镜像时，并不需要一个个文件去拷贝，打包。

我们只需要将我们的镜像的组成，需要哪些BaseImage、需要拷贝什么文件、需要安装什么依赖、启动脚本是什么都添加到Dockerfile文件中。

用Dockerfile文件来描述构建信息

**Dockerfile**就是一个文本文件，其中包含一个个的**指令(Instruction)**，用指令来说明要执行什么操作来构建镜像。每一个指令都会形成一层Layer

![在这里插入图片描述][ee38b67973f14de68af61b8d124f2a16.png]

**下面构建一个java项目作为演示**

`①步骤1：新建一个空文件夹docker-demo，把相应的java的jar包和JDK压缩包以及创建Dockerfile都添加该目录中`

`②编写Dockerfile文件，将构建镜像相关信息都添加到Dockerfile文件中`

例如下

# 指定基础镜像
    FROM ubuntu:16.04
    # 配置环境变量，JDK的安装目录
    ENV JAVA_DIR=/usr/local
    
    # 拷贝jdk和java项目的包
    COPY ./jdk8.tar.gz $JAVA_DIR/
    COPY ./docker-demo.jar /tmp/app.jar
    
    # 安装JDK
    RUN cd $JAVA_DIR \
     && tar -xf ./jdk8.tar.gz \
     && mv ./jdk1.8.0_144 ./java8
    
    # 配置环境变量
    ENV JAVA_HOME=$JAVA_DIR/java8
    ENV PATH=$PATH:$JAVA_HOME/bin
    
    # 暴露端口
    EXPOSE 8090
    # 入口，java项目的启动命令
    ENTRYPOINT java -jar /tmp/app.jar

`③在docker-demo目录下执行命令构建镜像`

docker build -t javaweb:1.0 .

![在这里插入图片描述][5cd94cc581be4193968313ef837ccc94.png]

将构建好的镜像运行

docker run --name web -p 8090:8090 -d javaweb:1.0

![在这里插入图片描述][98b3a3eda5ea448bb6fce96659993842.png]

--------------------

**基于java8构建Java项目**

虽然可以添加任意自己需要的安装包，构建镜像，但是却比较麻烦。所以大多数情况下，我们都可以在一些安装了**部分软件的基础镜像**上做改造。

例如，构建java项目的镜像，可以在已经准备了JDK的基础镜像基础上构建。  
![在这里插入图片描述][46f67cd0ab7a4cbc8c44980ca9bb3c28.png]

例如下  
需求：基于java:8-alpine镜像，将一个Java项目构建为镜像

实现思路如下：

*  ① 新建一个空的目录，然后在目录中新建一个文件，命名为Dockerfile
 *  ② 拷贝课前资料提供的docker-demo.jar到这个目录中
 *  ③ 编写Dockerfile文件：
    
     *  a ）基于java:8-alpine作为基础镜像
     *  b ）将app.jar拷贝到镜像中
     *  c ）暴露端口
     *  d ）编写入口ENTRYPOINT
        
        内容如下：
        
            FROM java:8-alpine
            COPY ./app.jar /tmp/app.jar
            EXPOSE 8090
            ENTRYPOINT java -jar /tmp/app.jar
 *  ④ 使用docker build命令构建镜像
 *  ⑤ 使用docker run创建容器并运行

> ***小结***

1.  Dockerfile的本质是一个**文件**，通过指令描述镜像的构建过程
2.  Dockerfile的第一行必须是FROM，从一个基础镜像来构建
3.  基础镜像可以是基本操作系统，如Ubuntu，CentOS。也可以是其他人制作好的镜像，例如：java:8-alpine

--------------------

### Docker-Compose ###

当微服务较多时，我们不可能一个一个的创建并运行容器，若要快速部署应用服务，就需要使用到Compose文件

Docker Compose可以基于Compose文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器

Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行（和Dockerfile有点类似）

![在这里插入图片描述][542da36c9cbc4c669401520bea9887f4.png]

上面的Compose文件就描述一个项目，其中包含两个容器：

*  mysql：一个基于`mysql:5.7.25`镜像构建的容器，并且挂载了两个目录
 *  web：一个基于`docker build`临时构建的镜像容器，映射端口时8090

--------------------

> 安装 Compose

1.下载compose

# 安装
    curl -L https://github.com/docker/compose/releases/download/1.23.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

但由于是外网下载很慢，这里直接把compoes压缩包放这里，下载更快  
Compose下载地址  
提取码：8tfx

将下载后的文件上传到`/usr/local/bin/`目录即可。

--------------------

2.修改文件权限

# 修改权限
    chmod +x /usr/local/bin/docker-compose

![在这里插入图片描述][31c2e7d38f084913a0c9b348beb7abca.png]

--------------------

3.添加Base自动补全命令  
①

echo "199.232.68.133 raw.githubusercontent.com" >> /etc/hosts

②

systemctl restart docker

③

curl -L http://raw.githubusercontent.com/docker/compose/1.29.1/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

**复制粘贴按顺序运行即可，这个也是我踩坑后总结的顺序，不然就会一直下载中**

最后结果图  
![在这里插入图片描述][75873081a9274bc78ca180e3d53a67a8.png]

--------------------

> **部署微服务集群**

**需求**：将之前学习的cloud-demo微服务集群利用DockerCompose部署

**实现思路**：

① 编写好docker-compose文件用于构建项目镜像

② 修改自己的cloud-demo项目，将数据库、nacos地址都命名为docker-compose中的服务名

③ 使用maven打包工具，将项目中的每个微服务都打包为app.jar

④ 将打包好的app.jar拷贝到cloud-demo中的每一个对应的子目录中

⑤ 将cloud-demo上传至虚拟机，利用 docker-compose up -d 来部署

--------------------

> **Compose文件编写**

每个微服务都准备了一个独立的目录：

![在这里插入图片描述][1037d0d26f654627be6125c21e97f4eb.png]  
**（dockerfile可以说是构建自定义镜像，docker-compose是运行镜像构建的容器）**

`docker-compose中的build参数是要求dockerfile文件的位置，根据dockerfile来构建镜像`

version: "3.2"
    
    services:
      nacos:
        image: nacos/nacos-server
        environment:
          MODE: standalone
        ports:
          - "8848:8848"
      mysql:
        image: mysql:5.7.25
        environment:
          MYSQL_ROOT_PASSWORD: 123
        volumes:
          - "$PWD/mysql/data:/var/lib/mysql"
          - "$PWD/mysql/conf:/etc/mysql/conf.d/"
      userservice:
        build: ./user-service
      orderservice:
        build: ./order-service
      gateway:
        build: ./gateway
        ports:
          - "10010:10010"

--------------------

> **修改微服务配置**

因为微服务将来要部署为docker容器，而**容器之间互联不是通过IP地址**，而是通过容器名。这里我们将order-service、user-service、gateway服务的mysql、nacos地址都修改为基于容器名的访问。

如下所示：

spring:
      datasource:
        url: jdbc:mysql://mysql:3306/cloud_order?useSSL=false
        username: root
        password: 123
        driver-class-name: com.mysql.jdbc.Driver
      application:
        name: orderservice
      cloud:
        nacos:
          server-addr: nacos:8848 # nacos服务地址

把原本的localhost换成容器名称nacos，MySQL的localhost也需要替换一下

--------------------

> **打包**

接下来需要将我们的每个微服务都打包。因为之前查看到Dockerfile中的jar包名称都是app.jar，因此我们的每个微服务都需要用这个名称。

可以通过修改pom.xml中的打包名称来实现，每个微服务都需要修改：

<build>
      
      <finalName>app</finalName>
      <plugins>
        <plugin>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
      </plugins>
    </build>

![在这里插入图片描述][141f18c8604d4ef99e3a85b0bfbb5417.png]

--------------------

> **拷贝jar包到部署目录**

编译打包好的app.jar文件，需要放到Dockerfile的同级目录中。注意：每个微服务的app.jar放到与服务名称对应的目录，别搞错了。

例如user-service：  
![在这里插入图片描述][a6ef123dfba94b7fb4359722d3bee184.png]

--------------------

> **部署**

最后，我们需要将文件整个cloud-demo文件夹上传到虚拟机中，通过DockerCompose部署。

然后进入cloud-demo目录，然后运行下面的命令：

docker-compose up -d

![在这里插入图片描述][cebf6bd21c424578b16144958cf6ba22.png]

最后注意如果nacos启动过慢的话，其他服务就会连接失败报错，最后把除nacos的服务重启一遍就会来连接成功了

--------------------

### Docker镜像仓库 ###

镜像仓库比如DockerHub，镜像仓库（ Docker Registry ）有公共的和私有的两种形式，一般企业会搭建自己公司的私有镜像仓库。

下面介绍一下本地搭建私有 Docker Registry  
搭建镜像仓库可以基于Docker官方提供的DockerRegistry来实现。

--------------------

**简化版镜像仓库**  
Docker官方的Docker Registry是一个基础版本的Docker镜像仓库，具备仓库管理的完整功能，但是没有图形化界面。

搭建方式比较简单，命令如下：

docker run -d \
        --restart=always \
        --name registry	\
        -p 5000:5000 \
        -v registry-data:/var/lib/registry \
        registry

命令中挂载了一个数据卷registry-data到容器内的/var/lib/registry 目录，这是私有镜像库存放数据的目录。

--------------------

**带有图形化界面版本**  
使用DockerCompose部署带有图象界面的DockerRegistry，命令如下：

version: '3.0'
    services:
      registry:
        image: registry
        volumes:
          - ./registry-data:/var/lib/registry
      ui:
        image: joxit/docker-registry-ui:static
        ports:
          - 8080:80
        environment:
          - REGISTRY_TITLE=本地私有仓库
          - REGISTRY_URL=http://registry:5000
        depends_on:
          - registry

--------------------

**配置Docker信任地址**  
我们的私服采用的是http协议，默认不被Docker信任，所以需要做一个配置：

# 打开要修改的文件
    vi /etc/docker/daemon.json
    # 添加内容：
    "insecure-registries":["http://本机ip:8080"]
    # 重加载
    systemctl daemon-reload
    # 重启docker
    systemctl restart docker

![在这里插入图片描述][83057f41dcc344c290a8941ffa2e7557.png]

![在这里插入图片描述][66d6814f71574520874bf7bd55830a98.png]

最后浏览器访问自己配置的仓库地址就会看到图形化界面

--------------------

**推送拉取镜像**  
推送镜像到私有镜像服务必须先tag，步骤如下：

① 重新tag本地镜像，名称前缀为私有仓库的地址： 仓库IP:8080/

docker tag nginx:latest 自己ip地址:8080/nginx:1.0

② 推送镜像

docker push 自己ip地址:8080/nginx:1.0

③ 拉取镜像

docker pull 自己ip地址:8080/nginx:1.0

--------------------

![在这里插入图片描述][0229551881974fafa4719e8d29e6b3ad.png]

--------------------

## 异步通信 ##

### 初识MQ ###

微服务间通讯有同步和异步两种方式：

同步通讯：就像**打电话**，需要实时响应。

异步通讯：就像**发消息**，不需要马上回复。

--------------------

#### 同步通讯 ####

下面以用户购物业务为例  
![在这里插入图片描述][807106eafa6d4bdc9dcf60949e7f271c.png]

Feign调用就属于同步方式，虽然调用可以实时得到结果，但存在下面的问题：  
![在这里插入图片描述][599d6e92705f43beb072891318b92214.png]

--------------------

同步调用的**优点**：

*  时效性较强，可以立即得到结果

同步调用的**问题**：

*  耦合度高
 *  性能和吞吐能力下降
 *  有额外的资源消耗
 *  有级联失败问题

--------------------

#### 异步通讯 ####

异步调用则可以避免上述问题：

还是以上面的用户购物业务为例  
为了解除事件发布者与订阅者之间的耦合，两者并不是直接通信，而是有一个中间人（Broker）。发布者发布事件到Broker，不关心谁来订阅事件。订阅者从Broker订阅事件，不关心谁发来的消息。

![在这里插入图片描述][e2cb8060fdd94e35b2bfdfa98c7b7567.png]

--------------------

还有一个重要的功能解决高并发问题，实现削峰  
![在这里插入图片描述][5b0c427a55d24f539f036720ea8d992e.png]  
把一个时间点的大量请求给放入broker中，后台照常处理，不让大量请求直接打向服务，压力由Broker扛着，充当缓冲层。

--------------------

Broker 是一个像数据总线一样的东西，所有的服务要接收数据和发送数据都发到这个总线上，这个总线就像协议一样，让服务间的通讯变得标准和可控。  
![在这里插入图片描述][262af2d7e00c40c6936f340e77fd7ac8.png]

--------------------

优点：

*  吞吐量提升：无需等待订阅者处理完成，响应更快速
 *  故障隔离：服务没有直接调用，不存在级联失败问题
 *  调用间没有阻塞，不会造成无效的资源占用
 *  耦合度极低，每个服务都可以灵活插拔，可替换
 *  流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件

缺点：

*  架构复杂了，业务没有明显的流程线，不好管理
 *  需要依赖于Broker的可靠、安全、性能

> 大部分场景都是使用同步调用，因为要求时效性它的返回结果；异步调用只是在高并发的业务中使用到

--------------------

#### MQ常见框架 ####

MQ，中文是消息队列（MessageQueue），字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。

比较常见的MQ实现：

*  ActiveMQ
 *  RabbitMQ
 *  RocketMQ
 *  Kafka

几种常见MQ的对比：

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th><strong>RabbitMQ</strong></th> 
   <th><strong>ActiveMQ</strong></th> 
   <th><strong>RocketMQ</strong></th> 
   <th><strong>Kafka</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>公司/社区</td> 
   <td>Rabbit</td> 
   <td>Apache</td> 
   <td>阿里</td> 
   <td>Apache</td> 
  </tr> 
  <tr> 
   <td>开发语言</td> 
   <td>Erlang</td> 
   <td>Java</td> 
   <td>Java</td> 
   <td>Scala&amp;Java</td> 
  </tr> 
  <tr> 
   <td>协议支持</td> 
   <td>AMQP，XMPP，SMTP，STOMP</td> 
   <td>OpenWire,STOMP，REST,XMPP,AMQP</td> 
   <td>自定义协议</td> 
   <td>自定义协议</td> 
  </tr> 
  <tr> 
   <td>可用性</td> 
   <td>高</td> 
   <td>一般</td> 
   <td>高</td> 
   <td>高</td> 
  </tr> 
  <tr> 
   <td>单机吞吐量</td> 
   <td>一般</td> 
   <td>差</td> 
   <td>高</td> 
   <td>非常高</td> 
  </tr> 
  <tr> 
   <td>消息延迟</td> 
   <td>微秒级</td> 
   <td>毫秒级</td> 
   <td>毫秒级</td> 
   <td>毫秒以内</td> 
  </tr> 
  <tr> 
   <td>消息可靠性</td> 
   <td>高</td> 
   <td>一般</td> 
   <td>高</td> 
   <td>一般</td> 
  </tr> 
 </tbody> 
</table>

追求**可用性**：Kafka、 RocketMQ 、RabbitMQ

追求**可靠性**：RabbitMQ、RocketMQ

追求**吞吐能力**：RocketMQ、Kafka

追求**消息低延迟**：RabbitMQ、Kafka

--------------------

### RabbitMQ快速入门 ###

#### RabbitMQ概述和安装 ####

**①安装rabbitmq:镜像**

docker pull rabbitmq:3-management

**②运行MQ容器**

其中管理界面的账号密码自己设置，问题不大

docker run \
     -e RABBITMQ_DEFAULT_USER=管理界面的账号 \
     -e RABBITMQ_DEFAULT_PASS=管理界面的密码 \
     --name mq \
     --hostname mq1 \
     -p 15672:15672 \
     -p 5672:5672 \
     -d \
     rabbitmq:3-management

--------------------

**③开放端口**  
开放MQ的端口5672和它的管理端口15672

sudo firewall-cmd --zone=public --permanent --add-port=15672/tcp
     sudo firewall-cmd --zone=public --permanent --add-port=5672/tcp
     firewall-cmd --reload

![在这里插入图片描述][39a059cc39a14c378d3d614182cdcd13.png]

如果是服务器的话，防火墙添加开放规则

--------------------

然后 ip+端口号 来访问MQ的管理界面，账号密码就是自己刚才设置的。

![在这里插入图片描述][983121e2518742378919fd7dd653968d.png]

**MQ的基本结构：**  
![在这里插入图片描述][ae4ffe8e857240069beaeaab5bd4b503.png]

--------------------

#### 常见消息模型 ####

两种消息对列和三种订阅模式

![在这里插入图片描述][22e9ab37fb134587a757ab96532088ae.png]

--------------------

![在这里插入图片描述][2207ba24f1fb403d902a32d102d62465.png]  
官方的HelloWorld是基于最基础的消息队列模型来实现的，只包括三个角色：

*  publisher：消息发布者，将消息发送到队列queue
 *  queue：消息队列，负责接受并缓存消息
 *  consumer：订阅队列，处理队列中的消息

--------------------

#### 快速入门 ####

接下来就实现这个HelloWorld基本消息队列

思路：

*  建立连接
 *  创建Channel
 *  声明队列
 *  发送消息
 *  关闭连接和channel

--------------------

**publisher实现**

代码思路:

*  建立连接
 *  创建Channel
 *  声明队列
 *  发送消息
 *  关闭连接和channel

public class PublisherTest {
        
        @Test
        public void testSendMessage() throws IOException, TimeoutException {
        
            // 1.建立连接
            ConnectionFactory factory = new ConnectionFactory();
            // 1.1.设置连接参数，分别是：主机名、端口号、vhost、用户名、密码
            factory.setHost("192.168.150.101");
            factory.setPort(5672);
            factory.setVirtualHost("/");
            factory.setUsername("itcast");
            factory.setPassword("123321");
            // 1.2.建立连接
            Connection connection = factory.newConnection();
    
            // 2.创建通道Channel
            Channel channel = connection.createChannel();
    
            // 3.创建队列
            String queueName = "simple.queue";
            channel.queueDeclare(queueName, false, false, false, null);
    
            // 4.发送消息
            String message = "hello, rabbitmq!";
            channel.basicPublish("", queueName, null, message.getBytes());
            System.out.println("发送消息成功：【" + message + "】");
    
            // 5.关闭通道和连接
            channel.close();
            connection.close();
    
        }
    }

发送后访问rabbitmq的管理界面，可以看到发送的消息

![在这里插入图片描述][cb4a0684d714480fa170613915c02dad.png]

--------------------

**consumer实现**

代码思路：

*  建立连接
 *  创建Channel
 *  声明队列
 *  订阅消息

public class ConsumerTest {
        
    
        public static void main(String[] args) throws IOException, TimeoutException {
        
            // 1.建立连接
            ConnectionFactory factory = new ConnectionFactory();
            // 1.1.设置连接参数，分别是：主机名、端口号、vhost、用户名、密码
            factory.setHost("192.168.150.101");
            factory.setPort(5672);
            factory.setVirtualHost("/");
            factory.setUsername("itcast");
            factory.setPassword("123321");
            // 1.2.建立连接
            Connection connection = factory.newConnection();
    
            // 2.创建通道Channel
            Channel channel = connection.createChannel();
    
            // 3.创建队列
            String queueName = "simple.queue";
            channel.queueDeclare(queueName, false, false, false, null);
    
            // 4.订阅消息
            channel.basicConsume(queueName, true, new DefaultConsumer(channel){
        
                @Override
                public void handleDelivery(String consumerTag, Envelope envelope,
                                           AMQP.BasicProperties properties, byte[] body) throws IOException {
        
                    // 5.处理消息
                    String message = new String(body);
                    System.out.println("接收到消息：【" + message + "】");
                }
            });
            System.out.println("等待接收消息。。。。");
        }
    }

消费后消息就不存在了，阅后即焚

![在这里插入图片描述][dfa6b58f97084659a9d64782a1e909d3.png]

--------------------

基本消息队列的消息**发送流程**：  
1.建立connection  
2.创建channel  
3.利用channel声明队列  
4.利用channel向队列发送消息

--------------------

基本消息队列的消息**接收流程**：  
1.建立connection  
2.创建channel  
3.利用channel声明队列  
4.定义consumer的消费行为handleDelivery()  
5.利用channel将消费者与队列绑定

--------------------

发送和接收都重复建立连接，通道，队列，是为了做个双保险，因为不清楚发送和接收代码谁先执行谁后执行，但要保证无论谁执行，连接通道和队列要存在。

--------------------

### SpringAMQP ###

> 什么是SpringAMQP

![在这里插入图片描述][9fe854ec19724d938d8d7f636d04e829.png]

**SpringAMQP提供了三个功能：**

*  自动声明队列、交换机及其绑定关系
 *  基于注解的监听器模式，异步接收消息
 *  封装了RabbitTemplate工具，用于发送消息

--------------------

#### Basic Queue 简单队列模型 ####

流程如下：  
1.在父工程中引入spring-amqp的依赖（父工程引入依赖后，子模块的发送者和接收者就不用重复引入了）  
2.在publisher服务中利用RabbitTemplate发送消息到simple.queue这个队列  
3.在consumer服务中编写消费逻辑，绑定simple.queue这个队列

--------------------

> **消息的发送**

`①在父工程mq-demo中引入依赖`

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-amqp</artifactId>
    </dependency>

`②yml配置文件中添加MQ的配置信息`

spring:
      rabbitmq:
        host: 192.168.150.101 # 主机名
        port: 5672 # 端口
        virtual-host: / # 虚拟主机
        username: rabbitmq # 用户名
        password: 123456 # 密码

`③在publisher服务中编写测试类SpringAmqpTest，并利用RabbitTemplate实现消息发送`

前提是，代码中的队列（simple.queue）必须已经创建

@RunWith(SpringRunner.class)
    @SpringBootTest
    public class SpringAmqpTest {
        
    
        @Autowired
        private RabbitTemplate rabbitTemplate;
    
        @Test
        public void testSimpleQueue() {
        
            // 队列名称
            String queueName = "simple.queue";
            // 消息
            String message = "hello, spring amqp!";
            // 发送消息
            rabbitTemplate.convertAndSend(queueName, message);
        }
    }

--------------------

> **消息的接收**

`①yml配置文件中添加配置信息`

spring:
      rabbitmq:
        host: 192.168.150.101 # 主机名
        port: 5672 # 端口
        virtual-host: / # 虚拟主机
        username: ribbit # 用户名
        password: 123456 # 密码

`②在consumer服务的listener包中新建一个类SpringRabbitListener`

@Component
    public class SpringRabbitListener {
        
    
        @RabbitListener(queues = "simple.queue")
        public void listenSimpleQueueMessage(String msg) throws InterruptedException {
        
            System.out.println("spring 消费者接收到消息：【" + msg + "】");
        }
    }

> **最后启动测试**

启动consumer服务，然后在publisher服务中运行测试代码，发送MQ消息

--------------------

> **总结**

*什么是AMQP？*  
应用间消息通信的一种协议，与语言和平台无关。

*SpringAMQP如何发送消息？*  
①引入amqp的starter依赖  
②配置RabbitMQ地址  
③利用RabbitTemplate的convertAndSend方法

*SpringAMQP如何接收消息？*  
①引入amqp的starter依赖  
②配置RabbitMQ地址  
③定义类，添加@Component注解  
④类中声明方法，添加@RabbitListener注解，方法参数就是消息

注意：消息一旦消费就会从队列删除，RabbitMQ没有消息回溯功能

--------------------

#### Work Queue 工作队列模型 ####

当消息处理比较耗时的时候，可能生产消息的速度会远远大于消息的消费速度。长此以往，消息就会堆积越来越多，无法及时处理。

此时就可以使用work 模型，多个消费者共同处理消息处理，速度就能大大提高了。  
![在这里插入图片描述][2a3cd29b68374faab4bfacf1b8720de7.png]  
简单来说就是**让多个消费者绑定到一个队列，共同消费队列中的消息**。

--------------------

> **消息发送**

我们循环发送，来模拟大量消息堆积现象。

在publisher服务中的SpringAmqpTest类中添加一个测试方法：

/**
         * workQueue
         * 向队列中不停发送消息，模拟消息堆积。
         */
    @Test
    public void testWorkQueue() throws InterruptedException {
        
        // 队列名称
        String queueName = "simple.queue";
        // 消息
        String message = "hello, message_";
        for (int i = 0; i < 50; i++) {
        
            // 发送消息
            rabbitTemplate.convertAndSend(queueName, message + i);
            Thread.sleep(20);
        }
    }

--------------------

> **消息接收**

要模拟多个消费者绑定同一个队列，我们在consumer服务的SpringRabbitListener中添加2个新的方法：

@RabbitListener(queues = "simple.queue")
    public void listenWorkQueue1(String msg) throws InterruptedException {
        
        System.out.println("消费者1接收到消息：【" + msg + "】" + LocalTime.now());
        Thread.sleep(20);
    }
    
    @RabbitListener(queues = "simple.queue")
    public void listenWorkQueue2(String msg) throws InterruptedException {
        
        System.err.println("消费者2........接收到消息：【" + msg + "】" + LocalTime.now());
        Thread.sleep(200);
    }

注意到这个消费者sleep了1000秒，模拟任务耗时。

--------------------

> **运行测试**

启动ConsumerApplication后，在执行publisher服务中刚刚编写的发送测试方法testWorkQueue。

可以看到消费者1很快完成了自己的25条消息。消费者2却在缓慢的处理自己的25条消息。

也就是说消息是平均分配给每个消费者，并没有考虑到消费者的处理能力。这样显然是有问题的。

--------------------

**能者多劳**  
**消息预取**，是先进行消息分配，分配完毕后再给它处理，先拿了再说，这就是消息的预取  
在spring中有一个简单的配置，可以解决这个问题。我们修改consumer服务的application.yml文件，添加配置：

spring:
      rabbitmq:
        listener:
          simple:
            prefetch: 1 # 每次只能获取一条消息，处理完成才能获取下一个消息

没生效的重启consumer的application启动类

--------------------

> **总结**

Work模型的使用：

*  多个消费者绑定到一个队列，同一条消息只会被一个消费者处理
 *  通过设置prefetch来控制消费者预取的消息数量

--------------------

#### 发布/订阅 ####

![在这里插入图片描述][85b3c06977e74f14a65e387425e6d628.png]

可以看到，在订阅模型中，多了一个exchange角色，而且过程略有变化：

*  Publisher：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）
 *  Exchange：交换机，图中的X。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有以下3种类型：
    
     *  Fanout：广播，将消息交给所有绑定到交换机的队列
     *  Direct：定向，把消息交给符合指定routing key 的队列
     *  Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列
 *  Consumer：消费者，与以前一样，订阅队列，没有变化
 *  Queue：消息队列也与以前一样，接收消息、缓存消息。

--------------------

#### 发布、订阅模型-Fanout ####

Fanout，英文翻译是扇出，我觉得在MQ中叫广播更合适

![在这里插入图片描述][94957a8498c945f789c5737753cd0a47.png]

在广播模式下，消息发送流程是这样的：

*  1） 可以有多个队列
 *  2） 每个队列都要绑定到Exchange（交换机）
 *  3） 生产者发送的消息，只能发送到交换机，交换机来决定要发给哪个队列，生产者无法决定
 *  4） 交换机把消息发送给绑定过的所有队列
 *  5） 订阅队列的**消费者都能**拿到消息

--------------------

代码思路

*  创建一个交换机 itcast.fanout，类型是Fanout
 *  创建两个队列fanout.queue1和fanout.queue2，绑定到交换机itcast.fanout

![在这里插入图片描述][fb706814a4684dc7a5784faad5d7db15.png]

--------------------

> **声明交换机和队列**

Spring提供了一个接口Exchange，来表示不同类型的交换机

![在这里插入图片描述][b3bb23fde2a54a458b1be53fb0dca600.png]

在consumer中创建一个类，声明队列和交换机：

@Configuration
    public class FanoutConfig {
        
        /**
         * 声明交换机
         * @return Fanout类型交换机
         */
        @Bean
        public FanoutExchange fanoutExchange(){
        
            return new FanoutExchange("itcast.fanout");
        }
    
        /**
         * 第1个队列
         */
        @Bean
        public Queue fanoutQueue1(){
        
            return new Queue("fanout.queue1");
        }
    
        /**
         * 绑定队列和交换机
         */
        @Bean
        public Binding bindingQueue1(Queue fanoutQueue1, FanoutExchange fanoutExchange){
        
            return BindingBuilder.bind(fanoutQueue1).to(fanoutExchange);
        }
    
        /**
         * 第2个队列
         */
        @Bean
        public Queue fanoutQueue2(){
        
            return new Queue("fanout.queue2");
        }
    
        /**
         * 绑定队列和交换机
         */
        @Bean
        public Binding bindingQueue2(Queue fanoutQueue2, FanoutExchange fanoutExchange){
        
            return BindingBuilder.bind(fanoutQueue2).to(fanoutExchange);
        }
    }

--------------------

> **消息发送**

在publisher服务的SpringAmqpTest类中添加测试方法：

@Test
    public void testFanoutExchange() {
        
        // 队列名称
        String exchangeName = "itcast.fanout";
        // 消息
        String message = "hello, everyone!";
        rabbitTemplate.convertAndSend(exchangeName, "", message);
    }

> **消息接收**

在consumer服务的SpringRabbitListener中添加两个方法，作为消费者：

@RabbitListener(queues = "fanout.queue1")
    public void listenFanoutQueue1(String msg) {
        
        System.out.println("消费者1接收到Fanout消息：【" + msg + "】");
    }
    
    @RabbitListener(queues = "fanout.queue2")
    public void listenFanoutQueue2(String msg) {
        
        System.out.println("消费者2接收到Fanout消息：【" + msg + "】");
    }

--------------------

> **小结**

*交换机的作用是什么？*

*  接收publisher发送的消息
 *  将消息按照规则路由到与之绑定的队列
 *  **不能缓存消息**，路由失败，消息丢失
 *  FanoutExchange的会将消息路由到每个绑定的队列

*声明队列、交换机、绑定关系的Bean是什么？*

*  Queue
 *  FanoutExchange
 *  Binding

--------------------

#### 发布、订阅模型-Direct ####

在Fanout模式中，一条消息，会被所有订阅的队列都消费。但是，在某些场景下，我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。

![在这里插入图片描述][9302b2f736414a928137f71568d93d25.png]

在Direct模型下：

*  队列与交换机的绑定，不能是任意绑定了，而是要指定一个`RoutingKey`（路由key）
 *  消息的发送方在 向 Exchange发送消息时，也必须指定消息的 `RoutingKey`。
 *  Exchange不再把消息交给每一个绑定的队列，而是根据消息的`Routing Key`进行判断，只有队列的`Routingkey`与消息的 `Routing key`完全一致，才会接收到消息

--------------------

**案例需求如下**：

1.  利用@RabbitListener声明Exchange、Queue、RoutingKey
2.  在consumer服务中，编写两个消费者方法，分别监听direct.queue1和direct.queue2
3.  在publisher中编写测试方法，向itcast. direct发送消息

> **基于注解声明队列和交换机**

基于@Bean的方式声明队列和交换机比较麻烦，Spring还提供了基于注解方式来声明。

在consumer的SpringRabbitListener中添加两个消费者，同时基于注解来声明队列和交换机：

@RabbitListener(bindings = @QueueBinding(
        value = @Queue(name = "direct.queue1"),
        exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT),
        key = {
        "red", "blue"}
    ))
    public void listenDirectQueue1(String msg){
        
        System.out.println("消费者接收到direct.queue1的消息：【" + msg + "】");
    }
    
    @RabbitListener(bindings = @QueueBinding(
        value = @Queue(name = "direct.queue2"),
        exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT),
        key = {
        "red", "yellow"}
    ))
    public void listenDirectQueue2(String msg){
        
        System.out.println("消费者接收到direct.queue2的消息：【" + msg + "】");
    }

> **消息发送**

在publisher服务的SpringAmqpTest类中添加测试方法：

@Test
    public void testSendDirectExchange() {
        
        // 交换机名称
        String exchangeName = "itcast.direct";
        // 消息
        String message = "红警";
        // 发送消息
        rabbitTemplate.convertAndSend(exchangeName, "red", message);
    }

> **总结**

*描述下Direct交换机与Fanout交换机的差异？*

*  Fanout交换机将消息路由给每一个与之绑定的队列
 *  Direct交换机根据RoutingKey判断路由给哪个队列
 *  如果多个队列具有相同的RoutingKey，则与Fanout功能类似

*基于@RabbitListener注解声明队列和交换机有哪些常见注解？*

*  @Queue
 *  @Exchang

--------------------

#### 发布、订阅模型-Topic ####

`Topic`类型的`Exchange`与`Direct`相比，都是可以根据`RoutingKey`把消息路由到不同的队列。只不过`Topic`类型`Exchange`可以让队列在绑定`Routing key` 的时候使用通配符！

`Routingkey` 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： `item.insert`

通配符规则：

`#`：匹配一个或多个词

`*`：匹配不多不少恰好1个词

例如下图

![在这里插入图片描述][b84ef0f873794a05910176b11a5e7fd5.png]  
解释：

*  Queue1：绑定的是`china.#` ，因此凡是以 `china.`开头的`routing key` 都会被匹配到。包括china.news和china.weather
 *  Queue2：绑定的是`#.news` ，因此凡是以 `.news`结尾的 `routing key` 都会被匹配。包括china.news和japan.news

--------------------

代码实现思路如下：

1.  并利用@RabbitListener声明Exchange、Queue、RoutingKey
2.  在consumer服务中，编写两个消费者方法，分别监听topic.queue1和topic.queue2
3.  在publisher中编写测试方法，向itcast. topic发送消息

![在这里插入图片描述][195e3641bd874604907828b17c8e8d38.png]

> **消息接收**

在consumer服务的SpringRabbitListener中添加方法：

@RabbitListener(bindings = @QueueBinding(
        value = @Queue(name = "topic.queue1"),
        exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
        key = "china.#"
    ))
    public void listenTopicQueue1(String msg){
        
        System.out.println("消费者接收到topic.queue1的消息：【" + msg + "】");
    }
    
    @RabbitListener(bindings = @QueueBinding(
        value = @Queue(name = "topic.queue2"),
        exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
        key = "#.news"
    ))
    public void listenTopicQueue2(String msg){
        
        System.out.println("消费者接收到topic.queue2的消息：【" + msg + "】");
    }

> **消息发送**

在publisher服务的SpringAmqpTest类中添加测试方法：
    
    ```java
    /**
         * topicExchange
         */
    @Test
    public void testSendTopicExchange() {
        
        // 交换机名称
        String exchangeName = "itcast.topic";
        // 消息
        String message = "喜报！孙悟空大战哥斯拉，胜!";
        // 发送消息
        rabbitTemplate.convertAndSend(exchangeName, "china.news", message);
    }

--------------------

> **小结**

*描述下Direct交换机与Topic交换机的差异？*

*  Topic交换机接收的消息RoutingKey必须是多个单词，以 `.` 分割
 *  Topic交换机与队列绑定时的bindingKey可以指定通配符
 *  `#`：代表0个或多个词
 *  `*`：代表1个词

--------------------

#### 消息转换器 ####

Spring会把你发送的消息序列化为字节发送给MQ，接收消息的时候，还会把字节反序列化为Java对象。

只不过，默认情况下Spring采用的序列化方式是JDK序列化。众所周知，JDK序列化存在下列问题：

*  数据体积过大
 *  有安全漏洞
 *  可读性差

--------------------

> **测试默认转换器**

修改消息发送的代码，发送一个Map对象：

@Test
    public void testSendMap() throws InterruptedException {
        
        // 准备消息
        Map<String,Object> msg = new HashMap<>();
        msg.put("name", "Jack");
        msg.put("age", 21);
        // 发送消息
        rabbitTemplate.convertAndSend("simple.queue","", msg);
    }

停止consumer服务

发送消息后查看控制台：

![在这里插入图片描述][04eed0eb811f49e9b8446b65f4d40a2b.png]

--------------------

> **配置JSON转换器**

显然，JDK序列化方式并不合适。我们希望消息体的体积更小、可读性更高，因此可以使用JSON方式来做序列化和反序列化。

在publisher和consumer两个服务中都引入依赖（在父工程加入依赖即可，免得重复引用）：

<dependency>
        <groupId>com.fasterxml.jackson.dataformat</groupId>
        <artifactId>jackson-dataformat-xml</artifactId>
        <version>2.9.10</version>
    </dependency>

配置消息转换器。

在启动类中添加一个Bean即可：

@Bean
    public MessageConverter jsonMessageConverter(){
        
        return new Jackson2JsonMessageConverter();
    }

这样获取的消息就是原内容了

![在这里插入图片描述][743a7a3fb5ab488e85d839fcc6b66108.png]

--------------------

## 分布式搜索 ##

### 初识elasticsearch ###

#### ES介绍 ####

elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容  
![在这里插入图片描述][7e41369fccb64f65910fc8356b27084c.png]

**ELK技术栈**  
elasticsearch结合kibana、Logstash、Beats，也就是elastic stack（ELK）。被广泛应用在日志数据分析、实时监控等领域

而elasticsearch是elastic stack的核心，负责存储、搜索、分析数据。

--------------------

相比与lucene，elasticsearch具备下列优势：

*  支持分布式，可水平扩展
 *  提供Restful接口，可被任何语言调用

--------------------

*什么是elasticsearch？*

*  一个开源的**分布式**搜索引擎，可以用来实现搜索、日志统计、分析、系统监控等功能

*什么是elastic stack（ELK）？*

*  是以elasticsearch为核心的技术栈，包括beats、Logstash、kibana、elasticsearch

*什么是Lucene？*

*  是Apache的开源搜索引擎类库，提供了搜索引擎的核心API

--------------------

#### 倒排索引 ####

倒排索引的概念是基于MySQL这样的正向索引而言的。一般搜索引擎都会使用倒排索引，实现根据关键字来搜索

**正向索引**，就是数据库表中，根据id创建索引，如果要根据关键词搜索，就会使用模糊匹配，而模糊匹配有可能会让索引失效，如下  
![在这里插入图片描述][700741cb3cd04fc98e625b79d0a94f83.png]  
而索引失效就会进行全表扫描，在数据量很大时，那效率一言难尽。

--------------------

**倒排索引**

**创建倒排索引**是对正向索引的一种特殊处理，流程如下：

*  将每一个文档的数据利用算法分词，得到一个个词条
 *  创建表，每行数据包括词条、词条所在文档id、位置等信息
 *  因为词条唯一性，可以给词条创建索引，例如hash表结构索引  
    ![在这里插入图片描述][01bf7fd89e4c48f7ac39be18ba50c0d0.png]

--------------------

#### ES基本概念 ####

elasticsearch中有很多独有的概念，与mysql中略有差别，但也有相似之处。

**文档和字段**  
elasticsearch是面向 **文档Document**存储的，可以是数据库中的一条商品数据，一个订单信息。文档数据会被序列化为json格式后存储在elasticsearch中：  
![在这里插入图片描述][d6debee063f24df7939478d1a0c68fbf.png]  
而Json文档中往往包含很多的 **字段（Field）**，类似于数据库中的列。

**索引和映射**

**索引（Index）**，就是相同类型的文档的集合。

例如：

*  所有用户文档，就可以组织在一起，称为用户的索引；
 *  所有商品的文档，可以组织在一起，称为商品的索引；
 *  所有订单的文档，可以组织在一起，称为订单的索引；

![在这里插入图片描述][6b7b710237e54a8e86be3e0725f91c24.png]

因此，我们可以把**索引**当做是数据库中的**表**。

数据库的表会有约束信息，用来定义表的结构、字段的名称、类型等信息。因此，索引库中就有**映射（mapping）**，是索引中文档的字段约束信息，类似**表的结构约束**。

--------------------

**mysql与elasticsearch对比**

![在这里插入图片描述][63629a13640e49d385d9a9ed11ae6ade.png]

两者各自有自己的擅长支出，它们是一种**互补**的关系

*  Mysql：擅长事务类型操作，可以确保数据的安全和一致性
 *  Elasticsearch：擅长海量数据的关键词搜索、分析、计算

--------------------

使用时一般是二者结合使用

*  对安全性要求较高的写操作，使用mysql实现
 *  对查询性能要求较高的搜索需求，使用elasticsearch实现
 *  两者再基于某种方式，实现数据的同步，保证一致性  
    ![在这里插入图片描述][090217094bc947a68677cf459e27a5c3.png]

--------------------

#### 安装es、kibana ####

> **安装elasticsearch**

①安装es镜像  
把导入镜像的压缩包构建成镜像

es和kibana镜像压缩包下载：[es和kibana镜像][es_kibana]  
提取码：icnb

docker load -i es.tar

我们还需要部署kibana容器，因此需要让es和kibana容器互联。这里先创建一个网络：

docker network create es-net

②运行镜像如果docker服务没启动，先启动docker

systemctl start docker

运行docker命令，部署单点es：

docker run -d \
    	--name es \
        -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
        -e "discovery.type=single-node" \
        -v es-data:/usr/share/elasticsearch/data \
        -v es-plugins:/usr/share/elasticsearch/plugins \
        --privileged \
        --network es-net \
        -p 9200:9200 \
        -p 9300:9300 \
    elasticsearch:7.12.1

命令解释：

*  `-e "cluster.name=es-docker-cluster"`：设置集群名称
 *  `-e "http.host=0.0.0.0"`：监听的地址，可以外网访问
 *  `-e "ES_JAVA_OPTS=-Xms512m -Xmx512m"`：内存大小
 *  `-e "discovery.type=single-node"`：非集群模式
 *  `-v es-data:/usr/share/elasticsearch/data`：挂载逻辑卷，绑定es的数据目录
 *  `-v es-logs:/usr/share/elasticsearch/logs`：挂载逻辑卷，绑定es的日志目录
 *  `-v es-plugins:/usr/share/elasticsearch/plugins`：挂载逻辑卷，绑定es的插件目录
 *  `--privileged`：授予逻辑卷访问权
 *  `--network es-net` ：加入一个名为es-net的网络中
 *  `-p 9200:9200`：端口映射配置

③浏览器访问测试  
先开放防火墙的9200端口

sudo firewall-cmd --zone=public --permanent --add-port=9200/tcp
    
    firewall-cmd --reload

![在这里插入图片描述][bd455389b20345b2ac1063b0c142a5cd.png]

--------------------

> **部署kibana**

kibana可以给我们提供一个elasticsearch的可视化界面，便于我们学习。

①导入镜像压缩包，构建镜像

docker load -i kibana.tar

②运行镜像  
运行docker命令，部署kibana

docker run -d \
    --name kibana \
    -e ELASTICSEARCH_HOSTS=http://es:9200 \
    --network=es-net \
    -p 5601:5601  \
    kibana:7.12.1

*  `--network es-net` ：加入一个名为es-net的网络中，与elasticsearch在同一个网络中
 *  `-e ELASTICSEARCH_HOSTS=http://es:9200"`：设置elasticsearch的地址，因为kibana已经与elasticsearch在一个网络，因此可以用容器名直接访问elasticsearch
 *  `-p 5601:5601`：端口映射配置

kibana启动一般比较慢，需要多等待一会，可以通过命令：

docker logs -f kibana

查看运行日志，当查看到下面的日志，说明成功：

![在这里插入图片描述][8fb73d1e7456415faabb0cc2eff7d9b0.png]

③浏览器访问测试

开放端口，如果时服务器，防火墙添加开放规则

sudo firewall-cmd --zone=public --permanent --add-port=9200/tcp
    
    firewall-cmd --reload

![在这里插入图片描述][a77a6a7ec6d24af78439f22e34aab393.png]

--------------------

点击Dev tools在这个界面中可以编写DSL来操作elasticsearch。并且对DSL语句有自动补全功能。  
![在这里插入图片描述][5a6a94ef52114ff9865580ad55db5497.png]

![在这里插入图片描述][c881cedf7cd6405984ad1607da88e8a7.png]

--------------------

但是es对英文分词较好，对中文分词只能每个汉字每个汉字分，很明显不是我们想要的效果，所以下面安装ik分词器，对中问分词较为友好

**在线安装ik插件（较慢）**

# 进入容器内部
    docker exec -it elasticsearch /bin/bash
    
    # 在线下载并安装
    ./bin/elasticsearch-plugin  install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v7.12.1/elasticsearch-analysis-ik-7.12.1.zip
    
    #退出
    exit
    #重启容器
    docker restart elasticsearch

--------------------

**离线安装ik插件（推荐）**

查看数据卷目录

安装插件需要知道elasticsearch的plugins目录位置，而我们用了数据卷挂载，因此需要查看elasticsearch的数据卷目录，通过下面命令查看:

docker volume inspect es-plugins

显示结果：

[
        {
        
            "CreatedAt": "2022-05-06T10:06:34+08:00",
            "Driver": "local",
            "Labels": null,
            "Mountpoint": "/var/lib/docker/volumes/es-plugins/_data",
            "Name": "es-plugins",
            "Options": null,
            "Scope": "local"
        }
    ]

说明plugins目录被挂载到了：`/var/lib/docker/volumes/es-plugins/_data`这个目录中。  
**把ik分词器的压缩包解压到这个目录中**（压缩包下载在上面es镜像下载的链接里）

最后重启容器

docker restart es

--------------------

> **测试**

IK分词器包含两种模式：

*  `ik_smart`：最少切分(粗粒切分）
 *  `ik_max_word`：最细切分（细腻切分）

**最少切分**，废话少说，直接上图更清晰

![在这里插入图片描述][afd482ead66e407b801fd19c8d63a5e7.png]

--------------------

**最细切分**

![在这里插入图片描述][65308a9e34ff432cbb6b46875f72702e.png]

--------------------

> **扩展词典**

随着互联网的发展，“造词运动”也越发的频繁。出现了很多新的词语，在原有的词汇列表中并不存在。比如：“奥力给”，“鸡你太美” ，“瑞克顶针”等。

所以我们的词汇也需要不断的更新，IK分词器提供了扩展词汇的功能。

要拓展ik分词器的词库，只需要修改一个ik分词器目录中的config目录中的IkAnalyzer.cfg.xml文件，文件位置在ik文件夹下的config目录下  
![在这里插入图片描述][fb1e01fe78d64c5c9ba55586309fc807.png]

![在这里插入图片描述][1fb8c8192e4647ae81360a38b96f67f5.png]  
然后在IkAnalyzer.cfg.xml文件所在目录下新建一个 ext.dic，可以参考config目录下复制一个配置文件进行修改

> 注意当前文件的编码必须是 UTF-8 格式，严禁使用Windows记事本编辑（windows记事本编码格式默认gbk）

![在这里插入图片描述][ac108cd948b04fc2906bba41cd8904a8.png]  
重启elasticsearch 生效

docker restart es

效果如下  
![在这里插入图片描述][a20c031b4fb24f088b56a2917a6d5acb.png]

--------------------

> **停用词汇**

对于敏感词，这里也需要进行停用；关于宗教、政治等敏感词语，那么我们在搜索时也应该忽略当前词汇。

IK分词器也提供了强大的停用词功能，让我们在索引时就直接忽略当前的停用词汇表中的内容。  
和上面扩展同理，创建一个文件就是上面填入IkAnalyzer.cfg.xml中的stopword.dic  
在其中添加禁用敏感词

同样的步骤，就不再多写一遍了

--------------------

> **总结**

*分词器的作用是什么？*  
创建倒排索引时对文档分词  
用户搜索时，对输入的内容分词

*IK分词器有几种模式？*  
ik\_smart：智能切分，粗粒度  
ik\_max\_word：最细切分，细粒度

*IK分词器如何拓展词条？如何停用词条？*  
利用config目录的IkAnalyzer.cfg.xml文件添加拓展词典和停用词典  
在词典中添加拓展词条或者停用词条

--------------------

### 索引库操作 ###

索引库就类似数据库表，mapping映射就类似表的结构。

我们要向es中存储数据，必须先创建“库”和“表”。

#### mapping映射属性 ####

mapping是对索引库中文档的约束，常见的mapping属性包括：

*  type：字段数据类型，常见的简单类型有：
    
     *  字符串：**text**（可分词的文本）、**keyword**（精确值，例如：品牌、国家、ip地址**不需要分词的文本**）
     *  数值：long、integer、short、byte、double、float、
     *  布尔：boolean
     *  日期：date
     *  对象：object
 *  index：是否创建索引，默认为true（并非所有的都需要创建倒排索引，比如图片的url，创建倒排索引并没有用）
 *  analyzer：使用哪种分词器
 *  properties：该字段的子字段

例如下面的json文档：

{
        
        "age": 21,
        "weight": 52.1,
        "isMarried": false,
        "info": "什么是快乐星球",
        "email": "zy@itcast.cn",
        "score": [99.1, 99.5, 98.9],
        "name": {
        
            "firstName": "云",
            "lastName": "赵"
        }
    }

--------------------

对应的每个字段映射（mapping）：

*  age：类型为 integer；参与搜索，因此需要index为true；无需分词器
 *  weight：类型为float；参与搜索，因此需要index为true；无需分词器
 *  isMarried：类型为boolean；参与搜索，因此需要index为true；无需分词器
 *  info：类型为字符串，需要分词，因此是text；参与搜索，因此需要index为true；分词器可以用ik\_smart
 *  email：类型为字符串，但是不需要分词，因此是keyword；不参与搜索，因此需要index为false；无需分词器
 *  score：虽然是数组，但是我们只看元素的类型，类型为float；参与搜索，因此需要index为true；无需分词器
 *  name：类型为object，需要定义多个子属性
    
     *  name.firstName；类型为字符串，但是不需要分词，因此是keyword；参与搜索，因此需要index为true；无需分词器
     *  name.lastName；类型为字符串，但是不需要分词，因此是keyword；参与搜索，因此需要index为true；无需分词器

--------------------

> **小结**

*mapping常见**属性**有哪些？*  
type：数据类型  
index：是否索引  
analyzer：分词器  
properties：子字段

*type常见的**类型**有哪些？*  
字符串：text、keyword  
数字：long、integer、short、byte、double、float  
布尔：boolean  
日期：date  
对象：object

--------------------

#### 索引库的CRUD ####

统一使用Kibana编写DSL的方式来演示

##### 创建索引库和映射 #####

以下面的代码为例，创建索引库的基本模板

PUT /test
    {
        
      "mappings": {
        
        "properties": {
        
          "info":{
        
            "type": "text",
            "analyzer": "ik_smart"
          },
          "email":{
        
            "type": "keyword",
            "index": false
          },
          "name":{
        
            "properties": {
        
              "firstName":{
        
                "type": "keyword"
              },
              "lastName":{
        
                "type": "keyword"
              }
            }
          }
        }
      }
    }

--------------------

##### 查询和删除索引库 #####

GET /索引库名

![在这里插入图片描述][ac25d824e6a74c81973bb75938d6420e.png]

--------------------

DELETE /索引库名

![在这里插入图片描述][445f386eca414b2097f45eb1570afdb7.png]

--------------------

##### 修改索引库 #####

倒排索引结构虽然不复杂，但是一旦数据结构改变（比如改变了分词器），就需要重新创建倒排索引，这简直是灾难。因此索引库**一旦创建，无法修改mapping**。

虽然无法修改mapping中已有的字段，但是却允许添加新的字段到mapping中，因为不会对倒排索引产生影响。  
如下示例

PUT /索引库名/_mapping
    {
        
      "properties": {
        
        "新字段名":{
        
          "type": "integer"
        }
      }
    }

![在这里插入图片描述][70daa89ea5f042c3a27be58a5ebc1d5c.png]

--------------------

> **小结**

*文档操作有哪些？*

创建文档：POST /索引库名/\_doc/文档id \{ json文档 \}  
查询文档：GET /索引库名/\_doc/文档id  
删除文档：DELETE /索引库名/\_doc/文档id

修改文档：

*  全量修改：PUT /索引库名/\_doc/文档id \{ json文档 \}
 *  增量修改：POST /索引库名/\_update/文档id \{ “doc”: \{字段\}\}

--------------------

### 文档操作 ###

#### 新增文档 ####

语法如下

POST /索引库名/_doc/文档id
    {
        
        "字段1": "值1",
        "字段2": "值2",
        "字段3": {
        
            "子属性1": "值3",
            "子属性2": "值4"
        },
        // ...
    }

下面来个具体实现来看

![在这里插入图片描述][3cf9a7cfedbc45dcb0546bf198a46362.png]

--------------------

#### 查询和删除文档 ####

> **查询文档**

根据rest风格，新增是post，查询应该是get，不过查询一般都需要条件，这里我们把文档id带上。  
文档也就是es中的一条数据，是JSON格式的（类似数据库中的row，一行数据）

**语法：**

GET /{
        索引库名称}/_doc/{
        id}

**通过kibana查看数据：**

GET /test/_doc/1

**查看结果：**

![在这里插入图片描述][29f1f7a63ec64a99a9f231463b9feb7d.png]

--------------------

> **删除文档**

删除使用DELETE请求，同样，需要根据id进行删除：

**语法：**

DELETE /{
        索引库名}/_doc/id值

**示例：**

# 根据id删除数据
    DELETE /test/_doc/1

--------------------

#### 修改文档 ####

修改有两种方式：

*  全量修改：直接**覆盖**原来的文档
 *  增量修改：修改文档中的**部分字段**

> **全量修改**

全量修改是覆盖原来的文档，其本质是：

*  根据指定的id删除文档
 *  新增一个相同id的文档

**注意**：如果根据id删除时，id不存在，第二步的新增也会执行，也就从修改变成了新增操作了。

**语法：**

PUT /{
        索引库名}/_doc/文档id
    {
        
        "字段1": "值1",
        "字段2": "值2",
        // ... 略
    }

**示例：**

PUT /heima/_doc/1
    {
        
        "info": "什么是快乐星球",
        "email": "10086@qq.com",
        "name": {
        
            "firstName": "云",
            "lastName": "赵"
        }
    }

--------------------

> **增量修改**

增量修改是只修改指定id匹配的文档中的部分字段。

**语法：**

POST /{
        索引库名}/_update/文档id
    {
        
        "doc": {
        
             "字段名": "新的值",
        }
    }

**示例：**

POST /test/_update/1
    {
        
      "doc": {
        
        "email": "123456@qq.com"
      }
    }

--------------------

#### 小结 ####

*文档操作有哪些？*

*  创建文档：POST /\{索引库名\}/\_doc/文档id \{ json文档 \}
 *  查询文档：GET /\{索引库名\}/\_doc/文档id
 *  删除文档：DELETE /\{索引库名\}/\_doc/文档id
 *  修改文档：
    
     *  全量修改：PUT /\{索引库名\}/\_doc/文档id \{ json文档 \}
     *  增量修改：POST /\{索引库名\}/\_update/文档id \{ “doc”: \{字段\}\}

--------------------

### RestAPI ###

ES官方提供了各种不同语言的客户端，用来操作ES。这些客户端的本质就是组装DSL语句，通过http请求发送给ES。官方文档地址：https://www.elastic.co/guide/en/elasticsearch/client/index.html

其中的Java Rest Client又包括两种：

*  Java Low Level Rest Client
 *  Java High Level Rest Client

一般Java HighLevel Rest Client客户端使用的更多，也是学习Java HighLevel Rest Client客户端的API

--------------------

#### 快速入门 ####

下面来一个demo案例，清晰明了

1.在数据库中导入sql文件，创建hotel相关表数据

![在这里插入图片描述][cffe9c4104d243d08764d5d11ec90365.png]

数据结构如下：

CREATE TABLE `tb_hotel` (
      `id` bigint(20) NOT NULL COMMENT '酒店id',
      `name` varchar(255) NOT NULL COMMENT '酒店名称；例：7天酒店',
      `address` varchar(255) NOT NULL COMMENT '酒店地址；例：航头路',
      `price` int(10) NOT NULL COMMENT '酒店价格；例：329',
      `score` int(2) NOT NULL COMMENT '酒店评分；例：45，就是4.5分',
      `brand` varchar(32) NOT NULL COMMENT '酒店品牌；例：如家',
      `city` varchar(32) NOT NULL COMMENT '所在城市；例：上海',
      `star_name` varchar(16) DEFAULT NULL COMMENT '酒店星级，从低到高分别是：1星到5星，1钻到5钻',
      `business` varchar(255) DEFAULT NULL COMMENT '商圈；例：虹桥',
      `latitude` varchar(32) NOT NULL COMMENT '纬度；例：31.2497',
      `longitude` varchar(32) NOT NULL COMMENT '经度；例：120.3925',
      `pic` varchar(255) DEFAULT NULL COMMENT '酒店图片；例:/img/1.jpg',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

--------------------

2.项目工程搭建

![在这里插入图片描述][5450d060937a42c18e6b1b8985ecff0b.png]

--------------------

3.mapping映射分析

创建索引库（就是创建表），最关键的是mapping映射（表约束），而mapping映射要考虑的信息包括：

*  字段名
 *  字段数据类型
 *  是否参与搜索
 *  是否需要分词
 *  如果分词，分词器是什么？

其中：

*  字段名、字段数据类型，可以参考数据表结构的名称和类型
 *  是否参与搜索要分析业务来判断，例如图片地址，就无需参与搜索
 *  是否分词呢要看内容，内容如果是一个整体就无需分词，反之则要分词
 *  分词器，我们可以统一使用ik\_max\_word

来看下酒店数据的索引库结构:

PUT /hotel
    {
        
      "mappings": {
        
        "properties": {
        
          "id": {
        
            "type": "keyword"
          },
          "name":{
        
            "type": "text",
            "analyzer": "ik_max_word",
            "copy_to": "all"
          },
          "address":{
        
            "type": "keyword",
            "index": false
          },
          "price":{
        
            "type": "integer"
          },
          "score":{
        
            "type": "integer"
          },
          "brand":{
        
            "type": "keyword",
            "copy_to": "all"
          },
          "city":{
        
            "type": "keyword",
            "copy_to": "all"
          },
          "starName":{
        
            "type": "keyword"
          },
          "business":{
        
            "type": "keyword"
          },
          "location":{
        
            "type": "geo_point"
          },
          "pic":{
        
            "type": "keyword",
            "index": false
          },
          "all":{
        
            "type": "text",
            "analyzer": "ik_max_word"
          }
        }
      }
    }

几个特殊字段说明：

*  location：地理坐标，里面包含精度、纬度
 *  all：一个组合字段，其目的是将多字段的值 利用copy\_to合并，提供给用户搜索

地理坐标说明：

![在这里插入图片描述][747f9a552d9f4256bb02be0a9bbc8ca3.png]

copy\_to说明：  
![在这里插入图片描述][a5c4353ad4c645f39dfb129aba9662ab.png]

--------------------

4.初始化RestClient  
在elasticsearch提供的API中，与elasticsearch一切交互都封装在一个名为RestHighLevelClient的类中，必须先完成这个对象的初始化，建立与elasticsearch的连接。

分为三步：

1）引入es的RestHighLevelClient依赖：

<dependency>
        <groupId>org.elasticsearch.client</groupId>
        <artifactId>elasticsearch-rest-high-level-client</artifactId>
    </dependency>

2）因为SpringBoot默认的ES版本是7.6.2，所以我们需要覆盖默认的ES版本：

3）初始化RestHighLevelClient：

初始化的代码如下：

RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(
            HttpHost.create("http://ip:9200")
    ));

--------------------

为了单元测试方便，我们创建一个测试类HotelIndexTest，然后将初始化的代码编写在@BeforeEach方法中：

@BeforeEach
        void setUp() {
        
            this.client = new RestHighLevelClient(RestClient.builder(
                    HttpHost.create("http://ip:9200")
            ));
        }
    
        @AfterEach
        void tearDown() throws IOException {
        
            this.client.close();
        }

--------------------

#### 操作索引库 ####

> **创建索引库**

![在这里插入图片描述][a22e852f31ec4c51a3f51f5db8cba9bf.png]

代码分为三步：

*  1）创建Request对象。因为是创建索引库的操作，因此Request是CreateIndexRequest。
 *  2）添加请求参数，其实就是DSL的JSON参数部分。因为json字符串很长，这里是定义了静态字符串常量MAPPING\_TEMPLATE，让代码看起来更加优雅。
 *  3）发送请求，client.indices()方法的返回值是IndicesClient类型，封装了所有与索引库操作有关的方法。

--------------------

在hotel-demo的cn.hotel.constants包下，创建一个类，定义mapping映射的JSON字符串常量：  
就是建立索引库的JSON语句，如下

public class HotelConstants {
        
        public static final String MAPPING_TEMPLATE = "{\n" +
                "  \"mappings\": {\n" +
                "    \"properties\": {\n" +
                "      \"id\": {\n" +
                "        \"type\": \"keyword\"\n" +
                "      },\n" +
                "      \"name\":{\n" +
                "        \"type\": \"text\",\n" +
                "        \"analyzer\": \"ik_max_word\",\n" +
                "        \"copy_to\": \"all\"\n" +
                "      },\n" +
                "      \"address\":{\n" +
                "        \"type\": \"keyword\",\n" +
                "        \"index\": false\n" +
                "      },\n" +
                "      \"price\":{\n" +
                "        \"type\": \"integer\"\n" +
                "      },\n" +
                "      \"score\":{\n" +
                "        \"type\": \"integer\"\n" +
                "      },\n" +
                "      \"brand\":{\n" +
                "        \"type\": \"keyword\",\n" +
                "        \"copy_to\": \"all\"\n" +
                "      },\n" +
                "      \"city\":{\n" +
                "        \"type\": \"keyword\",\n" +
                "        \"copy_to\": \"all\"\n" +
                "      },\n" +
                "      \"starName\":{\n" +
                "        \"type\": \"keyword\"\n" +
                "      },\n" +
                "      \"business\":{\n" +
                "        \"type\": \"keyword\"\n" +
                "      },\n" +
                "      \"location\":{\n" +
                "        \"type\": \"geo_point\"\n" +
                "      },\n" +
                "      \"pic\":{\n" +
                "        \"type\": \"keyword\",\n" +
                "        \"index\": false\n" +
                "      },\n" +
                "      \"all\":{\n" +
                "        \"type\": \"text\",\n" +
                "        \"analyzer\": \"ik_max_word\"\n" +
                "      }\n" +
                "    }\n" +
                "  }\n" +
                "}";
    }

在hotel-demo中的HotelIndexTest测试类中，编写单元测试，实现创建索引：

@Test
    void createHotelIndex() throws IOException {
        
        // 1.创建Request对象
        CreateIndexRequest request = new CreateIndexRequest("hotel");
        // 2.准备请求的参数：DSL语句
        request.source(MAPPING_TEMPLATE, XContentType.JSON);
        // 3.发送请求
        client.indices().create(request, RequestOptions.DEFAULT);
    }

--------------------

> **删除索引库**

删除索引库的DSL语句非常简单：

DELETE /hotel

与创建索引库相比：

*  请求方式从PUT变为DELTE
 *  请求路径不变
 *  无请求参数

所以代码的差异，注意体现在Request对象上。依然是三步走：

*  1）创建Request对象。这次是DeleteIndexRequest对象
 *  2）准备参数。这里是无参
 *  3）发送请求。改用delete方法

在hotel-demo中的HotelIndexTest测试类中，编写单元测试，实现删除索引：

@Test
    void testDeleteHotelIndex() throws IOException {
        
        // 1.创建Request对象
        DeleteIndexRequest request = new DeleteIndexRequest("hotel");
        // 2.发送请求
        client.indices().delete(request, RequestOptions.DEFAULT);
    }

--------------------

> **判断索引库是否存在**

判断索引库是否存在，本质就是查询，对应的DSL是：

GET /hotel

因此与删除的Java代码流程是类似的。依然是三步走：

*  1）创建Request对象。这次是GetIndexRequest对象
 *  2）准备参数。这里是无参
 *  3）发送请求。改用exists方法

@Test
    void testExistsHotelIndex() throws IOException {
        
        // 1.创建Request对象
        GetIndexRequest request = new GetIndexRequest("hotel");
        // 2.发送请求
        boolean exists = client.indices().exists(request, RequestOptions.DEFAULT);
        // 3.输出
        System.err.println(exists ? "索引库已经存在！" : "索引库不存在！");
    }

--------------------

**总结**

JavaRestClient操作elasticsearch的流程基本类似。核心是client.indices()方法来获取索引库的操作对象。

索引库操作的基本步骤：

*  初始化RestHighLevelClient
 *  创建XxxIndexRequest。XXX是Create、Get、Delete
 *  准备DSL（ Create时需要，其它是无参）
 *  发送请求。调用RestHighLevelClient\#indices().xxx()方法，xxx是create、exists、delete

--------------------

#### 操作文档 ####

> **新增文档**

就相当于数据库表中插入一条数据，只不过是插入到索引库中

新增文档的DSL语句如下：

POST /{
        索引库名}/_doc/1
    {
        
        "name": "Jack",
        "age": 21
    }

对应的java代码如图：

![在这里插入图片描述][4bfca5be58a14f8d92e6d335a6dc4a0f.png]  
可以看到与**创建索引库**类似，同样是三步走：

*  1）创建Request对象
 *  2）准备请求参数，也就是DSL中的JSON文档
 *  3）发送请求

变化的地方在于，这里直接使用client.xxx()的API，不再需要client.indices()了。

--------------------

数据库查询后的结果是一个Hotel类型的对象，和索引库中的字段（比如经纬度longitude和latitude需要合并为location）不太一致，这里就需要定义一个新的类型，与索引库结构吻合：

@Data
    @NoArgsConstructor
    public class HotelDoc {
        
        private Long id;
        private String name;
        private String address;
        private Integer price;
        private Integer score;
        private String brand;
        private String city;
        private String starName;
        private String business;
        private String location;
        private String pic;
    
        public HotelDoc(Hotel hotel) {
        
            this.id = hotel.getId();
            this.name = hotel.getName();
            this.address = hotel.getAddress();
            this.price = hotel.getPrice();
            this.score = hotel.getScore();
            this.brand = hotel.getBrand();
            this.city = hotel.getCity();
            this.starName = hotel.getStarName();
            this.business = hotel.getBusiness();
            this.location = hotel.getLatitude() + ", " + hotel.getLongitude();
            this.pic = hotel.getPic();
        }
    }

**要把数据库中的hotel对象插入到索引库中，有以下三点需要注意**

*  酒店数据来自于数据库，我们需要先查询出来，得到hotel对象
 *  hotel对象需要转为HotelDoc对象
 *  HotelDoc需要序列化为json格式

代码整体步骤如下：

*  1）根据id查询酒店数据Hotel
 *  2）将Hotel封装为HotelDoc
 *  3）将HotelDoc序列化为JSON
 *  4）创建IndexRequest，指定索引库名和id
 *  5）准备请求参数，也就是JSON文档
 *  6）发送请求

@Test
    void testAddDocument() throws IOException {
        
        // 1.根据id查询酒店数据
        Hotel hotel = hotelService.getById(61083L);
        // 2.转换为文档类型
        HotelDoc hotelDoc = new HotelDoc(hotel);
        // 3.将HotelDoc转json
        String json = JSON.toJSONString(hotelDoc);
    
        // 1.准备Request对象
        IndexRequest request = new IndexRequest("hotel").id(hotelDoc.getId().toString());
        // 2.准备Json文档
        request.source(json, XContentType.JSON);
        // 3.发送请求
        client.index(request, RequestOptions.DEFAULT);
    }

![在这里插入图片描述][6e342612606f40a4bdabb8c3094963cb.png]

--------------------

> **查询文档**

查询的DSL语句如下：

GET /hotel/_doc/{
        id}

非常简单，因此代码大概分两步：

*  准备Request对象
 *  发送请求

不过查询的目的是得到结果，解析为HotelDoc，因此难点是结果的解析。完整代码如下：

![在这里插入图片描述][1b7baf1eeb0d4a64a884ca3ea1a50625.png]  
可以看到，结果是一个JSON，其中文档放在一个`_source`属性中，因此解析就是拿到`_source`，反序列化为Java对象即可。

与之前类似，也是三步走：

*  1）准备Request对象。这次是查询，所以是GetRequest
 *  2）发送请求，得到结果。因为是查询，这里调用client.get()方法
 *  3）解析结果，就是对JSON做反序列化

@Test
    void testGetDocumentById() throws IOException {
        
        // 1.准备Request
        GetRequest request = new GetRequest("hotel", "61083");
        // 2.发送请求，得到响应
        GetResponse response = client.get(request, RequestOptions.DEFAULT);
        // 3.解析响应结果
        String json = response.getSourceAsString();
    
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
        System.out.println(hotelDoc);
    }

![在这里插入图片描述][40de55bd86d643e182208053b49127a9.png]

--------------------

> **删除文档**

删除的DSL为是这样的：

DELETE /hotel/_doc/{
        id}

与查询相比，仅仅是请求方式从DELETE变成GET，可以想象Java代码应该依然是三步走：

*  1）准备Request对象，因为是删除，这次是DeleteRequest对象。要指定索引库名和id
 *  2）准备参数，无参
 *  3）发送请求。因为是删除，所以是client.delete()方法

在hotel-demo的HotelDocumentTest测试类中，编写单元测试：

@Test
    void testDeleteDocument() throws IOException {
        
        // 1.准备Request
        DeleteRequest request = new DeleteRequest("hotel", "61083");
        // 2.发送请求
        client.delete(request, RequestOptions.DEFAULT);
    }

![在这里插入图片描述][7d12963db2c94e8f9cd58b514a60377d.png]

--------------------

> **修改文档**

文档修改有两种方式：

*  全量修改：本质是先根据id删除，再新增
 *  增量修改：修改文档中的指定字段值

在RestClient的API中，全量修改与新增的API完全一致，判断依据是ID：

*  如果新增时，ID已经存在，则修改
 *  如果新增时，ID不存在，则新增

主要关注增量修改，因为全量修改就是新增覆盖和新增文档一致  
代码示例如图：

![在这里插入图片描述][42c10ee2581f4ac381f8f3dee731bf9f.png]  
与之前类似，也是三步走：

*  1）准备Request对象。这次是修改，所以是UpdateRequest
 *  2）准备参数。也就是JSON文档，里面包含要修改的字段
 *  3）更新文档。这里调用client.update()方法

@Test
    void testUpdateDocument() throws IOException {
        
        // 1.准备Request
        UpdateRequest request = new UpdateRequest("hotel", "61083");
        // 2.准备请求参数
        request.doc(
            "price", "952",
            "starName", "四钻"
        );
        // 3.发送请求
        client.update(request, RequestOptions.DEFAULT);
    }

把要修改的参数和值写在doc中，其间都是逗号隔开

结果如下![在这里插入图片描述][656ea1f75dc14b0d92d0bd58c4029f48.png]

--------------------

> **批量导入文档**

案例需求：利用BulkRequest批量将数据库数据导入到索引库中。

步骤如下：

*  利用mybatis-plus查询酒店数据
 *  将查询到的酒店数据（Hotel）转换为文档类型数据（HotelDoc）
 *  利用JavaRestClient中的BulkRequest批处理，实现批量新增文档

批量处理BulkRequest，其本质就是将多个普通的CRUD请求组合在一起发送。

其中提供了一个add方法，用来添加其他请求：

![在这里插入图片描述][7ff975aaf4b34183bb65a4af02b15376.png]  
可以看到，能添加的请求包括：

*  IndexRequest，也就是新增
 *  UpdateRequest，也就是修改
 *  DeleteRequest，也就是删除

因此Bulk中添加了多个IndexRequest，就是批量新增功能了。示例：  
![在这里插入图片描述][b4fc546b4b0c4c1a912b62442cf4e093.png]  
其实还是三步走：

*  1）创建Request对象。这里是BulkRequest
 *  2）准备参数。批处理的参数，就是其它Request对象，这里就是多个IndexRequest
 *  3）发起请求。这里是批处理，调用的方法为client.bulk()方法

在导入酒店数据时，将上述代码改造成for循环处理即可。

@Test
    void testBulkRequest() throws IOException {
        
        // 批量查询酒店数据
        List<Hotel> hotels = hotelService.list();
    
        // 1.创建Request
        BulkRequest request = new BulkRequest();
        // 2.准备参数，添加多个新增的Request
        for (Hotel hotel : hotels) {
        
            // 2.1.转换为文档类型HotelDoc
            HotelDoc hotelDoc = new HotelDoc(hotel);
            // 2.2.创建新增文档的Request对象
            request.add(new IndexRequest("hotel")
                        .id(hotelDoc.getId().toString())
                        .source(JSON.toJSONString(hotelDoc), XContentType.JSON));
        }
        // 3.发送请求
        client.bulk(request, RequestOptions.DEFAULT);
    }

然后es开发工具 批量查询 验证效果

GET /索引库名/_search

![在这里插入图片描述][4988cc4d12ad49d0b7e5023e69a43eed.png]

--------------------

**小结：**  
文档操作的基本步骤：

*  初始化RestHighLevelClient
 *  创建XxxRequest。XXX是Index、Get、Update、Delete、Bulk
 *  准备参数（Index、Update、Bulk时需要）
 *  发送请求。调用RestHighLevelClient\#.xxx()方法，xxx是index、get、update、delete、bulk
 *  解析结果（Get时需要）

--------------------

### elasticsearch搜索功能 ###

#### DSL查询文档 ####

elasticsearch的查询依然是基于JSON风格的DSL来实现的。  
（DSL类似于数据库的DQL查询语句）

--------------------

##### DSL查询分类 #####

Elasticsearch提供了基于JSON的DSL（[Domain Specific Language][]）来定义查询。常见的查询类型包括：

*  **查询所有**：查询出所有数据，一般测试用。例如：match\_all
 *  **全文检索（full text）查询**：利用分词器对用户输入内容分词，然后去倒排索引库中匹配。例如：
    
     *  match\_query
     *  multi\_match\_query
 *  **精确查询**：根据精确词条值查找数据，一般是查找keyword、数值、日期、boolean等类型字段。例如：
    
     *  ids
     *  range
     *  term
 *  **地理（geo）查询**：根据经纬度查询。例如：
    
     *  geo\_distance
     *  geo\_bounding\_box
 *  **复合（compound）查询**：复合查询可以将上述各种查询条件组合起来，合并查询条件。例如：
    
     *  bool
     *  function\_score

--------------------

##### 查询所有 #####

查询的语法基本一致：

GET /indexName/_search
    {
        
      "query": {
        
        "查询类型": {
        
          "查询条件": "条件值"
        }
      }
    }

我们以查询所有为例，其中：

*  查询类型为match\_all
 *  没有查询条件

// 查询所有
    GET /indexName/_search
    {
        
      "query": {
        
        "match_all": {
        
        }
      }
    }

其它查询无非就是**查询类型**、**查询条件**的变化。

![在这里插入图片描述][54a7cefc384c488a80661a9d59de83f5.png]

--------------------

##### 全文检索查询 #####

**使用场景：**  
全文检索查询的基本流程如下：

*  对用户搜索的内容做分词，得到词条
 *  根据词条去倒排索引库中匹配，得到文档id
 *  根据文档id找到文档，返回给用户

就是搜索时，根据**关键词**返回搜索结果  
因为是拿着词条去匹配，因此参与搜索的字段也必须是可分词的text类型的字段。

**基本语法**

常见的全文检索查询包括：

*  match查询：单字段查询
 *  multi\_match查询：多字段查询，任意一个字段符合条件就算符合查询条件

**match查询语法如下：**

GET /indexName/_search
    {
        
      "query": {
        
        "match": {
        
          "FIELD": "TEXT"
        }
      }
    }

![在这里插入图片描述][69cc7dee90ee449a8e6e34b9c8fd43e2.png]

--------------------

**mulit\_match语法如下：**

GET /indexName/_search
    {
        
      "query": {
        
        "multi_match": {
        
          "query": "TEXT",
          "fields": ["FIELD1", " FIELD12"]
        }
      }
    }

![在这里插入图片描述][7881daf617ca4ced8767bda18e020bae.png]

可以看到，两种查询结果是一样的，为什么？

因为我们将brand、name、business值都**利用copy\_to复制到了all字段中**。因此可以根据三个字段搜索，和根据all字段搜索效果当然一样了。

但是，搜索字段越多，对查询性能影响越大，因此建议采用copy\_to，然后单字段查询的方式。

![在这里插入图片描述][ec4eaac3179841c7a871bb73b190c943.png]  
***match和multi\_match的区别***

*  match：根据一个字段查询
 *  multi\_match：根据多个字段查询，参与查询字段越多，查询性能越差

--------------------

##### 精准查询 #####

精确查询一般是查找keyword、数值、日期、boolean等类型字段。所以**不会**对搜索条件**分词**。常见的有：

*  term：根据词条精确值查询
 *  range：根据值的范围查询

> **term查询**

因为精确查询的字段搜是不分词的字段，因此查询的条件也必须是**不分词**的词条。查询时，用户输入的内容跟自动值**完全匹配**时才认为符合条件。如果用户输入的内容过多，反而搜索不到数据。

语法说明：

// term查询
    GET /indexName/_search
    {
        
      "query": {
        
        "term": {
        
          "FIELD": {
        
            "value": "VALUE"
          }
        }
      }
    }

如下实例  
![在这里插入图片描述][502c724da054457fbd2f79f703105cb7.png]但是，当我们搜索的内容不是词条，而是多个词语形成的短语时，反而搜索不到：

![在这里插入图片描述][ec23814ca6ed4cb5a4708dec4afd49cb.png]

--------------------

> **range查询**

范围查询，一般应用在对数值类型做范围过滤的时候。比如做价格范围过滤。

基本语法：

// range查询
    GET /indexName/_search
    {
        
      "query": {
        
        "range": {
        
          "FIELD": {
        
            "gte": 10, // 这里的gte代表大于等于，gt则代表大于
            "lte": 20 // lte代表小于等于，lt则代表小于
          }
        }
      }
    }

![在这里插入图片描述][c477aa9c74c44fd7aaf76f2795691b12.png]

--------------------

> **总结**

精确查询常见的有哪些？

*  term查询：根据词条精确匹配，一般搜索keyword类型、数值类型、布尔类型、日期类型字段
 *  range查询：根据数值范围查询，可以是数值、日期的范围

--------------------

##### 地理坐标查询 #####

所谓的地理坐标查询，其实就是根据经纬度查询，官方文档：[https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html][https_www.elastic.co_guide_en_elasticsearch_reference_current_geo-queries.html]

常见的使用场景包括：

*  携程：搜索我附近的酒店
 *  滴滴：搜索我附近的出租车
 *  微信：搜索我附近的人

--------------------

> **矩形范围查询**

矩形范围查询，也就是geo\_bounding\_box查询，查询坐标落在某个矩形范围的所有文档：

![在这里插入图片描述][4fbf09582cc24dd3b40bf731371ecc12.gif_pic_center]

询时，需要指定矩形的**左上**、**右下**两个点的坐标，然后画出一个矩形，落在该矩形内的都是符合条件的点。

语法如下：

// geo_bounding_box查询
    GET /indexName/_search
    {
        
      "query": {
        
        "geo_bounding_box": {
        
          "FIELD": {
        
            "top_left": {
         // 左上点
              "lat": 31.1,
              "lon": 121.5
            },
            "bottom_right": {
         // 右下点
              "lat": 30.9,
              "lon": 121.7
            }
          }
        }
      }
    }

**但这种并不符合“附近的人”这样的需求，且用之甚少，不过多解析**

--------------------

> **附近查询**

附近查询，也叫做距离查询（geo\_distance）：查询到指定中心点小于某个距离值的所有文档。

换句话来说，在地图上找一个点作为圆心，以指定距离为半径，画一个圆，落在圆内的坐标都算符合条件：  
![在这里插入图片描述][c29355e0767e4790a3d2970385af02bf.gif_pic_center]

// geo_distance 查询
    GET /indexName/_search
    {
        
      "query": {
        
        "geo_distance": {
        
          "distance": "15km", // 半径
          "FIELD": "31.21,121.5" // 圆心
        }
      }
    }

**示例**  
我们搜索以陆家嘴坐标为圆心，附近15km的酒店：

![在这里插入图片描述][e231827b137f4e119322660f018f3135.png]  
发现共有47家酒店。

--------------------

##### 复合查询 #####

复合（compound）查询：复合查询可以将其它简单查询组合起来，实现更复杂的搜索逻辑。常见的有两种：

*  fuction score：算分函数查询，可以控制文档相关性算分，**控制文档排名**
 *  bool query：布尔查询，利用逻辑关系**组合**多个其它的查询，实现复杂搜索

--------------------

> **相关性算分**

当我们利用match查询时，文档结果会根据与搜索词条的关联度打分（\_score），返回结果时**按照分值降序排列**。

![在这里插入图片描述][03fdaa3b8b1341cab7020b1ba006f729.png]

--------------------

TF-IDF算法有一各缺陷，就是词条频率越高，文档得分也会越高，单个词条对文档影响较大。而BM25则会让单个词条的算分有一个上限，曲线更加平滑：  
![在这里插入图片描述][c98046886b054e4bb428a1f3379b7d56.png]

**在后来的5.1版本升级中，elasticsearch将算法改进为BM25算法**

--------------------

> **算分函数查询**

根据相关度打分是比较合理的需求，但**合理的不一定是产品经理需要**的。

以百度为例，你搜索的结果中，并不是相关度越高排名越靠前，而是谁掏的钱多排名就越靠前。如图：  
![在这里插入图片描述][ed40df44198842b3959806f4c42e2a8b.png]

**语法说明**

![在这里插入图片描述][8e4feedad554456f81dea8efcc0e1742.png]

function score 查询中包含四部分内容：

*  **原始查询**条件：query部分，基于这个条件搜索文档，并且基于BM25算法给文档打分，**原始算分**（query score)
 *  **过滤条件**：filter部分，符合该条件的文档才会重新算分
 *  **算分函数**：符合filter条件的文档要根据这个函数做运算，得到的**函数算分**（function score），有四种函数
    
     *  weight：函数结果是常量
     *  field\_value\_factor：以文档中的某个字段值作为函数结果
     *  random\_score：以随机数作为函数结果
     *  script\_score：自定义算分函数算法
 *  **运算模式**：算分函数的结果、原始查询的相关性算分，两者之间的运算方式，包括：
    
     *  multiply：相乘
     *  replace：用function score替换query score
     *  其它，例如：sum、avg、max、min

--------------------

function score的运行流程如下：

*  1）根据**原始条件**查询搜索文档，并且计算相关性算分，称为**原始算分**（query score）
 *  2）根据**过滤条件**，过滤文档
 *  3）符合**过滤条件**的文档，基于**算分函数**运算，得到**函数算分**（function score）
 *  4）将**原始算分**（query score）和**函数算分**（function score）基于**运算模式**做运算，得到最终结果，作为相关性算分。

其中的关键点是：

*  过滤条件：决定哪些文档的算分被修改
 *  算分函数：决定函数算分的算法
 *  运算模式：决定最终算分结果

--------------------

> **示例**

需求：给“如家”这个品牌的酒店排名靠前一些

翻译一下这个需求，转换为之前说的四个要点：

*  原始条件：不确定，可以任意变化
 *  过滤条件：brand = “如家”
 *  算分函数：可以简单粗暴，直接给固定的算分结果，weight
 *  运算模式：比如求和

因此最终的DSL语句如下：

GET /hotel/_search
    {
        
      "query": {
        
        "function_score": {
        
          "query": {
          .... }, // 原始查询，可以是任意条件
          "functions": [ // 算分函数
            {
        
              "filter": {
         // 满足的条件，品牌必须是如家
                "term": {
        
                  "brand": "如家"
                }
              },
              "weight": 2 // 算分权重为2
            }
          ],
          "boost_mode": "sum" // 加权模式，求和
        }
      }
    }

测试，在未添加算分函数时，如家得分如下：  
![在这里插入图片描述][8e8c2bde99cc4230b1d1bff9e5f2bcee.png]  
添加了算分函数后，如家得分就提升了：

![在这里插入图片描述][32416e5bce364271bdea064f28f1b6fe.png]

> **小结**

*  过滤条件：哪些文档要加分
 *  算分函数：如何计算function score
 *  加权方式：function score 与 query score如何运算

--------------------

##### 布尔查询 #####

布尔查询是一个或多个查询子句的组合，每一个子句就是一个**子查询**。子查询的组合方式有：

*  must：必须匹配每个子查询，类似“与”
 *  should：选择性匹配子查询，类似“或”
 *  must\_not：必须不匹配，**不参与算分**，类似“非”
 *  filter：必须匹配，**不参与算分**

比如在搜索酒店时，除了关键字搜索外，我们还可能根据品牌、价格、城市等字段做过滤，这时就需要组合查询了：  
每一个不同的字段，其查询的条件、方式都不一样，必须是多个不同的查询，而要组合这些查询，就必须用bool查询了。  
需要注意的是，搜索时，参与**打分的字段越多，查询的性能也越差**。因此这种多条件查询时，建议这样做：

*  搜索框的关键字搜索，是全文检索查询，使用must查询，参与算分
 *  其它过滤条件，采用filter查询。不参与算分

**语法说明**  
查询城市是上海，品牌是皇冠假日或华美达；价格大于500，评分大于等于4.5分的酒店

GET /hotel/_search
    {
        
      "query": {
        
        "bool": {
        
          "must": [
            {
        "term": {
        "city": "上海" }}
          ],
          "should": [
            {
        "term": {
        "brand": "皇冠假日" }},
            {
        "term": {
        "brand": "华美达" }}
          ],
          "must_not": [
            {
         "range": {
         "price": {
         "lte": 500 } }}
          ],
          "filter": [
            {
         "range": {
        "score": {
         "gte": 45 } }}
          ]
        }
      }
    }

***范例***  
需求：搜索名字包含“如家”，价格不高于400，在坐标31.21,121.5周围10km范围内的酒店。

分析：

*  名称搜索，属于全文检索查询，应该参与算分。放到must中
 *  价格不高于400，用range查询，属于过滤条件，不参与算分。放到must\_not中
 *  周围10km范围内，用geo\_distance查询，属于过滤条件，不参与算分。放到filter中

![在这里插入图片描述][7e2ffb79933242438ef17ffa9c4378b5.png]

--------------------

> **小结**

*bool查询有几种逻辑关系？*

*  must：必须匹配的条件，可以理解为“与”
 *  should：选择性匹配的条件，可以理解为“或”
 *  must\_not：必须不匹配的条件，不参与打分
 *  filter：必须匹配的条件，不参与打分

--------------------

#### 搜索结果处理 ####

##### 排序 #####

elasticsearch默认是根据相关度算分（\_score）来排序，但是也支持自定义方式对搜索[结果排序][Link 3]。可以排序字段类型有：keyword类型、数值类型、地理坐标类型、日期类型等。

> **普通字段排序**

keyword、数值、日期类型排序的语法基本一致。

**语法**：

GET /indexName/_search
    {
        
      "query": {
        
        "match_all": {
        }
      },
      "sort": [
        {
        
          "FIELD": "desc"  // 排序字段、排序方式ASC、DESC
        }
      ]
    }

排序条件是一个数组，也就是可以写多个排序条件。按照声明的顺序，当第一个条件相等时，再按照第二个条件排序，以此类推

**示例**：

需求描述：酒店数据按照用户评价（score)降序排序，评价相同的按照价格(price)升序排序

![在这里插入图片描述][9b342ea35a784e4f87b54845b8931107.png]

--------------------

> **地理坐标排序**

这个场景，我们并不陌生，打车，点外卖，去游玩，app总是会把据我们位置，距离最近的商家排在前面

地理坐标排序略有不同。

**语法说明**：

GET /indexName/_search
    {
        
      "query": {
        
        "match_all": {
        }
      },
      "sort": [
        {
        
          "_geo_distance" : {
        
              "FIELD" : "纬度，经度", // 文档中geo_point类型的字段名、目标坐标点
              "order" : "asc", // 排序方式
              "unit" : "km" // 排序的距离单位
          }
        }
      ]
    }

这个查询的含义是：

*  指定一个坐标，作为目标点
 *  计算每一个文档中，指定字段（必须是geo\_point类型）的坐标 到目标点的距离是多少
 *  根据距离排序

**示例：**

需求描述：实现对酒店数据按照到你的位置坐标的距离升序排序

提示：获取你的位置的经纬度的方式：[https://lbs.amap.com/demo/jsapi-v2/example/map/click-to-get-lnglat/][https_lbs.amap.com_demo_jsapi-v2_example_map_click-to-get-lnglat]

![在这里插入图片描述][4585fd1a0da240b797f9ec4a667296c6.png]

--------------------

##### 分页 #####

elasticsearch 默认情况下只返回top10的数据。而如果要查询更多数据就需要修改分页参数了。elasticsearch中通过修改from、size参数来控制要返回的分页结果：

*  from：从第几个文档开始
 *  size：总共查询几个文档

类似于mysql中的`limit`

> **基本的分页**

分页的基本语法如下：

GET /hotel/_search
    {
        
      "query": {
        
        "match_all": {
        }
      },
      "from": 0, // 分页开始的位置，默认为0
      "size": 10, // 期望获取的文档总数
      "sort": [
        {
        "price": "asc"}
      ]
    }

> **深度分页**

要查询990~1000的数据，查询逻辑这么写：

GET /hotel/_search
    {
        
      "query": {
        
        "match_all": {
        }
      },
      "from": 990, // 分页开始的位置，默认为0
      "size": 10, // 期望获取的文档总数
      "sort": [
        {
        "price": "asc"}
      ]
    }

这里是查询990开始的数据，也就是 第990~第1000条 数据。

不过，elasticsearch内部分页时，必须先查询 0~1000条，然后截取其中的990 ~ 1000的这10条

![在这里插入图片描述][b7f39044dce0441ba29c4c0575282146.png]  
查询TOP1000，如果es是单点模式，这并无太大影响。

但是elasticsearch将来一定是集群，例如我集群有5个节点，我要查询TOP1000的数据，并不是每个节点查询200条就可以了。

因为节点A的TOP200，在另一个节点可能排到10000名以外了。

因此要想获取整个集群的TOP1000，必须先查询出每个节点的TOP1000，汇总结果后，重新排名，重新截取TOP1000。

![在这里插入图片描述][452a52894ed548849f610aca4971c79c.png]  
如果我要查询9900~10000的数据，要先查询TOP10000，那每个节点都要查询10000条，汇总到内存中，数据过多，对内存压力过大，因此elasticsearch会禁止from+ size 超过10000的请求

针对深度分页，ES提供了两种解决方案，[官方文档][Link 4]：

*  search after：分页时需要排序，原理是从上一次的排序值开始，查询下一页数据。官方推荐使用的方式。
 *  scroll：原理将排序后的文档id形成快照，保存在内存。官方已经不推荐使用。

--------------------

> **小结**

分页查询的常见实现方案以及优缺点：

*  `from + size`：
    
     *  优点：支持随机翻页
     *  缺点：深度分页问题，默认查询上限（from + size）是10000
     *  场景：百度、京东、谷歌、淘宝这样的随机翻页搜索
 *  `after search`：
    
     *  优点：没有查询上限（单次查询的size不超过10000）
     *  缺点：只能向后逐页查询，不支持随机翻页
     *  场景：没有随机翻页需求的搜索，例如手机向下滚动翻页
 *  `scroll`：
    
     *  优点：没有查询上限（单次查询的size不超过10000）
     *  缺点：会有额外内存消耗，并且搜索结果是非实时的
     *  场景：海量数据的获取和迁移。从ES7.1开始不推荐，建议用 after search方案。

--------------------

##### 高亮 #####

我们在百度，京东搜索时，关键字会变成红色，比较醒目，这叫高亮显示

高亮显示的实现分为两步：

*  1）给文档中的所有关键字都添加一个标签，例如`<em>`标签
 *  2）页面给`<em>`标签编写CSS样式

**实现高亮**

GET /hotel/_search
    {
        
      "query": {
        
        "match": {
        
          "FIELD": "TEXT" // 查询条件，高亮一定要使用全文检索查询
        }
      },
      "highlight": {
        
        "fields": {
         // 指定要高亮的字段
          "FIELD": {
        
            "pre_tags": "<em>",  // 用来标记高亮字段的前置标签//可以不加，不加默认是它
            "post_tags": "</em>" // 用来标记高亮字段的后置标签
          }
        }
      }
    }

**注意：**

*  高亮是对关键字高亮，因此**搜索条件必须带有关键字**，而不能是范围这样的查询。
 *  默认情况下，**高亮的字段，必须与搜索指定的字段一致**，否则无法高亮
 *  如果要对非搜索字段高亮，则需要添加一个属性：required\_field\_match=false

**示例**：  
![在这里插入图片描述][4f20784c2d324680b2445b2d06169ea5.png]

--------------------

##### 总结 #####

查询的DSL是一个大的JSON对象，包含下列属性：

*  query：查询条件
 *  from和size：分页条件
 *  sort：排序条件
 *  highlight：高亮条件

示例：  
![在这里插入图片描述][5124464678e04036976263d61d29f562.png]

--------------------

#### RestClient查询文档 ####

##### 快速入门 #####

操作几乎和前面的CRUD步骤基本相同  
1.导入RestClient的依赖

<dependency>
        <groupId>org.elasticsearch.client</groupId>
        <artifactId>elasticsearch-rest-high-level-client</artifactId>
    </dependency>

因为SpringBoot默认的ES版本是7.6.2，所以我们需要覆盖默认的ES版本：

2.初始化RestClient  
为了单元测试方便，创建一个测试类，将初始化的代码编写在@BeforeEach方法中

private RestHighLevelClient client;
    
    @BeforeEach
    void setUp() {
        
        this.client = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://47.100.200.177:9200")
        ));
    }
    
    @AfterEach
    void tearDown() throws IOException {
        
        this.client.close();
    }

--------------------

3.编写java代码，代替DSL查询语句

基本步骤包括：

*  1）准备Request对象
 *  2）准备请求参数
 *  3）发起请求
 *  4）解析响应

**原DSL的查询请求格式**  
![在这里插入图片描述][4ebcc739d3584dcb9b90a2c3b5619204.png]  
代码解读：

*  第一步，创建`SearchRequest`对象，指定索引库名
 *  第二步，利用`request.source()`构建DSL，DSL中可以包含查询、分页、排序、高亮等
    
     *  `query()`：代表查询条件，利用`QueryBuilders.matchAllQuery()`构建一个match\_all查询的DSL
 *  第三步，利用client.search()发送请求，得到响应

这里关键的API有两个，一个是`request.source()`，其中包含了查询、排序、分页、高亮等所有功能：

![在这里插入图片描述][2d26aa25b4f34757a0df2d917e0ef96e.png]

另一个是`QueryBuilders`，其中包含match、term、function\_score、bool等各种查询：

![在这里插入图片描述][6ecb6ad4a3fe401e93dff17a3240cee8.png]

最后解析返回的结果  
![在这里插入图片描述][a624f29a5f664a798cb2d6692933e512.png]

elasticsearch返回的结果是一个JSON字符串，结构包含：

*  `hits`：命中的结果
    
     *  `total`：总条数，其中的value是具体的总条数值
     *  `max_score`：所有结果中得分最高的文档的相关性算分
     *  `hits`：搜索结果的文档数组，其中的每个文档都是一个json对象
        
         *  `_source`：文档中的原始数据，也是json对象

因此，我们解析响应结果，就是逐层解析JSON字符串，流程如下：

*  `SearchHits`：通过response.getHits()获取，就是JSON中的最外层的hits，代表命中的结果
    
     *  `SearchHits.getTotalHits().value`：获取总条数信息
     *  `SearchHits.getHits()`：获取SearchHit数组，也就是文档数组
        
         *  `SearchHit.getSourceAsString()`：获取文档结果中的\_source，也就是原始的json文档数据

--------------------

**代码实现如下**

@Test
        void testMatchAll() throws IOException {
        
            //准备Request
            SearchRequest request = new SearchRequest("hotel");
            //组织DSL参数
            request.source().query(QueryBuilders.matchAllQuery());
            //发送请求，得到相应结果
            SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    
            /**
             * 解析查询返回的json字符串
             */
            handleResponse(response);
        }
    
        private void handleResponse(SearchResponse response) {
        
            SearchHits searchHits = response.getHits();
            //获取总条数
            TotalHits total = searchHits.getTotalHits();
            //获取查询结果的数组
            SearchHit[] hits = searchHits.getHits();
            for (SearchHit hit : hits) {
        
                //获取文档的source的json串
                String json = hit.getSourceAsString();
                //反序列化为HotelDoc对象
                HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
                System.out.println(hotelDoc);
            }
        }

> **小结**

查询的基本步骤是：

1.  创建SearchRequest对象
2.  准备Request.source()，也就是DSL。
    
    ① QueryBuilders来构建查询条件
    
    ② 传入Request.source() 的 query() 方法
3.  发送请求，得到结果
4.  解析结果（参考JSON结果，从外到内，逐层解析）

--------------------

##### match查询 #####

全文检索的match和multi\_match查询与match\_all的API基本一致。差别是查询条件，也就是query的部分。  
![在这里插入图片描述][c2b0522af5ad419ebd820d86144b0101.png]  
因此，Java代码上的差异主要是request.source().query()中的参数了。同样是利用QueryBuilders提供的方法  
![在这里插入图片描述][15177ce24d2a40339efaf12a4e99334f.png]  
而结果解析代码则完全一致，可以抽取并共享。

完整代码如下：

@Test
    void testMatch() throws IOException {
        
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        request.source()
            .query(QueryBuilders.matchQuery("all", "如家"));
        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        handleResponse(response);
    
    }

--------------------

##### 精确查询 #####

精确查询主要是两者：

*  term：词条精确匹配
 *  range：范围查询

与之前的查询相比，差异同样在查询条件，其它都一样。

查询条件构造的API如下：  
![在这里插入图片描述][bff6becfacdb48f799c9303d76b7e7fa.png]

@Test
        void testExact() throws IOException {
        
            //准备request
            SearchRequest request = new SearchRequest("hotel");
            //准备DSL
            request.source().query(QueryBuilders.termQuery("city", "杭州"));//精确匹配城市杭州的酒店
    //        request.source().query(QueryBuilders.rangeQuery("price").gte(100).lte(200));//范围查询价格大于等于100小于等于200
            //发送请求
            SearchResponse response = client.search(request, RequestOptions.DEFAULT);
            //解析结果
            handleResponse(response);
        }

--------------------

##### 布尔查询 #####

布尔查询是用must、must\_not、filter等方式组合其它查询，代码示例如下：  
![在这里插入图片描述][0df699649e574f7cbfe64e44a66692fa.png]  
可以看到，API与其它查询的差别同样是在查询条件的构建，QueryBuilders，结果解析等其他代码完全不变。

@Test
    void testBool() throws IOException {
        
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.准备BooleanQuery
        BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
        // 2.2.添加term
        boolQuery.must(QueryBuilders.termQuery("city", "杭州"));
        // 2.3.添加range
        boolQuery.filter(QueryBuilders.rangeQuery("price").lte(250));
    
        request.source().query(boolQuery);
        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        handleResponse(response);
    
    }

--------------------

##### 排序、分页 #####

搜索结果的排序和分页是与query同级的参数，因此同样是使用request.source()来设置。

对应的API如下：  
![在这里插入图片描述][ceca09e992a3422fa5de850980d178c9.png]  
完整代码示例：

@Test
    void testPageAndSort() throws IOException {
        
        // 页码，每页大小
        int page = 1, size = 5;
    
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        request.source().query(QueryBuilders.matchAllQuery());
        // 2.2.排序 sort
        request.source().sort("price", SortOrder.ASC);
        // 2.3.分页 from、size
        request.source().from((page - 1) * size).size(5);
        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        handleResponse(response);
    
    }

--------------------

##### 高亮 #####

高亮的代码与之前代码差异较大，有两点：

*  查询的DSL：其中除了查询条件，还需要添加高亮条件，同样是与query同级。
 *  结果解析：结果除了要解析\_source文档数据，还要解析高亮结果

**高亮请求构建**

![在这里插入图片描述][a9dace4480d74257a11d9c9e48db58a9.png]

述代码省略了查询条件部分，但是大家不要忘了：高亮查询必须使用全文检索查询，并且要有搜索关键字，将来才可以对关键字高亮。

完整代码如下：

@Test
    void testHighlight() throws IOException {
        
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        request.source().query(QueryBuilders.matchQuery("all", "如家"));
        // 2.2.高亮
        request.source().highlighter(new HighlightBuilder().field("name").requireFieldMatch(false));
        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        handleResponse(response);
    
    }

**高亮结果解析**  
![在这里插入图片描述][f6f774ecec17434bbdc85d216c52164f.png]  
代码解读：

*  第一步：从结果中获取source。hit.getSourceAsString()，这部分是非高亮结果，json字符串。还需要反序列为HotelDoc对象
 *  第二步：获取高亮结果。hit.getHighlightFields()，返回值是一个Map，key是高亮字段名称，值是HighlightField对象，代表高亮值
 *  第三步：从map中根据高亮字段名称，获取高亮字段值对象HighlightField
 *  第四步：从HighlightField中获取Fragments，并且转为字符串。这部分就是真正的高亮字符串了
 *  第五步：用高亮的结果替换HotelDoc中的非高亮结果

解析相响应代码修改如下：

private void handleResponse(SearchResponse response) {
        
        // 4.解析响应
        SearchHits searchHits = response.getHits();
        // 4.1.获取总条数
        long total = searchHits.getTotalHits().value;
        System.out.println("共搜索到" + total + "条数据");
        // 4.2.文档数组
        SearchHit[] hits = searchHits.getHits();
        // 4.3.遍历
        for (SearchHit hit : hits) {
        
            // 获取文档source
            String json = hit.getSourceAsString();
            // 反序列化
            HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
            // 获取高亮结果
            Map<String, HighlightField> highlightFields = hit.getHighlightFields();
            if (!CollectionUtils.isEmpty(highlightFields)) {
        
                // 根据字段名获取高亮结果
                HighlightField highlightField = highlightFields.get("name");
                if (highlightField != null) {
        
                    // 获取高亮值
                    String name = highlightField.getFragments()[0].string();
                    // 覆盖非高亮结果
                    hotelDoc.setName(name);
                }
            }
            System.out.println("hotelDoc = " + hotelDoc);
        }
    }

--------------------

### 旅游项目案例 ###

首先导入RestClient的依赖

<dependency>
        <groupId>org.elasticsearch.client</groupId>
        <artifactId>elasticsearch-rest-high-level-client</artifactId>
    </dependency>

因为SpringBoot默认的ES版本是7.6.2，所以我们需要覆盖默认的ES版本：

--------------------

其次，把RestClient注册为bean，完成初始化，在启动类中注入bean

@Bean
        public RestHighLevelClient client(){
        
            return new RestHighLevelClient(RestClient.builder(
                    HttpHost.create("http://47.100.200.177:9200")
            ));
        }

--------------------

定义前端请求参数实体类

![在这里插入图片描述][ddddbdffc79c47d1a0ac76edda53e615.png]

![在这里插入图片描述][cc4758a039bb4b74969508da5543464f.png]

@Data
    public class RequestParams {
        
        private String key;
        private Integer page;
        private Integer size;
        private String sortBy;
    }

定义服务端应该返回的响应结果实体类

分页查询返回分页结果PageResult，包含两个属性：

*  `total`：总条数
 *  `List<HotelDoc>`：当前页的数据

@Data
    public class PageResult {
        
        private Long total;
        private List<HotelDoc> hotels;
    
        public PageResult() {
        
        }
    
        public PageResult(Long total, List<HotelDoc> hotels) {
        
            this.total = total;
            this.hotels = hotels;
        }
    }

--------------------

#### 酒店搜索和分页 ####

定义一个HotelController，声明查询接口，满足下列要求：

*  请求方式：Post
 *  请求路径：/hotel/list
 *  请求参数：对象，类型为RequestParam
 *  返回值：PageResult，包含两个属性
    
     *  `Long total`：总条数
     *  `List<HotelDoc> hotels`：酒店数据

@Slf4j
    @RestController
    @RequestMapping("/hotel")
    public class HotelController {
        
        @Autowired
        private IHotelService hotelService;
        
        //搜索酒店数据
        @PostMapping("/list")
        public PageResult search(@RequestBody RequestParams params){
        
            return hotelService.search(params);
        }
    }

然后在service层中实现搜索业务  
1.`IHotelService`接口中定义一个方法：

/**
     * 根据关键字搜索酒店信息
     * @param params 请求参数对象，包含用户输入的关键字 
     * @return 酒店文档列表
     */
    PageResult search(RequestParams params);

2.在`cn.itcast.hotel.service.impl`中的`HotelService`中实现search方法：

@Override
    public PageResult search(RequestParams params) {
        
        try {
        
            // 1.准备Request
            SearchRequest request = new SearchRequest("hotel");
            // 2.准备DSL
            // 2.1.query
            String key = params.getKey();
            if (key == null || "".equals(key)) {
        
                boolQuery.must(QueryBuilders.matchAllQuery());
            } else {
        
                boolQuery.must(QueryBuilders.matchQuery("all", key));
            }
    
            // 2.2.分页
            int page = params.getPage();
            int size = params.getSize();
            request.source().from((page - 1) * size).size(size);
    
            // 3.发送请求
            SearchResponse response = client.search(request, RequestOptions.DEFAULT);
            // 4.解析响应
            return handleResponse(response);
        } catch (IOException e) {
        
            throw new RuntimeException(e);
        }
    }
    
    // 结果解析
    private PageResult handleResponse(SearchResponse response) {
        
        // 4.解析响应
        SearchHits searchHits = response.getHits();
        // 4.1.获取总条数
        long total = searchHits.getTotalHits().value;
        // 4.2.文档数组
        SearchHit[] hits = searchHits.getHits();
        // 4.3.遍历
        List<HotelDoc> hotels = new ArrayList<>();
        for (SearchHit hit : hits) {
        
            // 获取文档source
            String json = hit.getSourceAsString();
            // 反序列化
            HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
    		// 放入集合
            hotels.add(hotelDoc);
        }
        // 4.4.封装返回
        return new PageResult(total, hotels);
    }

需要注意的是处理返回结果的方法需要修改，把最后的返回值给封装成我们定义的PageResult对象

![在这里插入图片描述][2afb414996ec4cab80f62adfc437f3a3.png]

![在这里插入图片描述][11dc70e8147241608b0fd57fed95322a.png]  
![在这里插入图片描述][42f0ae87c23547d4a524a305120faa38.png]

--------------------

#### 酒店结果过滤 ####

需求：添加品牌、城市、星级、价格等过滤功能  
![在这里插入图片描述][c3b144aff7fc4fe08d12e9b5d0b7db9c.png]  
传递的参数如图：  
![在这里插入图片描述][2dfda9ecf3484b309fd3df0b4ae5935a.png]

包含的过滤条件有：

*  brand：品牌值
 *  city：城市
 *  minPrice~maxPrice：价格范围
 *  starName：星级

我们需要做两件事情：

*  ①修改请求参数的对象RequestParams，接收上述参数
 *  ②修改业务逻辑，在搜索条件之外，添加一些过滤条件

**修改实体类**  
实体类RequestParams添加城市，品牌，星级，价格参数

@Data
    public class RequestParams {
        
        private String key;
        private Integer page;
        private Integer size;
        private String sortBy;
        // 下面是新增的过滤条件参数
        private String city;
        private String brand;
        private String starName;
        private Integer minPrice;
        private Integer maxPrice;
    }

--------------------

**修改搜索业务**  
在HotelService的search方法中，只有一个地方需要修改：requet.source().query( … )其中的查询条件。

在之前的业务中，只有match查询，根据关键字搜索，现在要添加条件过滤，包括：

*  品牌过滤：是keyword类型，用term查询
 *  星级过滤：是keyword类型，用term查询
 *  价格过滤：是数值类型，用range查询
 *  城市过滤：是keyword类型，用term查询

多个查询条件组合，肯定是boolean查询来组合：

*  关键字搜索放到must中，参与算分
 *  其它过滤条件放到filter中，不参与算分

因为条件构建的逻辑比较复杂，这里先封装为一个函数：

![在这里插入图片描述][b0a23c04cd9845f1b43c47e1bb6147d5.png]  
buildBasicQuery的代码如下

private void buildBasicQuery(RequestParams params, SearchRequest request) {
        
        // 1.构建BooleanQuery
        BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
        // 2.关键字搜索
        String key = params.getKey();
        if (key == null || "".equals(key)) {
        
            boolQuery.must(QueryBuilders.matchAllQuery());
        } else {
        
            boolQuery.must(QueryBuilders.matchQuery("all", key));
        }
        // 3.城市条件
        if (params.getCity() != null && !params.getCity().equals("")) {
        
            boolQuery.filter(QueryBuilders.termQuery("city", params.getCity()));
        }
        // 4.品牌条件
        if (params.getBrand() != null && !params.getBrand().equals("")) {
        
            boolQuery.filter(QueryBuilders.termQuery("brand", params.getBrand()));
        }
        // 5.星级条件
        if (params.getStarName() != null && !params.getStarName().equals("")) {
        
            boolQuery.filter(QueryBuilders.termQuery("starName", params.getStarName()));
        }
    	// 6.价格
        if (params.getMinPrice() != null && params.getMaxPrice() != null) {
        
            boolQuery.filter(QueryBuilders
                             .rangeQuery("price")
                             .gte(params.getMinPrice())
                             .lte(params.getMaxPrice())
                            );
        }
    	// 7.放入source
        request.source().query(boolQuery);
    }

--------------------

#### 我周边的酒店 ####

在酒店列表页的右侧，有一个小地图，点击地图的定位按钮，地图会找到你所在的位置：  
并且，在前端会发起查询请求，将你的坐标发送到服务端：  
![在这里插入图片描述][ec065587194a485d88071777f577c2ef.png]

![在这里插入图片描述][96fb5d73cb6c43c6971e56ac3496ae14.png]

我们要做的事情就是基于这个location坐标，然后按照距离对周围酒店排序。实现思路如下：

*  修改RequestParams参数，接收location字段
 *  修改search方法业务逻辑，如果location有值，添加根据geo\_distance排序的功能
 *  修改处理响应结果的方法，从JSON串中解析出距离值

--------------------

地理坐标排序只学过DSL语法，如下：

GET /indexName/_search
    {
        
      "query": {
        
        "match_all": {
        }
      },
      "sort": [
        {
        
          "price": "asc"  
        },
        {
        
          "_geo_distance" : {
        
              "FIELD" : "纬度，经度",
              "order" : "asc",
              "unit" : "km"
          }
        }
      ]
    }

对应的java代码示例：  
![在这里插入图片描述][4708562b87824ef19439f4e0927dcbcb.png]

--------------------

**添加距离排序**

![在这里插入图片描述][677c4340a9334882b5c543dcd47a7311.png]

@Override
    public PageResult search(RequestParams params) {
        
        try {
        
            // 1.准备Request
            SearchRequest request = new SearchRequest("hotel");
            // 2.准备DSL
            // 2.1.query
            buildBasicQuery(params, request);
    
            // 2.2.分页
            int page = params.getPage();
            int size = params.getSize();
            request.source().from((page - 1) * size).size(size);
    
            // 2.3.排序
            String location = params.getLocation();
            if (location != null && !location.equals("")) {
        
                request.source().sort(SortBuilders
                                      .geoDistanceSort("location", new GeoPoint(location))
                                      .order(SortOrder.ASC)
                                      .unit(DistanceUnit.KILOMETERS)
                                     );
            }
    
            // 3.发送请求
            SearchResponse response = client.search(request, RequestOptions.DEFAULT);
            // 4.解析响应
            return handleResponse(response);
        } catch (IOException e) {
        
            throw new RuntimeException(e);
        }
    }

--------------------

排序完成后，页面还要获取我附近每个酒店的具体**距离**值，这个值在响应结果中是独立的：  
![在这里插入图片描述][501bbd8223ae4f699297353a9fcc77dd.png]  
我们在结果解析阶段，除了解析source部分以外，还要得到sort部分，也就是排序的距离，然后放到响应结果中。

我们要做两件事：

*  修改HotelDoc，添加排序距离字段，用于页面显示
 *  修改HotelService类中的handleResponse方法，添加对sort值的获取

1）修改HotelDoc类，添加距离字段distance  
![在这里插入图片描述][3feccf12b4d4424fb6ed805c4935b0ee.png]

2）修改HotelService中的handleResponse方法

![在这里插入图片描述][81c3108dffb342bfb702cabecaaa2cc4.png]

最后结果如下图  
![在这里插入图片描述][685757987fdc4f5f8ff04e0de700aa30.png]

--------------------

#### 酒店竞价排名 ####

需求：让指定的酒店在搜索结果中排名置顶  
就修改它的相关性分值，分值越高越靠前

要让指定酒店在搜索结果中排名置顶，效果如图：

![在这里插入图片描述][231e073b8792416890f2d3db6ee52d70.png]  
页面会给指定的酒店添加**广告**标记。

之前学习过的function\_score查询可以影响算分，算分高了，自然排名也就高了。而function\_score包含3个要素：

*  过滤条件：哪些文档要加分
 *  算分函数：如何计算function score
 *  加权方式：function score 与 query score如何运算

这里的需求是：让**指定酒店**排名靠前。因此我们需要给这些酒店添加一个标记，这样在过滤条件中就可以**根据这个标记来判断，是否要提高算分**。

比如，我们给酒店添加一个字段：isAD，Boolean类型：

*  true：是广告
 *  false：不是广告

这样function\_score包含3个要素就很好确定了：

*  过滤条件：判断isAD 是否为true
 *  算分函数：我们可以用最简单暴力的weight，固定加权值
 *  加权方式：可以用默认的相乘，大大提高算分

因此，业务的实现步骤包括：

1.  给HotelDoc类添加isAD字段，Boolean类型
2.  挑选几个你喜欢的酒店，给它的文档数据添加isAD字段，值为true
3.  修改search方法，添加function score功能，给isAD值为true的酒店增加权重

--------------------

**修改HotelDoc实体**  
HotelDoc类添加isAD字段  
![在这里插入图片描述][09000b32d0be419ea765d0a337b096a7.png]

**添加广告标记**  
接下来，我们挑几个酒店，添加isAD字段，设置为true：

POST /hotel/_update/1902197537
    {
        
        "doc": {
        
            "isAD": true
        }
    }
    POST /hotel/_update/2056126831
    {
        
        "doc": {
        
            "isAD": true
        }
    }
    POST /hotel/_update/1989806195
    {
        
        "doc": {
        
            "isAD": true
        }
    }
    POST /hotel/_update/2056105938
    {
        
        "doc": {
        
            "isAD": true
        }
    }

**添加算分函数查询**

接下来我们就要修改查询条件了。之前是用的boolean 查询，现在要改成function\_socre查询。  
function\_score查询结构如下：  
![在这里插入图片描述][b176e594a2b04a479650c5b8aad78fff.png]  
对应的JavaAPI如下：  
![在这里插入图片描述][d43631d7a83f460d92c52bb6ce475fe1.png]  
可以将之前写的boolean查询作为**原始查询**条件放到query中，接下来就是添加**过滤条件**、**算分函数**、**加权模式**了。所以原来的代码依然可以沿用。

private void buildBasicQuery(RequestParams params, SearchRequest request) {
        
        // 1.构建BooleanQuery
        BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
        // 关键字搜索
        String key = params.getKey();
        if (key == null || "".equals(key)) {
        
            boolQuery.must(QueryBuilders.matchAllQuery());
        } else {
        
            boolQuery.must(QueryBuilders.matchQuery("all", key));
        }
        // 城市条件
        if (params.getCity() != null && !params.getCity().equals("")) {
        
            boolQuery.filter(QueryBuilders.termQuery("city", params.getCity()));
        }
        // 品牌条件
        if (params.getBrand() != null && !params.getBrand().equals("")) {
        
            boolQuery.filter(QueryBuilders.termQuery("brand", params.getBrand()));
        }
        // 星级条件
        if (params.getStarName() != null && !params.getStarName().equals("")) {
        
            boolQuery.filter(QueryBuilders.termQuery("starName", params.getStarName()));
        }
        // 价格
        if (params.getMinPrice() != null && params.getMaxPrice() != null) {
        
            boolQuery.filter(QueryBuilders
                             .rangeQuery("price")
                             .gte(params.getMinPrice())
                             .lte(params.getMaxPrice())
                            );
        }
    
        // 2.算分控制
        FunctionScoreQueryBuilder functionScoreQuery =
            QueryBuilders.functionScoreQuery(
            // 原始查询，相关性算分的查询
            boolQuery,
            // function score的数组
            new FunctionScoreQueryBuilder.FilterFunctionBuilder[]{
        
                // 其中的一个function score 元素
                new FunctionScoreQueryBuilder.FilterFunctionBuilder(
                    // 过滤条件
                    QueryBuilders.termQuery("isAD", true),
                    // 算分函数
                    ScoreFunctionBuilders.weightFactorFunction(10)
                )
            });
        request.source().query(functionScoreQuery);
    }

--------------------

### 数据聚合 ###

#### 聚合的种类 ####

聚合常见的有三类：

*  **桶**（Bucket）聚合：用来对文档做分组，就像生活中的垃圾分类一样，不同垃圾放入不同垃圾桶中
    
     *  TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
     *  Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
 *  **度量**（Metric）聚合：用以计算一些值，比如：最大值、最小值、平均值等
    
     *  Avg：求平均值
     *  Max：求最大值
     *  Min：求最小值
     *  Stats：同时求max、min、avg、sum等
 *  **管道**（pipeline）\*聚合：其它聚合的结果为基础做聚合

> **注意**：参加聚合的字段必须是keyword、日期、数值、布尔类型

--------------------

#### DSL实现聚合 ####

现在，我们要统计所有数据中的**酒店品牌**有几种，其实就是**按照品牌**对数据**分组**。此时可以根据酒店品牌的名称做聚合，也就是Bucket聚合。

> **Bucket(桶)聚合语法**

语法如下：

GET /hotel/_search
    {
        
      "size": 0,  // 设置size为0，结果中不包含文档，只包含聚合结果
      "aggs": {
         // 定义聚合
        "brandAgg": {
         //给聚合起个名字
          "terms": {
         // 聚合的类型，按照品牌值聚合，所以选择term
            "field": "brand", // 参与聚合的字段
            "size": 20 // 希望获取的聚合结果数量
          }
        }
      }
    }

结果如图：  
![在这里插入图片描述][8092ab934d4e45b19b44b399b80fec7e.png]

--------------------

> **对聚合结果排序**

默认情况下，Bucket聚合会统计Bucket内的文档数量，记为\_count，并且**按照\_count降序排序**。

我们可以指定order属性，自定义聚合的排序方式：

GET /hotel/_search
    {
        
      "size": 0, 
      "aggs": {
        
        "brandAgg": {
        
          "terms": {
        
            "field": "brand",
            "order": {
        
              "_count": "asc" // 按照_count升序排列
            },
            "size": 20
          }
        }
      }
    }

--------------------

> **限定聚合范围**

默认情况下，Bucket聚合是对索引库的所有文档做聚合，但真实场景下，用户会输入搜索条件，因此聚合必须是对搜索结果聚合。那么聚合必须添加限定条件。

我们可以限定要聚合的文档范围，只要添加query条件即可：

GET /hotel/_search
    {
        
      "query": {
        
        "range": {
        
          "price": {
        
            "lte": 200 // 只对200元以下的文档聚合
          }
        }
      }, 
      "size": 0, 
      "aggs": {
        
        "brandAgg": {
        
          "terms": {
        
            "field": "brand",
            "size": 20
          }
        }
      }
    }

这次，聚合得到的品牌明显变少了：

![在这里插入图片描述][b631779d90b444d6b13e287c23605be5.png]

--------------------

> **Metric(度量)聚合语法**

我们对酒店按照品牌分组，形成了一个个桶。现在我们需要对桶内的酒店做运算，获取每个品牌的用户评分的min、max、avg等值。

这就要用到Metric聚合了，例如stat聚合：就可以获取min、max、avg等结果。

语法如下：

GET /hotel/_search
    {
        
      "size": 0, 
      "aggs": {
        
        "brandAgg": {
         
          "terms": {
         
            "field": "brand", 
            "size": 20
          },
          "aggs": {
         // 是brands聚合的子聚合，也就是分组后对每组分别计算
            "score_stats": {
         // 聚合名称
              "stats": {
         // 聚合类型，这里stats可以计算min、max、avg等
                "field": "score" // 聚合字段，这里是score
              }
            }
          }
        }
      }
    }

这次的score\_stats聚合是在brandAgg的聚合内部**嵌套的子聚合**。因为我们需要在每个桶分别计算。

另外，我们还可以给聚合结果做个排序，例如按照每个桶的酒店平均分做排序：

![在这里插入图片描述][23cc6bf665ac47328b22169c3a347b2d.png]

--------------------

> **小结**

*aggs代表聚合，与query同级，此时query的作用是？*

*  限定聚合的的文档范围

*聚合必须的三要素：*

*  聚合名称
 *  聚合类型
 *  聚合字段

*聚合可配置属性有：*

*  size：指定聚合结果数量
 *  order：指定聚合结果排序方式
 *  field：指定聚合字段

--------------------

#### RestAPI实现聚合 ####

> **API语法**

聚合条件与query条件同级别，因此需要使用request.source()来指定聚合条件。

聚合条件的语法：

![在这里插入图片描述][01e8f192a1214059957617a7e7a87975.png]  
聚合的结果也与查询结果不同，API也比较特殊。不过同样是**JSON逐层解析**：  
![在这里插入图片描述][bc9f631bcb9e44779a804397390e4948.png]

--------------------

> **业务需求**

需求：搜索页面的品牌、城市等信息不应该是在页面写死，而是通过聚合索引库中的酒店数据得来的：  
也就是每次选择了一个条件以后，栏中内容要发生变化，有相关的留下，没有相关的移除；

比如我先选择了价格100元以下的，那么星级一栏中五钻，四钻就不应该还在了，因为数据中没有100以下的四星，五星酒店

![在这里插入图片描述][6d675f73fc9546ef83b63a24d34971c1.png]

分析：

目前，页面的城市列表、星级列表、品牌列表都是写死的，并不会随着搜索结果的变化而变化。但是用户搜索条件改变时，搜索结果会跟着变化。

例如：用户搜索“东方明珠”，那搜索的酒店肯定是在上海东方明珠附近，因此，城市只能是上海，此时城市列表中就不应该显示北京、深圳、杭州这些信息了。

也就是说，搜索结果中包含哪些城市，页面就应该列出哪些城市；搜索结果中包含哪些品牌，页面就应该列出哪些品牌。

使用聚合功能，利用Bucket聚合，对搜索结果中的文档基于品牌分组、基于城市分组，就能得知包含哪些品牌、哪些城市了。

因为是对搜索结果聚合，因此聚合是**限定范围的聚合**，也就是说聚合的限定条件跟搜索文档的条件一致。  
查看浏览器可以发现，前端其实已经发出了这样的一个请求：  
![在这里插入图片描述][9fd44fff61db423cb0ca328fe0727c7d.png]  
请求**参数与搜索文档的参数完全一致**。

返回值类型就是页面要展示的最终结果：

![在这里插入图片描述][8dde9b5f73dd421eac51cff428aec8b7.png]  
结果是一个Map结构：

*  key是字符串，城市、星级、品牌、价格
 *  value是集合，例如多个城市的名称

--------------------

> **业务实现**

`HotelController`中添加一个方法，遵循下面的要求：

*  请求方式：`POST`
 *  请求路径：`/hotel/filters`
 *  请求参数：`RequestParams`，与搜索文档的参数一致
 *  返回值类型：`Map<String, List<String>>`

代码：

@PostMapping("filters")
        public Map<String, List<String>> getFilters(@RequestBody RequestParams params){
        
            return hotelService.getFilters(params);
        }

这里调用了IHotelService中的getFilters方法，尚未实现。

在`IHotelService`中定义新方法：

Map<String, List<String>> filters(RequestParams params);

@Override
    public Map<String, List<String>> filters(RequestParams params) {
        
        try {
        
            // 1.准备Request
            SearchRequest request = new SearchRequest("hotel");
            // 2.准备DSL
            // 2.1.query
            buildBasicQuery(params, request);
            // 2.2.设置size
            request.source().size(0);
            // 2.3.聚合
            buildAggregation(request);
            // 3.发出请求
            SearchResponse response = client.search(request, RequestOptions.DEFAULT);
            // 4.解析结果
            Map<String, List<String>> result = new HashMap<>();
            Aggregations aggregations = response.getAggregations();
            // 4.1.根据品牌名称，获取品牌结果
            List<String> brandList = getAggByName(aggregations, "brandAgg");
            result.put("品牌", brandList);
            // 4.2.根据品牌名称，获取品牌结果
            List<String> cityList = getAggByName(aggregations, "cityAgg");
            result.put("城市", cityList);
            // 4.3.根据品牌名称，获取品牌结果
            List<String> starList = getAggByName(aggregations, "starAgg");
            result.put("星级", starList);
    
            return result;
        } catch (IOException e) {
        
            throw new RuntimeException(e);
        }
    }
    
    private void buildAggregation(SearchRequest request) {
        
        request.source().aggregation(AggregationBuilders
                                     .terms("brandAgg")
                                     .field("brand")
                                     .size(100)
                                    );
        request.source().aggregation(AggregationBuilders
                                     .terms("cityAgg")
                                     .field("city")
                                     .size(100)
                                    );
        request.source().aggregation(AggregationBuilders
                                     .terms("starAgg")
                                     .field("starName")
                                     .size(100)
                                    );
    }
    
    private List<String> getAggByName(Aggregations aggregations, String aggName) {
        
        // 4.1.根据聚合名称获取聚合结果
        Terms brandTerms = aggregations.get(aggName);
        // 4.2.获取buckets
        List<? extends Terms.Bucket> buckets = brandTerms.getBuckets();
        // 4.3.遍历
        List<String> brandList = new ArrayList<>();
        for (Terms.Bucket bucket : buckets) {
        
            // 4.4.获取key
            String key = bucket.getKeyAsString();
            brandList.add(key);
        }
        return brandList;
    }

--------------------

### 自动补全 ###

当用户在搜索框输入字符时，我们应该提示出与该字符有关的搜索项，如图：

![在这里插入图片描述][47a20f78f6154ee793d84db9758ad026.png]  
这种根据用户输入的字母，提示完整词条的功能，就是自动补全了。

因为需要根据拼音字母来推断，因此要用到拼音分词功能。

> **拼音分词器**

要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。地址：[https://github.com/medcl/elasticsearch-analysis-pinyin][https_github.com_medcl_elasticsearch-analysis-pinyin]

**安装方式与IK分词器一样，分三步：**

①解压

②上传到虚拟机中，elasticsearch的plugin目录

③重启elasticsearch

测试用法如下：

POST /_analyze
    {
        
      "text": "如家酒店还不错",
      "analyzer": "pinyin"
    }

结果：  
![在这里插入图片描述][8323ffc6c9014aa4b41d1fab7e3e95d0.png]

--------------------

> **自定义分词器**

默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。

elasticsearch中分词器（analyzer）的组成包含三部分：

*  character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符
 *  tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik\_smart
 *  tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等

文档分词时会依次由这三部分来处理文档：

![在这里插入图片描述][8a4727ecf6ca4e0793e022fd14853b98.png]  
声明自定义分词器的语法如下：

PUT /test
    {
        
      "settings": {
        
        "analysis": {
        
          "analyzer": {
         // 自定义分词器
            "my_analyzer": {
          // 分词器名称
              "tokenizer": "ik_max_word",
              "filter": "py"
            }
          },
          "filter": {
         // 自定义tokenizer filter
            "py": {
         // 过滤器名称
              "type": "pinyin", // 过滤器类型，这里是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"
          }
        }
      }
    }

测试：  
![在这里插入图片描述][b4f8ca2cf159497a9921dbc6e665bd07.png]

--------------------

> **总结：**

*如何使用拼音分词器？*

*  ①下载pinyin分词器
 *  ②解压并放到elasticsearch的plugin目录
 *  ③重启即可

*如何自定义分词器？*

*  ①创建索引库时，在settings中配置，可以包含三部分
 *  ②character filter
 *  ③tokenizer
 *  ④filter

*拼音分词器注意事项？*

*  为了避免搜索到同音字，搜索时不要使用拼音分词器

--------------------

> **自动补全查询**

elasticsearch提供了[Completion Suggester][]查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。为了提高补全查询的效率，对于文档中字段的类型有一些约束：

*  参与补全查询的字段必须是completion类型。
 *  字段的内容一般是用来补全的多个词条形成的数组。

比如，一个这样的索引库：

// 创建索引库
    PUT test
    {
        
      "mappings": {
        
        "properties": {
        
          "title":{
        
            "type": "completion"
          }
        }
      }
    }

然后插入下面的数据：

// 示例数据
    POST test/_doc
    {
        
      "title": ["Sony", "WH-1000XM3"]
    }
    POST test/_doc
    {
        
      "title": ["SK-II", "PITERA"]
    }
    POST test/_doc
    {
        
      "title": ["Nintendo", "switch"]
    }

查询的DSL语句如下：

// 自动补全查询
    GET /test/_search
    {
        
      "suggest": {
        
        "title_suggest": {
        
          "text": "s", // 关键字
          "completion": {
        
            "field": "title", // 补全查询的字段
            "skip_duplicates": true, // 跳过重复的
            "size": 10 // 获取前10条结果
          }
        }
      }
    }

--------------------

### 数据同步 ###

常见的数据同步方案有三种：

*  同步调用
 *  异步通知
 *  监听binlog

#### 同步策略 ####

> **方案一：同步调用**

只适用于单体项目，对于微服务项目，效率既低下又难以维护管理，耦合度很高  
![在这里插入图片描述][e3150393d3e14f08bf893a9b92ec4dc4.png]  
基本步骤如下：

*  hotel-demo对外提供接口，用来修改elasticsearch中的数据
 *  酒店管理服务在完成数据库操作后，直接调用hotel-demo提供的接口

只要数据库更新，elasticsearch就更新，相当于把这个两个操作加到一个事务中

--------------------

> **方案二：异步通知**

![在这里插入图片描述][159f04a991fb4dd1937f64ddfa4536f3.png]

流程如下：

*  hotel-admin对mysql数据库数据完成增、删、改后，发送MQ消息
 *  hotel-demo监听MQ，接收到消息后完成elasticsearch数据修改

--------------------

> **方案三：监听binlog**

![在这里插入图片描述][202e521cdd0646c997714d736bfdf0fc.png]  
流程如下：

*  给mysql开启binlog功能
 *  mysql完成增、删、改操作都会记录在binlog中
 *  hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容

--------------------

> **小结**

方式一：同步调用

*  优点：实现简单，粗暴
 *  缺点：业务耦合度高

方式二：异步通知

*  优点：低耦合，实现难度一般
 *  缺点：依赖mq的可靠性

方式三：监听binlog

*  优点：完全解除服务间耦合
 *  缺点：开启binlog增加数据库负担、实现复杂度高

--------------------

#### 实现数据同步 ####

##### 代码思路 #####

这里使用前面学到的一种技术，MQ来做中间监听者  
当酒店数据发生增、删、改时，要求对elasticsearch中数据也要完成相同操作。

步骤：

*  导入课前资料提供的hotel-admin项目，启动并测试酒店数据的CRUD
 *  声明exchange、queue、RoutingKey
 *  在hotel-admin中的增、删、改业务中完成消息发送
 *  在hotel-demo中完成消息监听，并更新elasticsearch中数据
 *  启动并测试数据同步功能

--------------------

##### 导入demo工程 #####

导入课前资料提供的hotel-admin项目，yml中修改数据库的配置信息  
运行后，访问 http://localhost:8099

![在这里插入图片描述][9924de5388344de58300ade3c3a5addb.png]  
其中包含了酒店的CRUD功能：  
![在这里插入图片描述][7a0e8826f5a949c3a5c791b2d2e00a50.png]  
都是mp中的api，直接调用

--------------------

##### 声明队列和交换机 #####

MQ结构如图：  
![在这里插入图片描述][cfb8e94b3d1e4e0ba4f4cc98c8bb34a8.png]  
**引入依赖**  
在hotel-admin、hotel-demo中引入rabbitmq的依赖：

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-amqp</artifactId>
    </dependency>

**启动mq容器**  
如果之前run过mq容器，这里只需要

docker start 容器名

如果以前没有run过mq的容器，就需要

启动后可以访问 ip:15672  
![在这里插入图片描述][1ff13fd312dd4140a52bda6cb550d781.png]

**添加配置信息**  
hotel-admin、hotel-demo中需要添加配置信息  
![在这里插入图片描述][178102cdcf574bbb951cd45a049c7828.png]

rabbitmq:
        host: IP
        port: 5672
        username: 你mq管理界面的账号
        password: 你mq管理界面的密码
        virtual-host: /

**声明队列交换机名称**  
为避免队列交换机名称写错，把它们的名称都定义在常量类中，统一定义  
constatnts包下新建MqConstants静态变量类

public class MqConstants {
        
        /**
         * 交换机
         */
        public final static String HOTEL_EXCHANGE = "hotel.topic";
        /**
         * 监听新增和修改的队列
         */
        public final static String HOTEL_INSERT_QUEUE = "hotel.insert.queue";
        /**
         * 监听删除的队列
         */
        public final static String HOTEL_DELETE_QUEUE = "hotel.delete.queue";
        /**
         * 新增或修改的RoutingKey
         */
        public final static String HOTEL_INSERT_KEY = "hotel.insert";
        /**
         * 删除的RoutingKey
         */
        public final static String HOTEL_DELETE_KEY = "hotel.delete";
    }

**声明队列交换机**  
在hotel-demo中，定义配置类，声明队列、交换机：

@Configuration
    public class MqConfig {
        
        @Bean
        public TopicExchange topicExchange(){
        
            return new TopicExchange(MqConstants.HOTEL_EXCHANGE, true, false);
        }
    
        @Bean
        public Queue insertQueue(){
        
            return new Queue(MqConstants.HOTEL_INSERT_QUEUE, true);
        }
    
        @Bean
        public Queue deleteQueue(){
        
            return new Queue(MqConstants.HOTEL_DELETE_QUEUE, true);
        }
    
        @Bean
        public Binding insertQueueBinding(){
        
            return BindingBuilder.bind(insertQueue()).to(topicExchange()).with(MqConstants.HOTEL_INSERT_KEY);
        }
    
        @Bean
        public Binding deleteQueueBinding(){
        
            return BindingBuilder.bind(deleteQueue()).to(topicExchange()).with(MqConstants.HOTEL_DELETE_KEY);
        }
    }

--------------------

##### 发送MQ消息 #####

在hotel-admin中的增、删、改业务中分别发送MQ消息：

三个参数：交换机，RountingKey，消息  
![在这里插入图片描述][362097a9b76f4f14ac9b4a6731946538.png]

> ***hotel-admin中每次进行数据库的crud，就发送消息到对列，通知订阅消息的接收方hotel-demo来更新es索引库中的文档，保证数据同步***

--------------------

##### 接收MQ消息 #####

hotel-demo接收到MQ消息要做的事情包括：

*  新增消息：根据传递的hotel的id查询hotel信息，然后新增一条数据到索引库
 *  删除消息：根据传递的hotel的id删除索引库中的一条数据

1）首先在hotel-demo的`service`包下的`IHotelService`中添加新增、删除业务

void deleteById(Long id);
    
    void insertById(Long id);

2）给hotel-demo中的`service.impl`包下的HotelService中实现业务：

@Override
    public void deleteById(Long id) {
        
        try {
        
            // 1.准备Request
            DeleteRequest request = new DeleteRequest("hotel", id.toString());
            // 2.发送请求
            client.delete(request, RequestOptions.DEFAULT);
        } catch (IOException e) {
        
            throw new RuntimeException(e);
        }
    }
    
    @Override
    public void insertById(Long id) {
        
        try {
        
            // 0.根据id查询酒店数据
            Hotel hotel = getById(id);
            // 转换为文档类型
            HotelDoc hotelDoc = new HotelDoc(hotel);
    
            // 1.准备Request对象
            IndexRequest request = new IndexRequest("hotel").id(hotel.getId().toString());
            // 2.准备Json文档
            request.source(JSON.toJSONString(hotelDoc), XContentType.JSON);
            // 3.发送请求
            client.index(request, RequestOptions.DEFAULT);
        } catch (IOException e) {
        
            throw new RuntimeException(e);
        }
    }

3）编写监听器

在hotel-demo中的`cn.itcast.hotel.mq`包新增一个类：

@Component
    public class HotelListener {
        
    
        @Autowired
        private IHotelService hotelService;
    
        /**
         * 监听酒店新增或修改的业务
         * @param id 酒店id
         */
        @RabbitListener(queues = MqConstants.HOTEL_INSERT_QUEUE)
        public void listenHotelInsertOrUpdate(Long id){
        
            hotelService.insertById(id);
        }
    
        /**
         * 监听酒店删除的业务
         * @param id 酒店id
         */
        @RabbitListener(queues = MqConstants.HOTEL_DELETE_QUEUE)
        public void listenHotelDelete(Long id){
        
            hotelService.deleteById(id);
        }
    }

--------------------

### es集群搭建 ###

单机的elasticsearch做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。

*  海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点
 *  单点故障问题：将分片数据在不同节点备份（replica ）

**ES集群相关概念**:

*  集群（cluster）：一组拥有共同的 cluster name 的 节点。
 *  节点（node) ：集群中的一个 Elasticearch 实例
 *  分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中

解决问题：数据量太大，单点存储量有限的问题。  
![在这里插入图片描述][1c3ade131e094c09b57b0d3ec7ffb536.png]

> 此处，我们把数据分成3片：shard0、shard1、shard2

*  主分片（Primary shard）：相对于副本分片的定义。
 *  副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

数据备份可以保证高可用，但是每个分片备份一份，所需要的节点数量就会翻一倍，成本实在是太高了！

为了在高可用和成本间寻求平衡，我们可以这样做：

*  首先对数据分片，存储到不同节点
 *  然后对每个分片进行备份，**放到对方节点**，完成**互相备份**

这样可以大大减少所需要的服务节点数量，如图，我们以3分片，每个分片备份一份为例：

![在这里插入图片描述][1d2f34f75e344054ab086146a0586f23.png]  
现在，每个分片都有1个备份，存储在3个节点：

*  node0：保存了分片0和1
 *  node1：保存了分片0和2
 *  node2：保存了分片1和2

--------------------

#### 搭建ES集群 ####

部署es集群可以直接使用docker-compose来完成，不过要求你的Linux虚拟机至少有**8G**的内存空间

4G我试过了，云服务器4G，部署完直接死机，所以至少得8G

首先编写一个docker-compose文件，内容如下：

version: '2.2'
    services:
      es01:
        image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1
        container_name: es01
        environment:
          - node.name=es01
          - cluster.name=es-docker-cluster
          - discovery.seed_hosts=es02,es03
          - cluster.initial_master_nodes=es01,es02,es03
          - bootstrap.memory_lock=true
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
        ulimits:
          memlock:
            soft: -1
            hard: -1
        volumes:
          - data01:/usr/share/elasticsearch/data
        ports:
          - 9200:9200
        networks:
          - elastic
      es02:
        image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1
        container_name: es02
        environment:
          - node.name=es02
          - cluster.name=es-docker-cluster
          - discovery.seed_hosts=es01,es03
          - cluster.initial_master_nodes=es01,es02,es03
          - bootstrap.memory_lock=true
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
        ulimits:
          memlock:
            soft: -1
            hard: -1
        volumes:
          - data02:/usr/share/elasticsearch/data
        networks:
          - elastic
      es03:
        image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1
        container_name: es03
        environment:
          - node.name=es03
          - cluster.name=es-docker-cluster
          - discovery.seed_hosts=es01,es02
          - cluster.initial_master_nodes=es01,es02,es03
          - bootstrap.memory_lock=true
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
        ulimits:
          memlock:
            soft: -1
            hard: -1
        volumes:
          - data03:/usr/share/elasticsearch/data
        networks:
          - elastic
    
    volumes:
      data01:
        driver: local
      data02:
        driver: local
      data03:
        driver: local
    
    networks:
      elastic:
        driver: bridge

把编写好的compose文件上传至虚拟机中  
![在这里插入图片描述][be1c086aed0d4ccdb152a36325a968a2.png]

es运行需要修改一些linux系统权限，修改`/etc/sysctl.conf`文件

vi /etc/sysctl.conf

添加下面的内容：

vm.max_map_count=262144

然后执行命令，让配置生效：

sysctl -p

通过docker-compose启动集群：

docker-compose up -d

这里如果你未找到命令请先去安装 docker compose这个插件！安装完成后即可

![在这里插入图片描述][d47c5dfaf3e04d1789590ec0c585f372.png]

--------------------

> **集群状态监控**

kibana可以监控es集群，不过新版本需要依赖es的x-pack 功能，配置比较复杂。

这里推荐使用cerebro来监控es集群状态，官方网址：[https://github.com/lmenezes/cerebro][https_github.com_lmenezes_cerebro]  
压缩包下载后解压即用  
解压好的目录如下：  
![在这里插入图片描述][ae9d5bf7b1e44beeb46ea7336c7ed686.png]  
进入对应的bin目录：  
![在这里插入图片描述][180e8d7b703c423d84b51339d6ae7f64.png]  
双击其中的cerebro.bat文件即可启动服务。  
访问http://localhost:9000 即可进入管理界面：  
![在这里插入图片描述][2bcf3377777c4ef790715154ead11dfc.png]  
连接上部署的es服务的ip和端口  
![在这里插入图片描述][9a321be915f941009b0dc72530790928.png]

绿色的条，代表集群处于绿色（健康状态）。

--------------------

> **创建索引库**

①在DevTools中输入指令：

PUT /test
    {
        
      "settings": {
        
        "number_of_shards": 3, // 分片数量
        "number_of_replicas": 1 // 副本数量
      },
      "mappings": {
        
        "properties": {
        
          // mapping映射定义 ...
        }
      }
    }

--------------------

②也可以利用cerebro创建索引库  
![在这里插入图片描述][f49de365c87043feb4a740ca709ecb66.png]  
填写索引库信息：  
![在这里插入图片描述][69c90bf6c9ff4642ab2007571b9f1d86.png]  
点击右下角的create按钮：

![在这里插入图片描述][5d2fc15e9fb64e2fa52e06db0debc390.png]  
**查看分片效果**  
![在这里插入图片描述][7bcbda0b126449a2bed64b5392aa2f80.png]

--------------------

#### 集群脑裂问题 ####

elasticsearch中集群节点有不同的职责划分：  
![在这里插入图片描述][f8ed46e061224ef6892fb2d32daa37e1.png]

默认情况下，集群中的任何一个节点都同时具备上述四种角色。

但是真实的集群一定要将集群职责分离：

*  master节点：对CPU要求高，但是内存要求第
 *  data节点：对CPU和内存要求都高
 *  coordinating节点：对网络带宽、CPU要求高

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署。而且避免业务之间的互相干扰。

一个典型的es集群职责划分如图：

![在这里插入图片描述][b0130b2b29da4da6ba140d6ef7c6eeaa.png]  
有星号的为主节点，其余为备选主节点

> **脑裂问题**

脑裂是因为集群中的节点失联导致的。

例如一个集群中，主节点与其它节点失联：  
![在这里插入图片描述][26d542dc20e34f8fa12aa5c8188f5dad.png]  
此时，node2和node3认为node1宕机，就会重新选主：  
![在这里插入图片描述][7540cfe42824458f85052ff1c3db0820.png]  
当node3当选后，集群继续对外提供服务，node2和node3自成集群，node1自成集群，两个集群数据不同步，出现数据差异。

当网络恢复后，因为集群中有两个master节点，集群状态的不一致，出现脑裂的情况：  
![在这里插入图片描述][c6c4559ea5df40ac9eb8372d28145e28.png]  
解决脑裂的方案是，要求选票超过 ( eligible节点数量 + 1 ）/ 2 才能当选为主，因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum\_master\_nodes，在es7.0以后，已经成为默认配置，因此一般不会发生脑裂问题

例如：3个节点形成的集群，选票必须超过 （3 + 1） / 2 ，也就是2票。node3得到node2和node3的选票，当选为主。node1只有自己1票，没有当选。集群中依然只有1个主节点，没有出现脑裂。

> **小结**

master eligible节点的作用是什么？

*  参与集群选主
 *  主节点可以管理集群状态、管理分片信息、处理创建和删除索引库的请求

data节点的作用是什么？

*  数据的CRUD

coordinator节点的作用是什么？

*  路由请求到其它节点
 *  合并查询到的结果，返回给用户

--------------------

#### 集群分布式存储 ####

> *当新增文档时，应该保存到不同分片，保证数据均衡，那么coordinating node如何确定数据该存储到哪个分片*

插入三条数据：  
![在这里插入图片描述][9a0b09e23b804fcd96118efc75e73c51.png]  
插入三次

测试可以看到，三条数据分别在不同分片：  
![在这里插入图片描述][e2a6437f836e4537a29f04f9b51ab4b8.png]

结果如下：

![在这里插入图片描述][4772759a4ed24d7f9f7e5a75ed0e5785.png]

最后在三个分片任意一个中都额可以查出全部数据

> **分片存储原理**

elasticsearch会通过hash算法来计算文档应该存储到哪个分片：  
![在这里插入图片描述][c5f7cb4697a24ce7a74d4803ce6fdc2a.png]  
说明：

*  \_routing默认是文档的id
 *  算法与分片数量有关，因此索引库一旦创建，分片数量不能修改！

**新增文档的流程如下：**  
![在这里插入图片描述][091321b0d2b04b9ab4edf745d8a2438a.png]

**解析**：

*  1）新增一个id=1的文档
 *  2）对id做hash运算，假如得到的是2，则应该存储到shard-2
 *  3）shard-2的主分片在node3节点，将数据路由到node3
 *  4）保存文档
 *  5）同步给shard-2的副本replica-2，在node2节点
 *  6）返回结果给coordinating-node节点

--------------------

#### 集群分布式查询 ####

elasticsearch的查询分成两个阶段：

*  scatter phase：分散阶段，coordinating node会把请求**分发到每一个分片**
 *  gather phase：聚集阶段，coordinating node**汇总**data node的搜索结果，并处理为最终结果集返回给用户

![在这里插入图片描述][679311f921484b4d91ea3ccfebd130e3.png]

--------------------

#### 集群故障转移 ####

集群的master节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。

1）例如一个集群结构如图：  
![在这里插入图片描述][f066959a815d400e85dec07ba0acbe8d.png]  
现在，node1是主节点，其它两个节点是从节点。

2）突然，node1发生了故障：

![在这里插入图片描述][5311ae6a2b1545e185cfbfbfdcc71e55.png]  
宕机后的第一件事，需要重新选主，例如选中了node2：  
![在这里插入图片描述][e307be6eebb34ef6ba1bf9c9a5665cd4.png]  
node2成为主节点后，会检测集群监控状态，发现：shard-1、shard-0没有副本节点。因此需要将node1上的数据迁移到node2、node3：  
![在这里插入图片描述][bba0943dee8e471b89d3b3a867fbb906.png]

[bec3f775feb5430dbe89735af5be3ac5.png]: https://img-blog.csdnimg.cn/bec3f775feb5430dbe89735af5be3ac5.png
[b29ff82ab90342c7a4ecc774f2c64887.png]: https://img-blog.csdnimg.cn/b29ff82ab90342c7a4ecc774f2c64887.png
[db56dc40af2e4686b50cf808d75bb576.png]: https://img-blog.csdnimg.cn/db56dc40af2e4686b50cf808d75bb576.png
[240ee487807642a09428ab8a9c8bda2a.png]: https://img-blog.csdnimg.cn/240ee487807642a09428ab8a9c8bda2a.png
[Link 1]: https://c.163yun.com/hub
[Link 2]: https://cr.console.aliyun.com/
[52d521333fa34f1c863a22ca018dfa8e.png]: https://img-blog.csdnimg.cn/52d521333fa34f1c863a22ca018dfa8e.png
[50522041fdff47478e20a6adb7b936c8.png]: https://img-blog.csdnimg.cn/50522041fdff47478e20a6adb7b936c8.png
[e897c6775daf45088e92862317de1c8e.png]: https://img-blog.csdnimg.cn/e897c6775daf45088e92862317de1c8e.png
[https_cr.console.aliyun.com_cn-hangzhou_instances_mirrors]: https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
[f57dc341fca14626a2d6e668b942f477.png]: https://img-blog.csdnimg.cn/f57dc341fca14626a2d6e668b942f477.png
[73b8f4bac14a4120b51809b479e58013.png]: https://img-blog.csdnimg.cn/73b8f4bac14a4120b51809b479e58013.png
[DockerHub]: https://hub.docker.com/
[1da9d74fd74f4b39a250e073a6dbc4bd.png]: https://img-blog.csdnimg.cn/1da9d74fd74f4b39a250e073a6dbc4bd.png
[038588d7c84a46e3aaba26a55e03bc19.png]: https://img-blog.csdnimg.cn/038588d7c84a46e3aaba26a55e03bc19.png
[8c056baace884daea11b967e9e140caa.png]: https://img-blog.csdnimg.cn/8c056baace884daea11b967e9e140caa.png
[3234cca271d243e594a393b5f0b86a9c.png]: https://img-blog.csdnimg.cn/3234cca271d243e594a393b5f0b86a9c.png
[4428d08388b646d7ac7a620a70f68b9d.png]: https://img-blog.csdnimg.cn/4428d08388b646d7ac7a620a70f68b9d.png
[5ca035bec85d49e180c15a1d97ce1e78.png]: https://img-blog.csdnimg.cn/5ca035bec85d49e180c15a1d97ce1e78.png
[1d778606685e473e808a428e9a803f6b.png]: https://img-blog.csdnimg.cn/1d778606685e473e808a428e9a803f6b.png
[d41cf8800d32484fa7324373d1dc2588.png]: https://img-blog.csdnimg.cn/d41cf8800d32484fa7324373d1dc2588.png
[0b98d32b00e54f98b02df5c88886680a.png]: https://img-blog.csdnimg.cn/0b98d32b00e54f98b02df5c88886680a.png
[4320bdb1ef5c4fc4a6aceb63a249f7dd.png]: https://img-blog.csdnimg.cn/4320bdb1ef5c4fc4a6aceb63a249f7dd.png
[90d5a51f214c49b3883144f4a2b649d2.png]: https://img-blog.csdnimg.cn/90d5a51f214c49b3883144f4a2b649d2.png
[711741ecd2a1467b9369004076ac0bdf.png]: https://img-blog.csdnimg.cn/711741ecd2a1467b9369004076ac0bdf.png
[227485b254634aa7b841ad69a9663144.png]: https://img-blog.csdnimg.cn/227485b254634aa7b841ad69a9663144.png
[406a358c127641c69bccae7bfa504644.png]: https://img-blog.csdnimg.cn/406a358c127641c69bccae7bfa504644.png
[2761efc7c531494f9b668b615c3b8a7a.png]: https://img-blog.csdnimg.cn/2761efc7c531494f9b668b615c3b8a7a.png
[f0b35f55b4624b2bb19757080c41d717.png]: https://img-blog.csdnimg.cn/f0b35f55b4624b2bb19757080c41d717.png
[853e1717f93143b687d158645513dfef.png]: https://img-blog.csdnimg.cn/853e1717f93143b687d158645513dfef.png
[93e1fae002ea4d2383fb9fbe6c09d4db.png]: https://img-blog.csdnimg.cn/93e1fae002ea4d2383fb9fbe6c09d4db.png
[3dcfe59d12e94e9cbd1d9017318c78fb.png]: https://img-blog.csdnimg.cn/3dcfe59d12e94e9cbd1d9017318c78fb.png
[60616f739c12473fa9f4dbb61bfa66cf.png]: https://img-blog.csdnimg.cn/60616f739c12473fa9f4dbb61bfa66cf.png
[e6d4a92c00374d889641452c6f829831.png]: https://img-blog.csdnimg.cn/e6d4a92c00374d889641452c6f829831.png
[c010947102a34d71a7f163f759a2baa7.png]: https://img-blog.csdnimg.cn/c010947102a34d71a7f163f759a2baa7.png
[ee38b67973f14de68af61b8d124f2a16.png]: https://img-blog.csdnimg.cn/ee38b67973f14de68af61b8d124f2a16.png
[5cd94cc581be4193968313ef837ccc94.png]: https://img-blog.csdnimg.cn/5cd94cc581be4193968313ef837ccc94.png
[98b3a3eda5ea448bb6fce96659993842.png]: https://img-blog.csdnimg.cn/98b3a3eda5ea448bb6fce96659993842.png
[46f67cd0ab7a4cbc8c44980ca9bb3c28.png]: https://img-blog.csdnimg.cn/46f67cd0ab7a4cbc8c44980ca9bb3c28.png
[542da36c9cbc4c669401520bea9887f4.png]: https://img-blog.csdnimg.cn/542da36c9cbc4c669401520bea9887f4.png
[31c2e7d38f084913a0c9b348beb7abca.png]: https://img-blog.csdnimg.cn/31c2e7d38f084913a0c9b348beb7abca.png
[75873081a9274bc78ca180e3d53a67a8.png]: https://img-blog.csdnimg.cn/75873081a9274bc78ca180e3d53a67a8.png
[1037d0d26f654627be6125c21e97f4eb.png]: https://img-blog.csdnimg.cn/1037d0d26f654627be6125c21e97f4eb.png
[141f18c8604d4ef99e3a85b0bfbb5417.png]: https://img-blog.csdnimg.cn/141f18c8604d4ef99e3a85b0bfbb5417.png
[a6ef123dfba94b7fb4359722d3bee184.png]: https://img-blog.csdnimg.cn/a6ef123dfba94b7fb4359722d3bee184.png
[cebf6bd21c424578b16144958cf6ba22.png]: https://img-blog.csdnimg.cn/cebf6bd21c424578b16144958cf6ba22.png
[83057f41dcc344c290a8941ffa2e7557.png]: https://img-blog.csdnimg.cn/83057f41dcc344c290a8941ffa2e7557.png
[66d6814f71574520874bf7bd55830a98.png]: https://img-blog.csdnimg.cn/66d6814f71574520874bf7bd55830a98.png
[0229551881974fafa4719e8d29e6b3ad.png]: https://img-blog.csdnimg.cn/0229551881974fafa4719e8d29e6b3ad.png
[807106eafa6d4bdc9dcf60949e7f271c.png]: https://img-blog.csdnimg.cn/807106eafa6d4bdc9dcf60949e7f271c.png
[599d6e92705f43beb072891318b92214.png]: https://img-blog.csdnimg.cn/599d6e92705f43beb072891318b92214.png
[e2cb8060fdd94e35b2bfdfa98c7b7567.png]: https://img-blog.csdnimg.cn/e2cb8060fdd94e35b2bfdfa98c7b7567.png
[5b0c427a55d24f539f036720ea8d992e.png]: https://img-blog.csdnimg.cn/5b0c427a55d24f539f036720ea8d992e.png
[262af2d7e00c40c6936f340e77fd7ac8.png]: https://img-blog.csdnimg.cn/262af2d7e00c40c6936f340e77fd7ac8.png
[39a059cc39a14c378d3d614182cdcd13.png]: https://img-blog.csdnimg.cn/39a059cc39a14c378d3d614182cdcd13.png
[983121e2518742378919fd7dd653968d.png]: https://img-blog.csdnimg.cn/983121e2518742378919fd7dd653968d.png
[ae4ffe8e857240069beaeaab5bd4b503.png]: https://img-blog.csdnimg.cn/ae4ffe8e857240069beaeaab5bd4b503.png
[22e9ab37fb134587a757ab96532088ae.png]: https://img-blog.csdnimg.cn/22e9ab37fb134587a757ab96532088ae.png
[2207ba24f1fb403d902a32d102d62465.png]: https://img-blog.csdnimg.cn/2207ba24f1fb403d902a32d102d62465.png
[cb4a0684d714480fa170613915c02dad.png]: https://img-blog.csdnimg.cn/cb4a0684d714480fa170613915c02dad.png
[dfa6b58f97084659a9d64782a1e909d3.png]: https://img-blog.csdnimg.cn/dfa6b58f97084659a9d64782a1e909d3.png
[9fe854ec19724d938d8d7f636d04e829.png]: https://img-blog.csdnimg.cn/9fe854ec19724d938d8d7f636d04e829.png
[2a3cd29b68374faab4bfacf1b8720de7.png]: https://img-blog.csdnimg.cn/2a3cd29b68374faab4bfacf1b8720de7.png
[85b3c06977e74f14a65e387425e6d628.png]: https://img-blog.csdnimg.cn/85b3c06977e74f14a65e387425e6d628.png
[94957a8498c945f789c5737753cd0a47.png]: https://img-blog.csdnimg.cn/94957a8498c945f789c5737753cd0a47.png
[fb706814a4684dc7a5784faad5d7db15.png]: https://img-blog.csdnimg.cn/fb706814a4684dc7a5784faad5d7db15.png
[b3bb23fde2a54a458b1be53fb0dca600.png]: https://img-blog.csdnimg.cn/b3bb23fde2a54a458b1be53fb0dca600.png
[9302b2f736414a928137f71568d93d25.png]: https://img-blog.csdnimg.cn/9302b2f736414a928137f71568d93d25.png
[b84ef0f873794a05910176b11a5e7fd5.png]: https://img-blog.csdnimg.cn/b84ef0f873794a05910176b11a5e7fd5.png
[195e3641bd874604907828b17c8e8d38.png]: https://img-blog.csdnimg.cn/195e3641bd874604907828b17c8e8d38.png
[04eed0eb811f49e9b8446b65f4d40a2b.png]: https://img-blog.csdnimg.cn/04eed0eb811f49e9b8446b65f4d40a2b.png
[743a7a3fb5ab488e85d839fcc6b66108.png]: https://img-blog.csdnimg.cn/743a7a3fb5ab488e85d839fcc6b66108.png
[7e41369fccb64f65910fc8356b27084c.png]: https://img-blog.csdnimg.cn/7e41369fccb64f65910fc8356b27084c.png
[700741cb3cd04fc98e625b79d0a94f83.png]: https://img-blog.csdnimg.cn/700741cb3cd04fc98e625b79d0a94f83.png
[01bf7fd89e4c48f7ac39be18ba50c0d0.png]: https://img-blog.csdnimg.cn/01bf7fd89e4c48f7ac39be18ba50c0d0.png
[d6debee063f24df7939478d1a0c68fbf.png]: https://img-blog.csdnimg.cn/d6debee063f24df7939478d1a0c68fbf.png
[6b7b710237e54a8e86be3e0725f91c24.png]: https://img-blog.csdnimg.cn/6b7b710237e54a8e86be3e0725f91c24.png
[63629a13640e49d385d9a9ed11ae6ade.png]: https://img-blog.csdnimg.cn/63629a13640e49d385d9a9ed11ae6ade.png
[090217094bc947a68677cf459e27a5c3.png]: https://img-blog.csdnimg.cn/090217094bc947a68677cf459e27a5c3.png
[es_kibana]: https://pan.baidu.com/s/1dq7rQ3u0nxDmg_hS8OiSdg?pwd=icnb
[bd455389b20345b2ac1063b0c142a5cd.png]: https://img-blog.csdnimg.cn/bd455389b20345b2ac1063b0c142a5cd.png
[8fb73d1e7456415faabb0cc2eff7d9b0.png]: https://img-blog.csdnimg.cn/8fb73d1e7456415faabb0cc2eff7d9b0.png
[a77a6a7ec6d24af78439f22e34aab393.png]: https://img-blog.csdnimg.cn/a77a6a7ec6d24af78439f22e34aab393.png
[5a6a94ef52114ff9865580ad55db5497.png]: https://img-blog.csdnimg.cn/5a6a94ef52114ff9865580ad55db5497.png
[c881cedf7cd6405984ad1607da88e8a7.png]: https://img-blog.csdnimg.cn/c881cedf7cd6405984ad1607da88e8a7.png
[afd482ead66e407b801fd19c8d63a5e7.png]: https://img-blog.csdnimg.cn/afd482ead66e407b801fd19c8d63a5e7.png
[65308a9e34ff432cbb6b46875f72702e.png]: https://img-blog.csdnimg.cn/65308a9e34ff432cbb6b46875f72702e.png
[fb1e01fe78d64c5c9ba55586309fc807.png]: https://img-blog.csdnimg.cn/fb1e01fe78d64c5c9ba55586309fc807.png
[1fb8c8192e4647ae81360a38b96f67f5.png]: https://img-blog.csdnimg.cn/1fb8c8192e4647ae81360a38b96f67f5.png
[ac108cd948b04fc2906bba41cd8904a8.png]: https://img-blog.csdnimg.cn/ac108cd948b04fc2906bba41cd8904a8.png
[a20c031b4fb24f088b56a2917a6d5acb.png]: https://img-blog.csdnimg.cn/a20c031b4fb24f088b56a2917a6d5acb.png
[ac25d824e6a74c81973bb75938d6420e.png]: https://img-blog.csdnimg.cn/ac25d824e6a74c81973bb75938d6420e.png
[445f386eca414b2097f45eb1570afdb7.png]: https://img-blog.csdnimg.cn/445f386eca414b2097f45eb1570afdb7.png
[70daa89ea5f042c3a27be58a5ebc1d5c.png]: https://img-blog.csdnimg.cn/70daa89ea5f042c3a27be58a5ebc1d5c.png
[3cf9a7cfedbc45dcb0546bf198a46362.png]: https://img-blog.csdnimg.cn/3cf9a7cfedbc45dcb0546bf198a46362.png
[29f1f7a63ec64a99a9f231463b9feb7d.png]: https://img-blog.csdnimg.cn/29f1f7a63ec64a99a9f231463b9feb7d.png
[cffe9c4104d243d08764d5d11ec90365.png]: https://img-blog.csdnimg.cn/cffe9c4104d243d08764d5d11ec90365.png
[5450d060937a42c18e6b1b8985ecff0b.png]: https://img-blog.csdnimg.cn/5450d060937a42c18e6b1b8985ecff0b.png
[747f9a552d9f4256bb02be0a9bbc8ca3.png]: https://img-blog.csdnimg.cn/747f9a552d9f4256bb02be0a9bbc8ca3.png
[a5c4353ad4c645f39dfb129aba9662ab.png]: https://img-blog.csdnimg.cn/a5c4353ad4c645f39dfb129aba9662ab.png
[a22e852f31ec4c51a3f51f5db8cba9bf.png]: https://img-blog.csdnimg.cn/a22e852f31ec4c51a3f51f5db8cba9bf.png
[4bfca5be58a14f8d92e6d335a6dc4a0f.png]: https://img-blog.csdnimg.cn/4bfca5be58a14f8d92e6d335a6dc4a0f.png
[6e342612606f40a4bdabb8c3094963cb.png]: https://img-blog.csdnimg.cn/6e342612606f40a4bdabb8c3094963cb.png
[1b7baf1eeb0d4a64a884ca3ea1a50625.png]: https://img-blog.csdnimg.cn/1b7baf1eeb0d4a64a884ca3ea1a50625.png
[40de55bd86d643e182208053b49127a9.png]: https://img-blog.csdnimg.cn/40de55bd86d643e182208053b49127a9.png
[7d12963db2c94e8f9cd58b514a60377d.png]: https://img-blog.csdnimg.cn/7d12963db2c94e8f9cd58b514a60377d.png
[42c10ee2581f4ac381f8f3dee731bf9f.png]: https://img-blog.csdnimg.cn/42c10ee2581f4ac381f8f3dee731bf9f.png
[656ea1f75dc14b0d92d0bd58c4029f48.png]: https://img-blog.csdnimg.cn/656ea1f75dc14b0d92d0bd58c4029f48.png
[7ff975aaf4b34183bb65a4af02b15376.png]: https://img-blog.csdnimg.cn/7ff975aaf4b34183bb65a4af02b15376.png
[b4fc546b4b0c4c1a912b62442cf4e093.png]: https://img-blog.csdnimg.cn/b4fc546b4b0c4c1a912b62442cf4e093.png
[4988cc4d12ad49d0b7e5023e69a43eed.png]: https://img-blog.csdnimg.cn/4988cc4d12ad49d0b7e5023e69a43eed.png
[Domain Specific Language]: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html
[54a7cefc384c488a80661a9d59de83f5.png]: https://img-blog.csdnimg.cn/54a7cefc384c488a80661a9d59de83f5.png
[69cc7dee90ee449a8e6e34b9c8fd43e2.png]: https://img-blog.csdnimg.cn/69cc7dee90ee449a8e6e34b9c8fd43e2.png
[7881daf617ca4ced8767bda18e020bae.png]: https://img-blog.csdnimg.cn/7881daf617ca4ced8767bda18e020bae.png
[ec4eaac3179841c7a871bb73b190c943.png]: https://img-blog.csdnimg.cn/ec4eaac3179841c7a871bb73b190c943.png
[502c724da054457fbd2f79f703105cb7.png]: https://img-blog.csdnimg.cn/502c724da054457fbd2f79f703105cb7.png
[ec23814ca6ed4cb5a4708dec4afd49cb.png]: https://img-blog.csdnimg.cn/ec23814ca6ed4cb5a4708dec4afd49cb.png
[c477aa9c74c44fd7aaf76f2795691b12.png]: https://img-blog.csdnimg.cn/c477aa9c74c44fd7aaf76f2795691b12.png
[https_www.elastic.co_guide_en_elasticsearch_reference_current_geo-queries.html]: https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html
[4fbf09582cc24dd3b40bf731371ecc12.gif_pic_center]: https://img-blog.csdnimg.cn/4fbf09582cc24dd3b40bf731371ecc12.gif#pic_center
[c29355e0767e4790a3d2970385af02bf.gif_pic_center]: https://img-blog.csdnimg.cn/c29355e0767e4790a3d2970385af02bf.gif#pic_center
[e231827b137f4e119322660f018f3135.png]: https://img-blog.csdnimg.cn/e231827b137f4e119322660f018f3135.png
[03fdaa3b8b1341cab7020b1ba006f729.png]: https://img-blog.csdnimg.cn/03fdaa3b8b1341cab7020b1ba006f729.png
[c98046886b054e4bb428a1f3379b7d56.png]: https://img-blog.csdnimg.cn/c98046886b054e4bb428a1f3379b7d56.png
[ed40df44198842b3959806f4c42e2a8b.png]: https://img-blog.csdnimg.cn/ed40df44198842b3959806f4c42e2a8b.png
[8e4feedad554456f81dea8efcc0e1742.png]: https://img-blog.csdnimg.cn/8e4feedad554456f81dea8efcc0e1742.png
[8e8c2bde99cc4230b1d1bff9e5f2bcee.png]: https://img-blog.csdnimg.cn/8e8c2bde99cc4230b1d1bff9e5f2bcee.png
[32416e5bce364271bdea064f28f1b6fe.png]: https://img-blog.csdnimg.cn/32416e5bce364271bdea064f28f1b6fe.png
[7e2ffb79933242438ef17ffa9c4378b5.png]: https://img-blog.csdnimg.cn/7e2ffb79933242438ef17ffa9c4378b5.png
[Link 3]: https://www.elastic.co/guide/en/elasticsearch/reference/current/sort-search-results.html
[9b342ea35a784e4f87b54845b8931107.png]: https://img-blog.csdnimg.cn/9b342ea35a784e4f87b54845b8931107.png
[https_lbs.amap.com_demo_jsapi-v2_example_map_click-to-get-lnglat]: https://lbs.amap.com/demo/jsapi-v2/example/map/click-to-get-lnglat/
[4585fd1a0da240b797f9ec4a667296c6.png]: https://img-blog.csdnimg.cn/4585fd1a0da240b797f9ec4a667296c6.png
[b7f39044dce0441ba29c4c0575282146.png]: https://img-blog.csdnimg.cn/b7f39044dce0441ba29c4c0575282146.png
[452a52894ed548849f610aca4971c79c.png]: https://img-blog.csdnimg.cn/452a52894ed548849f610aca4971c79c.png
[Link 4]: https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html
[4f20784c2d324680b2445b2d06169ea5.png]: https://img-blog.csdnimg.cn/4f20784c2d324680b2445b2d06169ea5.png
[5124464678e04036976263d61d29f562.png]: https://img-blog.csdnimg.cn/5124464678e04036976263d61d29f562.png
[4ebcc739d3584dcb9b90a2c3b5619204.png]: https://img-blog.csdnimg.cn/4ebcc739d3584dcb9b90a2c3b5619204.png
[2d26aa25b4f34757a0df2d917e0ef96e.png]: https://img-blog.csdnimg.cn/2d26aa25b4f34757a0df2d917e0ef96e.png
[6ecb6ad4a3fe401e93dff17a3240cee8.png]: https://img-blog.csdnimg.cn/6ecb6ad4a3fe401e93dff17a3240cee8.png
[a624f29a5f664a798cb2d6692933e512.png]: https://img-blog.csdnimg.cn/a624f29a5f664a798cb2d6692933e512.png
[c2b0522af5ad419ebd820d86144b0101.png]: https://img-blog.csdnimg.cn/c2b0522af5ad419ebd820d86144b0101.png
[15177ce24d2a40339efaf12a4e99334f.png]: https://img-blog.csdnimg.cn/15177ce24d2a40339efaf12a4e99334f.png
[bff6becfacdb48f799c9303d76b7e7fa.png]: https://img-blog.csdnimg.cn/bff6becfacdb48f799c9303d76b7e7fa.png
[0df699649e574f7cbfe64e44a66692fa.png]: https://img-blog.csdnimg.cn/0df699649e574f7cbfe64e44a66692fa.png
[ceca09e992a3422fa5de850980d178c9.png]: https://img-blog.csdnimg.cn/ceca09e992a3422fa5de850980d178c9.png
[a9dace4480d74257a11d9c9e48db58a9.png]: https://img-blog.csdnimg.cn/a9dace4480d74257a11d9c9e48db58a9.png
[f6f774ecec17434bbdc85d216c52164f.png]: https://img-blog.csdnimg.cn/f6f774ecec17434bbdc85d216c52164f.png
[ddddbdffc79c47d1a0ac76edda53e615.png]: https://img-blog.csdnimg.cn/ddddbdffc79c47d1a0ac76edda53e615.png
[cc4758a039bb4b74969508da5543464f.png]: https://img-blog.csdnimg.cn/cc4758a039bb4b74969508da5543464f.png
[2afb414996ec4cab80f62adfc437f3a3.png]: https://img-blog.csdnimg.cn/2afb414996ec4cab80f62adfc437f3a3.png
[11dc70e8147241608b0fd57fed95322a.png]: https://img-blog.csdnimg.cn/11dc70e8147241608b0fd57fed95322a.png
[42f0ae87c23547d4a524a305120faa38.png]: https://img-blog.csdnimg.cn/42f0ae87c23547d4a524a305120faa38.png
[c3b144aff7fc4fe08d12e9b5d0b7db9c.png]: https://img-blog.csdnimg.cn/c3b144aff7fc4fe08d12e9b5d0b7db9c.png
[2dfda9ecf3484b309fd3df0b4ae5935a.png]: https://img-blog.csdnimg.cn/2dfda9ecf3484b309fd3df0b4ae5935a.png
[b0a23c04cd9845f1b43c47e1bb6147d5.png]: https://img-blog.csdnimg.cn/b0a23c04cd9845f1b43c47e1bb6147d5.png
[ec065587194a485d88071777f577c2ef.png]: https://img-blog.csdnimg.cn/ec065587194a485d88071777f577c2ef.png
[96fb5d73cb6c43c6971e56ac3496ae14.png]: https://img-blog.csdnimg.cn/96fb5d73cb6c43c6971e56ac3496ae14.png
[4708562b87824ef19439f4e0927dcbcb.png]: https://img-blog.csdnimg.cn/4708562b87824ef19439f4e0927dcbcb.png
[677c4340a9334882b5c543dcd47a7311.png]: https://img-blog.csdnimg.cn/677c4340a9334882b5c543dcd47a7311.png
[501bbd8223ae4f699297353a9fcc77dd.png]: https://img-blog.csdnimg.cn/501bbd8223ae4f699297353a9fcc77dd.png
[3feccf12b4d4424fb6ed805c4935b0ee.png]: https://img-blog.csdnimg.cn/3feccf12b4d4424fb6ed805c4935b0ee.png
[81c3108dffb342bfb702cabecaaa2cc4.png]: https://img-blog.csdnimg.cn/81c3108dffb342bfb702cabecaaa2cc4.png
[685757987fdc4f5f8ff04e0de700aa30.png]: https://img-blog.csdnimg.cn/685757987fdc4f5f8ff04e0de700aa30.png
[231e073b8792416890f2d3db6ee52d70.png]: https://img-blog.csdnimg.cn/231e073b8792416890f2d3db6ee52d70.png
[09000b32d0be419ea765d0a337b096a7.png]: https://img-blog.csdnimg.cn/09000b32d0be419ea765d0a337b096a7.png
[b176e594a2b04a479650c5b8aad78fff.png]: https://img-blog.csdnimg.cn/b176e594a2b04a479650c5b8aad78fff.png
[d43631d7a83f460d92c52bb6ce475fe1.png]: https://img-blog.csdnimg.cn/d43631d7a83f460d92c52bb6ce475fe1.png
[8092ab934d4e45b19b44b399b80fec7e.png]: https://img-blog.csdnimg.cn/8092ab934d4e45b19b44b399b80fec7e.png
[b631779d90b444d6b13e287c23605be5.png]: https://img-blog.csdnimg.cn/b631779d90b444d6b13e287c23605be5.png
[23cc6bf665ac47328b22169c3a347b2d.png]: https://img-blog.csdnimg.cn/23cc6bf665ac47328b22169c3a347b2d.png
[01e8f192a1214059957617a7e7a87975.png]: https://img-blog.csdnimg.cn/01e8f192a1214059957617a7e7a87975.png
[bc9f631bcb9e44779a804397390e4948.png]: https://img-blog.csdnimg.cn/bc9f631bcb9e44779a804397390e4948.png
[6d675f73fc9546ef83b63a24d34971c1.png]: https://img-blog.csdnimg.cn/6d675f73fc9546ef83b63a24d34971c1.png
[9fd44fff61db423cb0ca328fe0727c7d.png]: https://img-blog.csdnimg.cn/9fd44fff61db423cb0ca328fe0727c7d.png
[8dde9b5f73dd421eac51cff428aec8b7.png]: https://img-blog.csdnimg.cn/8dde9b5f73dd421eac51cff428aec8b7.png
[47a20f78f6154ee793d84db9758ad026.png]: https://img-blog.csdnimg.cn/47a20f78f6154ee793d84db9758ad026.png
[https_github.com_medcl_elasticsearch-analysis-pinyin]: https://github.com/medcl/elasticsearch-analysis-pinyin
[8323ffc6c9014aa4b41d1fab7e3e95d0.png]: https://img-blog.csdnimg.cn/8323ffc6c9014aa4b41d1fab7e3e95d0.png
[8a4727ecf6ca4e0793e022fd14853b98.png]: https://img-blog.csdnimg.cn/8a4727ecf6ca4e0793e022fd14853b98.png
[b4f8ca2cf159497a9921dbc6e665bd07.png]: https://img-blog.csdnimg.cn/b4f8ca2cf159497a9921dbc6e665bd07.png
[Completion Suggester]: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/search-suggesters.html
[e3150393d3e14f08bf893a9b92ec4dc4.png]: https://img-blog.csdnimg.cn/e3150393d3e14f08bf893a9b92ec4dc4.png
[159f04a991fb4dd1937f64ddfa4536f3.png]: https://img-blog.csdnimg.cn/159f04a991fb4dd1937f64ddfa4536f3.png
[202e521cdd0646c997714d736bfdf0fc.png]: https://img-blog.csdnimg.cn/202e521cdd0646c997714d736bfdf0fc.png
[9924de5388344de58300ade3c3a5addb.png]: https://img-blog.csdnimg.cn/9924de5388344de58300ade3c3a5addb.png
[7a0e8826f5a949c3a5c791b2d2e00a50.png]: https://img-blog.csdnimg.cn/7a0e8826f5a949c3a5c791b2d2e00a50.png
[cfb8e94b3d1e4e0ba4f4cc98c8bb34a8.png]: https://img-blog.csdnimg.cn/cfb8e94b3d1e4e0ba4f4cc98c8bb34a8.png
[1ff13fd312dd4140a52bda6cb550d781.png]: https://img-blog.csdnimg.cn/1ff13fd312dd4140a52bda6cb550d781.png
[178102cdcf574bbb951cd45a049c7828.png]: https://img-blog.csdnimg.cn/178102cdcf574bbb951cd45a049c7828.png
[362097a9b76f4f14ac9b4a6731946538.png]: https://img-blog.csdnimg.cn/362097a9b76f4f14ac9b4a6731946538.png
[1c3ade131e094c09b57b0d3ec7ffb536.png]: https://img-blog.csdnimg.cn/1c3ade131e094c09b57b0d3ec7ffb536.png
[1d2f34f75e344054ab086146a0586f23.png]: https://img-blog.csdnimg.cn/1d2f34f75e344054ab086146a0586f23.png
[be1c086aed0d4ccdb152a36325a968a2.png]: https://img-blog.csdnimg.cn/be1c086aed0d4ccdb152a36325a968a2.png
[d47c5dfaf3e04d1789590ec0c585f372.png]: https://img-blog.csdnimg.cn/d47c5dfaf3e04d1789590ec0c585f372.png
[https_github.com_lmenezes_cerebro]: https://github.com/lmenezes/cerebro
[ae9d5bf7b1e44beeb46ea7336c7ed686.png]: https://img-blog.csdnimg.cn/ae9d5bf7b1e44beeb46ea7336c7ed686.png
[180e8d7b703c423d84b51339d6ae7f64.png]: https://img-blog.csdnimg.cn/180e8d7b703c423d84b51339d6ae7f64.png
[2bcf3377777c4ef790715154ead11dfc.png]: https://img-blog.csdnimg.cn/2bcf3377777c4ef790715154ead11dfc.png
[9a321be915f941009b0dc72530790928.png]: https://img-blog.csdnimg.cn/9a321be915f941009b0dc72530790928.png
[f49de365c87043feb4a740ca709ecb66.png]: https://img-blog.csdnimg.cn/f49de365c87043feb4a740ca709ecb66.png
[69c90bf6c9ff4642ab2007571b9f1d86.png]: https://img-blog.csdnimg.cn/69c90bf6c9ff4642ab2007571b9f1d86.png
[5d2fc15e9fb64e2fa52e06db0debc390.png]: https://img-blog.csdnimg.cn/5d2fc15e9fb64e2fa52e06db0debc390.png
[7bcbda0b126449a2bed64b5392aa2f80.png]: https://img-blog.csdnimg.cn/7bcbda0b126449a2bed64b5392aa2f80.png
[f8ed46e061224ef6892fb2d32daa37e1.png]: https://img-blog.csdnimg.cn/f8ed46e061224ef6892fb2d32daa37e1.png
[b0130b2b29da4da6ba140d6ef7c6eeaa.png]: https://img-blog.csdnimg.cn/b0130b2b29da4da6ba140d6ef7c6eeaa.png
[26d542dc20e34f8fa12aa5c8188f5dad.png]: https://img-blog.csdnimg.cn/26d542dc20e34f8fa12aa5c8188f5dad.png
[7540cfe42824458f85052ff1c3db0820.png]: https://img-blog.csdnimg.cn/7540cfe42824458f85052ff1c3db0820.png
[c6c4559ea5df40ac9eb8372d28145e28.png]: https://img-blog.csdnimg.cn/c6c4559ea5df40ac9eb8372d28145e28.png
[9a0b09e23b804fcd96118efc75e73c51.png]: https://img-blog.csdnimg.cn/9a0b09e23b804fcd96118efc75e73c51.png
[e2a6437f836e4537a29f04f9b51ab4b8.png]: https://img-blog.csdnimg.cn/e2a6437f836e4537a29f04f9b51ab4b8.png
[4772759a4ed24d7f9f7e5a75ed0e5785.png]: https://img-blog.csdnimg.cn/4772759a4ed24d7f9f7e5a75ed0e5785.png
[c5f7cb4697a24ce7a74d4803ce6fdc2a.png]: https://img-blog.csdnimg.cn/c5f7cb4697a24ce7a74d4803ce6fdc2a.png
[091321b0d2b04b9ab4edf745d8a2438a.png]: https://img-blog.csdnimg.cn/091321b0d2b04b9ab4edf745d8a2438a.png
[679311f921484b4d91ea3ccfebd130e3.png]: https://img-blog.csdnimg.cn/679311f921484b4d91ea3ccfebd130e3.png
[f066959a815d400e85dec07ba0acbe8d.png]: https://img-blog.csdnimg.cn/f066959a815d400e85dec07ba0acbe8d.png
[5311ae6a2b1545e185cfbfbfdcc71e55.png]: https://img-blog.csdnimg.cn/5311ae6a2b1545e185cfbfbfdcc71e55.png
[e307be6eebb34ef6ba1bf9c9a5665cd4.png]: https://img-blog.csdnimg.cn/e307be6eebb34ef6ba1bf9c9a5665cd4.png
[bba0943dee8e471b89d3b3a867fbb906.png]: https://img-blog.csdnimg.cn/bba0943dee8e471b89d3b3a867fbb906.png