随身携带的笑

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

前言
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（依赖）、配置与应用一起打包
②将每个应用放到一个隔离容器去运行，避免互相干扰

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

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

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

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

Docker解决操作系统环境差异

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

结构包括：

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

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

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

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

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

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

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

解决方案如下

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

问题总结

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

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

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

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

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

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

Docker和虚拟机的差异：

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

Docker架构

Docker中有几个重要的概念：

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

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

DockerHub

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

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

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

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

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

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

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

如图：

配置镜像加速

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

比如这里使用阿里云的镜像
参考阿里云的镜像加速文档：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，代表最新版本的镜像

镜像基本命令

案例1从DockerHub拉取nginx镜像并查看镜像
1）首先去镜像仓库搜索nginx镜像，比如DockerHub这个镜像仓库:
有点慢很正常

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

不指定tag就默认最新版本

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

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

命令格式：

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

使用docker save导出镜像到磁盘

运行命令：

docker save -o nginx.tar nginx:latest

先删除本地的nginx镜像：

docker rmi nginx:latest

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

docker load -i nginx.tar

结果：

容器相关操作

容器保护三个状态：

运行：进程正常运行
暂停：进程暂停，CPU不再运行，进程挂起，并不释放内存
停止：进程终止，回收进程占用的内存、CPU等资源

docker run：创建并运行一个容器，处于运行状态
docker pause：让一个运行的容器暂停
docker unpause：让一个容器从暂停状态恢复运行
docker stop：停止一个运行的容器
docker start：让一个停止的容器再次运行
docker rm：删除一个容器

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

最后后面两个参数含义

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

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

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

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

案例-进入容器

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

docker exec -it mn bash

命令解读：

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

不建议在容器中修改文件

练手demo

进入redis客户端

存入键值

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

数据卷

通过上面案例可以看出容器与数据耦合的一些问题，容器内部没有vi编辑器，修改文件很麻烦

要解决这些问题，必须将数据与容器解耦，这就要用到数据卷了。

什么是数据卷

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

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

一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。
这样，我们操作宿主机的/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

小结

数据卷的作用：

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

数据卷操作：

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

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

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

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

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

语法：

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

-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为例，来看看镜像的组成结构：

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

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

用Dockerfile文件来描述构建信息

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

下面构建一个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 .

将构建好的镜像运行

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

基于java8构建Java项目

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

例如，构建java项目的镜像，可以在已经准备了JDK的基础镜像基础上构建。

例如下
需求：基于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创建容器并运行

小结

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

Docker-Compose

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

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

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

上面的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

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

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

最后结果图

部署微服务集群

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

实现思路：

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

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

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

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

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

Compose文件编写

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

（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>

拷贝jar包到部署目录

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

例如user-service：

部署

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

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

docker-compose up -d

最后注意如果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

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

推送拉取镜像
推送镜像到私有镜像服务必须先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

异步通信

初识MQ

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

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

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

同步通讯

下面以用户购物业务为例

Feign调用就属于同步方式，虽然调用可以实时得到结果，但存在下面的问题：

同步调用的优点：

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

同步调用的问题：

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

异步通讯

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

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

还有一个重要的功能解决高并发问题，实现削峰

把一个时间点的大量请求给放入broker中，后台照常处理，不让大量请求直接打向服务，压力由Broker扛着，充当缓冲层。

Broker 是一个像数据总线一样的东西，所有的服务要接收数据和发送数据都发到这个总线上，这个总线就像协议一样，让服务间的通讯变得标准和可控。

优点：

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

缺点：

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

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

MQ常见框架

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

比较常见的MQ实现：

ActiveMQ
RabbitMQ
RocketMQ
Kafka

几种常见MQ的对比：

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

追求可用性：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

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

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

MQ的基本结构：

常见消息模型

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

官方的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的管理界面，可以看到发送的消息

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("等待接收消息。。。。");
    }
}

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

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

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

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

SpringAMQP

什么是SpringAMQP

SpringAMQP提供了三个功能：

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

Basic Queue 简单队列模型

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

消息的发送

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


<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-amqpartifactId>
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 模型，多个消费者共同处理消息处理，速度就能大大提高了。

简单来说就是让多个消费者绑定到一个队列，共同消费队列中的消息。

消息发送

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

在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来控制消费者预取的消息数量

发布/订阅

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

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

发布、订阅模型-Fanout

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

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

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

代码思路

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

声明交换机和队列

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

在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。

在Direct模型下：

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

案例需求如下：

利用@RabbitListener声明Exchange、Queue、RoutingKey
在consumer服务中，编写两个消费者方法，分别监听direct.queue1和direct.queue2
在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个词

例如下图

解释：

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

代码实现思路如下：

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

消息接收

在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服务

发送消息后查看控制台：

配置JSON转换器

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

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

<dependency>
    <groupId>com.fasterxml.jackson.dataformatgroupId>
    <artifactId>jackson-dataformat-xmlartifactId>
    <version>2.9.10version>
dependency>

配置消息转换器。

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

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

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

分布式搜索

初识elasticsearch

ES介绍

elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容

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创建索引，如果要根据关键词搜索，就会使用模糊匹配，而模糊匹配有可能会让索引失效，如下

而索引失效就会进行全表扫描，在数据量很大时，那效率一言难尽。

倒排索引

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

将每一个文档的数据利用算法分词，得到一个个词条
创建表，每行数据包括词条、词条所在文档id、位置等信息
因为词条唯一性，可以给词条创建索引，例如hash表结构索引

ES基本概念

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

文档和字段
elasticsearch是面向 文档Document存储的，可以是数据库中的一条商品数据，一个订单信息。文档数据会被序列化为json格式后存储在elasticsearch中：

而Json文档中往往包含很多的 字段（Field），类似于数据库中的列。

索引和映射

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

例如：

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

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

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

mysql与elasticsearch对比

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

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

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

对安全性要求较高的写操作，使用mysql实现
对查询性能要求较高的搜索需求，使用elasticsearch实现
两者再基于某种方式，实现数据的同步，保证一致性

安装es、kibana

安装elasticsearch

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

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

部署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

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

③浏览器访问测试

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

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

firewall-cmd --reload

点击Dev tools在这个界面中可以编写DSL来操作elasticsearch。并且对DSL语句有自动补全功能。

但是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：最细切分（细腻切分）

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

最细切分

扩展词典

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

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

要拓展ik分词器的词库，只需要修改一个ik分词器目录中的config目录中的IkAnalyzer.cfg.xml文件，文件位置在ik文件夹下的config目录下

然后在IkAnalyzer.cfg.xml文件所在目录下新建一个 ext.dic，可以参考config目录下复制一个配置文件进行修改

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

重启elasticsearch 生效

docker restart es

效果如下

停用词汇

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

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": "[email protected]",
    "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 /索引库名

DELETE /索引库名

修改索引库

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

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

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

小结

文档操作有哪些？

创建文档：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"
    },
    // ...
}

下面来个具体实现来看

查询和删除文档

查询文档

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

语法：

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

通过kibana查看数据：

GET /test/_doc/1

查看结果：

删除文档

删除使用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": "[email protected]",
    "name": {
        "firstName": "云",
        "lastName": "赵"
    }
}

增量修改

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

语法：

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

示例：

POST /test/_update/1
{
  "doc": {
    "email": "[email protected]"
  }
}

小结

文档操作有哪些？

创建文档：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相关表数据

数据结构如下：

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.项目工程搭建

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合并，提供给用户搜索

地理坐标说明：

copy_to说明：

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

分为三步：

1）引入es的RestHighLevelClient依赖：

<dependency>
    <groupId>org.elasticsearch.clientgroupId>
    <artifactId>elasticsearch-rest-high-level-clientartifactId>
dependency>

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

<properties>
    <java.version>1.8java.version>
    <elasticsearch.version>7.12.1elasticsearch.version>
properties>

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();
    }

操作索引库

创建索引库

代码分为三步：

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代码如图：

可以看到与创建索引库类似，同样是三步走：

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);
}

查询文档

查询的DSL语句如下：

GET /hotel/_doc/{id}

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

准备Request对象
发送请求

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

可以看到，结果是一个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);
}

删除文档

删除的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);
}

修改文档

文档修改有两种方式：

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

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

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

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

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

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中，其间都是逗号隔开

结果如下

批量导入文档

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

步骤如下：

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

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

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

可以看到，能添加的请求包括：

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

因此Bulk中添加了多个IndexRequest，就是批量新增功能了。示例：

其实还是三步走：

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

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

初始化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": {
    }
  }
}

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

全文检索查询

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

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

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

基本语法

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

match查询：单字段查询
multi_match查询：多字段查询，任意一个字段符合条件就算符合查询条件

match查询语法如下：

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

mulit_match语法如下：

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

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

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

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

match和multi_match的区别

match：根据一个字段查询
multi_match：根据多个字段查询，参与查询字段越多，查询性能越差

精准查询

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

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

term查询

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

语法说明：

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

如下实例
但是，当我们搜索的内容不是词条，而是多个词语形成的短语时，反而搜索不到：

range查询

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

基本语法：

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

总结

精确查询常见的有哪些？

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

地理坐标查询

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

常见的使用场景包括：

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

矩形范围查询

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

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

语法如下：

// 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）：查询到指定中心点小于某个距离值的所有文档。

换句话来说，在地图上找一个点作为圆心，以指定距离为半径，画一个圆，落在圆内的坐标都算符合条件：

// geo_distance 查询
GET /indexName/_search
{
  "query": {
    "geo_distance": {
      "distance": "15km", // 半径
      "FIELD": "31.21,121.5" // 圆心
    }
  }
}

示例
我们搜索以陆家嘴坐标为圆心，附近15km的酒店：

发现共有47家酒店。

复合查询

复合（compound）查询：复合查询可以将其它简单查询组合起来，实现更复杂的搜索逻辑。常见的有两种：

fuction score：算分函数查询，可以控制文档相关性算分，控制文档排名
bool query：布尔查询，利用逻辑关系组合多个其它的查询，实现复杂搜索

相关性算分

当我们利用match查询时，文档结果会根据与搜索词条的关联度打分（_score），返回结果时按照分值降序排列。

TF-IDF算法有一各缺陷，就是词条频率越高，文档得分也会越高，单个词条对文档影响较大。而BM25则会让单个词条的算分有一个上限，曲线更加平滑：

在后来的5.1版本升级中，elasticsearch将算法改进为BM25算法

算分函数查询

根据相关度打分是比较合理的需求，但合理的不一定是产品经理需要的。

以百度为例，你搜索的结果中，并不是相关度越高排名越靠前，而是谁掏的钱多排名就越靠前。如图：

语法说明

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" // 加权模式，求和
    }
  }
}

测试，在未添加算分函数时，如家得分如下：

添加了算分函数后，如家得分就提升了：

小结

过滤条件：哪些文档要加分
算分函数：如何计算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中

小结

bool查询有几种逻辑关系？

must：必须匹配的条件，可以理解为“与”
should：选择性匹配的条件，可以理解为“或”
must_not：必须不匹配的条件，不参与打分
filter：必须匹配的条件，不参与打分

搜索结果处理

排序

elasticsearch默认是根据相关度算分（_score）来排序，但是也支持自定义方式对搜索结果排序。可以排序字段类型有：keyword类型、数值类型、地理坐标类型、日期类型等。

普通字段排序

keyword、数值、日期类型排序的语法基本一致。

语法：

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "FIELD": "desc"  // 排序字段、排序方式ASC、DESC
    }
  ]
}

排序条件是一个数组，也就是可以写多个排序条件。按照声明的顺序，当第一个条件相等时，再按照第二个条件排序，以此类推

示例：

需求描述：酒店数据按照用户评价（score)降序排序，评价相同的按照价格(price)升序排序

地理坐标排序

这个场景，我们并不陌生，打车，点外卖，去游玩，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/

分页

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条

查询TOP1000，如果es是单点模式，这并无太大影响。

但是elasticsearch将来一定是集群，例如我集群有5个节点，我要查询TOP1000的数据，并不是每个节点查询200条就可以了。

因为节点A的TOP200，在另一个节点可能排到10000名以外了。

因此要想获取整个集群的TOP1000，必须先查询出每个节点的TOP1000，汇总结果后，重新排名，重新截取TOP1000。

如果我要查询9900~10000的数据，要先查询TOP10000，那每个节点都要查询10000条，汇总到内存中，数据过多，对内存压力过大，因此elasticsearch会禁止from+ size 超过10000的请求

针对深度分页，ES提供了两种解决方案，官方文档：

search after：分页时需要排序，原理是从上一次的排序值开始，查询下一页数据。官方推荐使用的方式。
scroll：原理将排序后的文档id形成快照，保存在内存。官方已经不推荐使用。

小结

分页查询的常见实现方案以及优缺点：

from + size：
- 优点：支持随机翻页
- 缺点：深度分页问题，默认查询上限（from + size）是10000
- 场景：百度、京东、谷歌、淘宝这样的随机翻页搜索
after search：
- 优点：没有查询上限（单次查询的size不超过10000）
- 缺点：只能向后逐页查询，不支持随机翻页
- 场景：没有随机翻页需求的搜索，例如手机向下滚动翻页
scroll：
- 优点：没有查询上限（单次查询的size不超过10000）
- 缺点：会有额外内存消耗，并且搜索结果是非实时的
- 场景：海量数据的获取和迁移。从ES7.1开始不推荐，建议用 after search方案。

高亮

我们在百度，京东搜索时，关键字会变成红色，比较醒目，这叫高亮显示

高亮显示的实现分为两步：

1）给文档中的所有关键字都添加一个标签，例如标签

2）页面给标签编写CSS样式

实现高亮

GET /hotel/_search { "query": { "match": { "FIELD": "TEXT" // 查询条件，高亮一定要使用全文检索查询 } }, "highlight": { "fields": { // 指定要高亮的字段 "FIELD": { "pre_tags": "", // 用来标记高亮字段的前置标签//可以不加，不加默认是它 "post_tags": "" // 用来标记高亮字段的后置标签 } } } }

注意：

高亮是对关键字高亮，因此搜索条件必须带有关键字，而不能是范围这样的查询。

默认情况下，高亮的字段，必须与搜索指定的字段一致，否则无法高亮

如果要对非搜索字段高亮，则需要添加一个属性：required_field_match=false

示例：

总结

查询的DSL是一个大的JSON对象，包含下列属性：

query：查询条件

from和size：分页条件

sort：排序条件

highlight：高亮条件

示例：

RestClient查询文档

快速入门

操作几乎和前面的CRUD步骤基本相同
1.导入RestClient的依赖

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

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

<properties> <java.version>1.8java.version> <elasticsearch.version>7.12.1elasticsearch.version> properties>

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的查询请求格式

代码解读：

第一步，创建SearchRequest对象，指定索引库名

第二步，利用request.source()构建DSL，DSL中可以包含查询、分页、排序、高亮等

query()：代表查询条件，利用QueryBuilders.matchAllQuery()构建一个match_all查询的DSL

第三步，利用client.search()发送请求，得到响应

这里关键的API有两个，一个是request.source()，其中包含了查询、排序、分页、高亮等所有功能：

另一个是QueryBuilders，其中包含match、term、function_score、bool等各种查询：

最后解析返回的结果

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); } }

小结

查询的基本步骤是：

创建SearchRequest对象

准备Request.source()，也就是DSL。

① QueryBuilders来构建查询条件

② 传入Request.source() 的 query() 方法

发送请求，得到结果

解析结果（参考JSON结果，从外到内，逐层解析）

match查询

全文检索的match和multi_match查询与match_all的API基本一致。差别是查询条件，也就是query的部分。

因此，Java代码上的差异主要是request.source().query()中的参数了。同样是利用QueryBuilders提供的方法

而结果解析代码则完全一致，可以抽取并共享。

完整代码如下：

@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如下：

@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等方式组合其它查询，代码示例如下：

可以看到，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如下：

完整代码示例：

@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文档数据，还要解析高亮结果

高亮请求构建

述代码省略了查询条件部分，但是大家不要忘了：高亮查询必须使用全文检索查询，并且要有搜索关键字，将来才可以对关键字高亮。

完整代码如下：

@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); }

高亮结果解析

代码解读：

第一步：从结果中获取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版本：

<properties> <java.version>1.8java.version> <elasticsearch.version>7.12.1elasticsearch.version> properties>

其次，把RestClient注册为bean，完成初始化，在启动类中注入bean

@Bean public RestHighLevelClient client(){ return new RestHighLevelClient(RestClient.builder( HttpHost.create("http://47.100.200.177:9200") )); }

定义前端请求参数实体类

@Data public class RequestParams { private String key; private Integer page; private Integer size; private String sortBy; }

定义服务端应该返回的响应结果实体类

分页查询返回分页结果PageResult，包含两个属性：

total：总条数

List：当前页的数据

@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 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对象



酒店结果过滤

需求：添加品牌、城市、星级、价格等过滤功能

传递的参数如图：

包含的过滤条件有：

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中，不参与算分

因为条件构建的逻辑比较复杂，这里先封装为一个函数：

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); }

我周边的酒店

在酒店列表页的右侧，有一个小地图，点击地图的定位按钮，地图会找到你所在的位置：
并且，在前端会发起查询请求，将你的坐标发送到服务端：

我们要做的事情就是基于这个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代码示例：

添加距离排序

@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); } }

排序完成后，页面还要获取我附近每个酒店的具体距离值，这个值在响应结果中是独立的：

我们在结果解析阶段，除了解析source部分以外，还要得到sort部分，也就是排序的距离，然后放到响应结果中。

我们要做两件事：

修改HotelDoc，添加排序距离字段，用于页面显示

修改HotelService类中的handleResponse方法，添加对sort值的获取

1）修改HotelDoc类，添加距离字段distance

2）修改HotelService中的handleResponse方法

最后结果如下图

酒店竞价排名

需求：让指定的酒店在搜索结果中排名置顶
就修改它的相关性分值，分值越高越靠前

要让指定酒店在搜索结果中排名置顶，效果如图：

页面会给指定的酒店添加广告标记。

之前学习过的function_score查询可以影响算分，算分高了，自然排名也就高了。而function_score包含3个要素：

过滤条件：哪些文档要加分

算分函数：如何计算function score

加权方式：function score 与 query score如何运算

这里的需求是：让指定酒店排名靠前。因此我们需要给这些酒店添加一个标记，这样在过滤条件中就可以根据这个标记来判断，是否要提高算分。

比如，我们给酒店添加一个字段：isAD，Boolean类型：

true：是广告

false：不是广告

这样function_score包含3个要素就很好确定了：

过滤条件：判断isAD 是否为true

算分函数：我们可以用最简单暴力的weight，固定加权值

加权方式：可以用默认的相乘，大大提高算分

因此，业务的实现步骤包括：

给HotelDoc类添加isAD字段，Boolean类型

挑选几个你喜欢的酒店，给它的文档数据添加isAD字段，值为true

修改search方法，添加function score功能，给isAD值为true的酒店增加权重

修改HotelDoc实体
HotelDoc类添加isAD字段

添加广告标记
接下来，我们挑几个酒店，添加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查询结构如下：

对应的JavaAPI如下：

可以将之前写的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 // 希望获取的聚合结果数量 } } } }

结果如图：

对聚合结果排序

默认情况下，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 } } } }

这次，聚合得到的品牌明显变少了：

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的聚合内部嵌套的子聚合。因为我们需要在每个桶分别计算。

另外，我们还可以给聚合结果做个排序，例如按照每个桶的酒店平均分做排序：

小结

aggs代表聚合，与query同级，此时query的作用是？

限定聚合的的文档范围

聚合必须的三要素：

聚合名称

聚合类型

聚合字段

聚合可配置属性有：

size：指定聚合结果数量

order：指定聚合结果排序方式

field：指定聚合字段

RestAPI实现聚合

API语法

聚合条件与query条件同级别，因此需要使用request.source()来指定聚合条件。

聚合条件的语法：

聚合的结果也与查询结果不同，API也比较特殊。不过同样是JSON逐层解析：

业务需求

需求：搜索页面的品牌、城市等信息不应该是在页面写死，而是通过聚合索引库中的酒店数据得来的：
也就是每次选择了一个条件以后，栏中内容要发生变化，有相关的留下，没有相关的移除；

比如我先选择了价格100元以下的，那么星级一栏中五钻，四钻就不应该还在了，因为数据中没有100以下的四星，五星酒店

分析：

目前，页面的城市列表、星级列表、品牌列表都是写死的，并不会随着搜索结果的变化而变化。但是用户搜索条件改变时，搜索结果会跟着变化。

例如：用户搜索“东方明珠”，那搜索的酒店肯定是在上海东方明珠附近，因此，城市只能是上海，此时城市列表中就不应该显示北京、深圳、杭州这些信息了。

也就是说，搜索结果中包含哪些城市，页面就应该列出哪些城市；搜索结果中包含哪些品牌，页面就应该列出哪些品牌。

使用聚合功能，利用Bucket聚合，对搜索结果中的文档基于品牌分组、基于城市分组，就能得知包含哪些品牌、哪些城市了。

因为是对搜索结果聚合，因此聚合是限定范围的聚合，也就是说聚合的限定条件跟搜索文档的条件一致。
查看浏览器可以发现，前端其实已经发出了这样的一个请求：

请求参数与搜索文档的参数完全一致。

返回值类型就是页面要展示的最终结果：

结果是一个Map结构：

key是字符串，城市、星级、品牌、价格

value是集合，例如多个城市的名称

业务实现

HotelController中添加一个方法，遵循下面的要求：

请求方式：POST

请求路径：/hotel/filters

请求参数：RequestParams，与搜索文档的参数一致

返回值类型：Map>

代码：

@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; }

自动补全

当用户在搜索框输入字符时，我们应该提示出与该字符有关的搜索项，如图：

这种根据用户输入的字母，提示完整词条的功能，就是自动补全了。

因为需要根据拼音字母来推断，因此要用到拼音分词功能。

拼音分词器

要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。地址：https://github.com/medcl/elasticsearch-analysis-pinyin

安装方式与IK分词器一样，分三步：

①解压

②上传到虚拟机中，elasticsearch的plugin目录

③重启elasticsearch

测试用法如下：

POST /_analyze { "text": "如家酒店还不错", "analyzer": "pinyin" }

结果：

自定义分词器

默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。

elasticsearch中分词器（analyzer）的组成包含三部分：

character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符

tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik_smart

tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等

文档分词时会依次由这三部分来处理文档：

声明自定义分词器的语法如下：

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" } } } }

测试：

总结：

如何使用拼音分词器？

①下载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

同步策略

方案一：同步调用

只适用于单体项目，对于微服务项目，效率既低下又难以维护管理，耦合度很高

基本步骤如下：

hotel-demo对外提供接口，用来修改elasticsearch中的数据

酒店管理服务在完成数据库操作后，直接调用hotel-demo提供的接口

只要数据库更新，elasticsearch就更新，相当于把这个两个操作加到一个事务中

方案二：异步通知

流程如下：

hotel-admin对mysql数据库数据完成增、删、改后，发送MQ消息

hotel-demo监听MQ，接收到消息后完成elasticsearch数据修改

方案三：监听binlog

流程如下：

给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

其中包含了酒店的CRUD功能：

都是mp中的api，直接调用

声明队列和交换机

MQ结构如图：

引入依赖
在hotel-admin、hotel-demo中引入rabbitmq的依赖：

<dependency> <groupId>org.springframework.bootgroupId> <artifactId>spring-boot-starter-amqpartifactId> dependency>

启动mq容器
如果之前run过mq容器，这里只需要

docker start 容器名

如果以前没有run过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

启动后可以访问 ip:15672

添加配置信息
hotel-admin、hotel-demo中需要添加配置信息

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，消息

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）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中

解决问题：数据量太大，单点存储量有限的问题。

此处，我们把数据分成3片：shard0、shard1、shard2

主分片（Primary shard）：相对于副本分片的定义。

副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

数据备份可以保证高可用，但是每个分片备份一份，所需要的节点数量就会翻一倍，成本实在是太高了！

为了在高可用和成本间寻求平衡，我们可以这样做：

首先对数据分片，存储到不同节点

然后对每个分片进行备份，放到对方节点，完成互相备份

这样可以大大减少所需要的服务节点数量，如图，我们以3分片，每个分片备份一份为例：

现在，每个分片都有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文件上传至虚拟机中

es运行需要修改一些linux系统权限，修改/etc/sysctl.conf文件

vi /etc/sysctl.conf

添加下面的内容：

vm.max_map_count=262144

然后执行命令，让配置生效：

sysctl -p

通过docker-compose启动集群：

docker-compose up -d

这里如果你未找到命令请先去安装 docker compose这个插件！安装完成后即可

集群状态监控

kibana可以监控es集群，不过新版本需要依赖es的x-pack 功能，配置比较复杂。

这里推荐使用cerebro来监控es集群状态，官方网址：https://github.com/lmenezes/cerebro
压缩包下载后解压即用
解压好的目录如下：

进入对应的bin目录：

双击其中的cerebro.bat文件即可启动服务。
访问http://localhost:9000 即可进入管理界面：

连接上部署的es服务的ip和端口

绿色的条，代表集群处于绿色（健康状态）。

创建索引库

①在DevTools中输入指令：

PUT /test { "settings": { "number_of_shards": 3, // 分片数量 "number_of_replicas": 1 // 副本数量 }, "mappings": { "properties": { // mapping映射定义 ... } } }

②也可以利用cerebro创建索引库

填写索引库信息：

点击右下角的create按钮：

查看分片效果

集群脑裂问题

elasticsearch中集群节点有不同的职责划分：

默认情况下，集群中的任何一个节点都同时具备上述四种角色。

但是真实的集群一定要将集群职责分离：

master节点：对CPU要求高，但是内存要求第

data节点：对CPU和内存要求都高

coordinating节点：对网络带宽、CPU要求高

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署。而且避免业务之间的互相干扰。

一个典型的es集群职责划分如图：

有星号的为主节点，其余为备选主节点

脑裂问题

脑裂是因为集群中的节点失联导致的。

例如一个集群中，主节点与其它节点失联：

此时，node2和node3认为node1宕机，就会重新选主：

当node3当选后，集群继续对外提供服务，node2和node3自成集群，node1自成集群，两个集群数据不同步，出现数据差异。

当网络恢复后，因为集群中有两个master节点，集群状态的不一致，出现脑裂的情况：

解决脑裂的方案是，要求选票超过 ( 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如何确定数据该存储到哪个分片

插入三条数据：

插入三次

测试可以看到，三条数据分别在不同分片：

结果如下：

最后在三个分片任意一个中都额可以查出全部数据

分片存储原理

elasticsearch会通过hash算法来计算文档应该存储到哪个分片：

说明：

_routing默认是文档的id

算法与分片数量有关，因此索引库一旦创建，分片数量不能修改！

新增文档的流程如下：

解析：

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的搜索结果，并处理为最终结果集返回给用户

集群故障转移

集群的master节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。

1）例如一个集群结构如图：

现在，node1是主节点，其它两个节点是从节点。

2）突然，node1发生了故障：

宕机后的第一件事，需要重新选主，例如选中了node2：

node2成为主节点后，会检测集群监控状态，发现：shard-1、shard-0没有副本节点。因此需要将node1上的数据迁移到node2、node3：