前言

本篇是记录黑马的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 カーネルに基づいており、提供される異なるシステムアプリケーションにすぎません。関数ライブラリ違い

CentOS システムに MySQL アプリケーションの Ubuntu バージョンをインストールすると、MySQL が Ubuntu 関数ライブラリを呼び出すときに、見つからないか一致しないことがわかり、エラーが報告されます。

解決策は次のとおりです

Docker は、呼び出す必要があるシステム (Ubuntu など) 関数ライブラリを使用してユーザープログラムをパッケージ化します。
Docker がさまざまなオペレーティングシステムで実行される場合、Docker はパッケージ化された関数ライブラリに直接基づいており、オペレーティングシステムの Linux カーネルの助けを借りて実行されます。

在这里插入图片描述

問題の結論

Docker は、複雑な依存関係と、大規模なプロジェクトにおけるさまざまなコンポーネントの依存関係の互換性の問題をどのように解決しますか?

Docker を使用すると、開発中にアプリケーション、依存関係、関数ライブラリ、構成をまとめてパッケージ化し、移植可能なイメージを形成できます。
Docker アプリケーションはコンテナーで実行され、サンドボックスメカニズムを使用してそれらを互いに分離します。

Docker は、開発環境、テスト環境、および本番環境の違いの問題をどのように解決しますか?

Docker イメージには、システム関数ライブラリを含む完全なオペレーティング環境が含まれており、システムの Linux カーネルのみに依存するため、任意の Linux オペレーティングシステムで実行できます。

Docker は、アプリケーションを迅速に配信および実行するためのテクノロジーであり、次の利点があります。

プログラム、その依存関係、およびオペレーティング環境をミラーイメージにパッケージ化して、任意の Linux オペレーティングシステムに移行できます。
実行時に分離されたコンテナーを形成するためにサンドボックスメカニズムが使用され、各アプリケーションは互いに干渉しません。
起動も削除もコマンド一行で完了できるので便利で早い

Docker と仮想マシンの違い:

Docker は関数ライブラリをカプセル化するだけで、完全なオペレーティングシステムをシミュレートしません。
docker はシステムプロセスであり、仮想マシンはオペレーティングシステム内のオペレーティングシステムです。
docker はサイズが小さく、起動速度が速く、パフォーマンスが優れています。仮想マシンはサイズが大きく、起動速度が遅く、パフォーマンスは平均的です。

Docker アーキテクチャ

Docker にはいくつかの重要な概念があります。

イメージ: Docker は、イメージと呼ばれる、アプリケーションとその必要な依存関係、関数ライブラリ、環境、構成、およびその他のファイルをまとめてパッケージ化します。

コンテナー: イメージ内のアプリケーションが実行された後に形成されるプロセスはコンテナーですが、Docker はコンテナープロセスを分離し、外部からは見えません。

在这里插入图片描述

DockerHub

非常に多くのオープンソースアプリケーションが存在するため、それらをパッケージ化する作業はしばしば重複します。このような作業の重複を避けるために、GitHub のコード共有と同様に、Redis や MySQL のイメージなどの独自のパッケージ化されたアプリケーションイメージをネットワーク上に配置して共有します。

DockerHub: DockerHub は、公式の Docker イメージホスティングプラットフォームです。このようなプラットフォームは、Docker Registry と呼ばれます。
中国には、 NetEase Cloud Mirror ServiceやAlibaba Cloud Mirror Libraryなど、 DockerHub に似たパブリックサービスもあります。

独自のイメージを DockerHub に共有する一方で、DockerHub からイメージをプルすることもできます。

在这里插入图片描述

Docker を使用してイメージとコンテナーを操作する場合は、Docker をインストールする必要があります。

Docker は、次の 2 つの部分で構成される CS アーキテクチャのプログラムです。

サーバー (サーバー): Docker デーモンプロセス。Docker命令の処理、イメージの管理、コンテナーなどを担当します。
クライアント (クライアント): コマンドまたは 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

ドッカーをインストールする

まず、仮想マシンをインターネットに接続し、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 アプリケーションはさまざまなポートを使用し、ファイアウォール設定を 1 つずつ変更する必要があります。めんどくさいのでファイアウォールは直接閉じることをお勧めします！

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 と同じように、ミラーウェアハウスが外部にあり、アクセス速度が非常に遅いため、Ali のミラーまたは NetEase のミラーに置き換えることができます。

たとえば、Alibaba Cloud のミラーリングの使用については、
Alibaba Cloud のミラーリング高速化に関するドキュメントを参照してください: https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors

単にコピーして貼り付け、Enter キーを押します.
ミラーアクセラレータを構成します
. 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 の基本

ミラー関連操作

镜像的名称组成：

ミラー名は通常、[リポジトリ]:[タグ] の 2 つの部分で構成されます。
タグが指定されていない場合、デフォルトは latest で、イメージの最新バージョンを表します

在这里插入图片描述

镜像基本命令

在这里插入图片描述

ケース 1 DockerHub から nginx イメージをプルしてイメージを表示する1) まず、ミラーウェアハウスに移動して、 DockerHubミラーウェアハウス
などの nginx ミラーを検索します。少し遅くて正常です

在这里插入图片描述

在这里插入图片描述

2) 表示されたイメージ名に従って、必要なイメージをプルし、次のコマンドを使用します: docker pull nginx

タグが指定されていない場合、最新バージョンがデフォルトになります

在这里插入图片描述

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

結果：
在这里插入图片描述

コンテナ関連業務

コンテナーは、次の 3 つの状態を保護します。

running: プロセスは正常に実行されています
中断: プロセスは中断され、CPU は実行されなくなり、プロセスは中断され、メモリは解放されません。
停止: プロセスが終了し、プロセスが占有していたメモリ、CPU、およびその他のリソースを再利用します

docker run: コンテナを作成して実行中の状態で実行します
docker pause: 実行中のコンテナを一時停止します:
docker unpauseコンテナを一時停止状態から再開します: 実行中のコンテナを停止します
docker stop: コンテナ
docker startを停止しますコンテナコンテナが再び実行中です
docker rm: コンテナを削除してください

ケース: nginx コンテナーを作成して実行する

在这里插入图片描述
最後の 2 つのパラメーターの意味

-d: コンテナーをバックグラウンドで実行する
nginx: nginx などのミラー名

コンテナーポートはホストポートにマップされます。マップされたホストポートは変数であり、コンテナーと一致する必要はありません。ここでは 8080 にすることもできます。

在这里插入图片描述

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

コンテナーログを表示し、-f パラメーターを追加して、ログを継続的に表示します

ケース - コンテナに

コンテナに。作成したばかりの nginx コンテナーに入るコマンドは次のとおりです。

docker exec -it mn bash

コマンドの解釈:

docker exec: コンテナーに入り、コマンドを実行します
-it : 現在入っているコンテナ用の標準入出力ターミナルを作成し、コンテナと対話できるようにします
mn : 入るコンテナの名前
bash: コンテナーに入った後に実行されるコマンド。bash は Linux 端末の対話型コマンドです。

在这里插入图片描述

コンテナー内のファイルを変更することはお勧めしません

ハンズオンデモ

在这里插入图片描述

redis クライアントに入る

在这里插入图片描述

キー値を保存する

在这里插入图片描述

RDM ソフトウェアはサーバー IP に接続し、redis に接続して
保存されているキー値を表示します

在这里插入图片描述

データ量

上記のケースから、コンテナとデータの結合にいくつかの問題が見られます.コンテナ内にはvi エディタがないため、ファイルを変更するのは非常に面倒です

. これらの問題を解決するには、データとデータを分離する必要があります.データボリュームを使用する必要があるコンテナー。

データ量とは

データボリューム (ボリューム) は、ホストファイルシステム内のディレクトリを指す仮想ディレクトリです。

データボリュームは、サーバーホストとコンテナーの間の架け橋です。

在这里插入图片描述
一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。
这样，我们操作宿主机的/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コンテナ内のデータ格納ディレクトリにマウント

②mysqlコンテナの設定ファイルに/tmp/mysql/conf/hmy.cnfをマウント

③MySQLのパスワードを設定する

要約する

docker run のコマンドでは、ファイルまたはディレクトリが -v パラメーターを使用してコンテナーにマウントされます。

-v ボリューム名: コンテナ内のディレクトリ
-v ホストファイル: コンテナー内のファイル
-v ホストディレクトリ: コンテナーディレクトリ

データボリュームのマウントとディレクトリの直接マウント

データボリューム実装の結合度が低く、ディレクトリはdockerで管理しているが、ディレクトリが深くて見つけにくい
ディレクトリのマウントの結合度が高く、ディレクトリを自分で管理する必要がありますが、ディレクトリは簡単に見つけて表示できます

Dockerfile カスタムイメージ

一般的なイメージは DockerHub で見つけることができますが、自分で作成するプロジェクトの場合、自分でイメージをビルドする必要があります。

ミラーリング構造
ミラーリングは、アプリケーションと、それらに必要なシステム機能ライブラリ、環境、構成、および依存関係のパッケージです。
ミラーとは簡単に言えば、システムの機能ライブラリや動作環境をもとに、アプリケーションファイルや設定ファイル、依存ファイルなどを組み合わせて追加し、起動スクリプトを書いてパッケージ化したファイルです。

ミラーリングは階層構造であり、各レイヤーはレイヤーと呼ばれます
BaseImage层: 基本的なシステム関数ライブラリ、環境変数、およびファイルシステムが含まれます
Entrypoint: エントリは、ミラーでアプリケーションを起動するコマンドです
其它: 依存関係を追加し、プログラムをインストールし、完了しますBaseImage のインストールと構成に基づくアプリケーション全体

例として MySQL を取り上げて、イメージの構成構造を確認します。
在这里插入图片描述

カスタムイメージをビルドする場合、各ファイルをコピーしてパッケージ化する必要はありません。

イメージの構成、必要な BaseImage、コピーする必要のあるファイル、インストールする必要のある依存関係、Dockerfile への起動スクリプトを追加するだけです。

Dockerfile を使用してビルド情報を記述する

Dockerfileは、イメージをビルドするために実行する操作を説明する命令を使用して、命令 (Instructions) を1 つずつ含むテキストファイルです。各命令はレイヤーを形成します

在这里插入图片描述

以下のデモンストレーションとして 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 圧縮パッケージを直接ここに置くと、ダウンロードが速くなります
ダウンロードアドレス
抽出コードを作成: 8tfx

ダウンロードしたファイルを/usr/local/bin/ディレクトリにアップロードします。

2.ファイルのアクセス許可を変更する

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

在这里插入图片描述

3.ベースオートコンプリート
コマンドを追加①

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

コピペして順番に実行するだけこれも私ピットイン後のまとめ順、それ以外の場合はダウンロードを続けます

最終結果グラフ
在这里插入图片描述

マイクロサービスクラスターをデプロイする

要件: Docker Compose を使用して、以前に学習した cloud-demo マイクロサービスクラスターをデプロイする

実装のアイデア:

①docker-composeファイルを書いてプロジェクトイメージをビルドする

② 自作のcloud-demoプロジェクトを修正し、docker-composeでデータベースとnacosアドレスをサービス名として命名

③Mavenパッケージングツールを使用して、プロジェクト内の各マイクロサービスをapp.jarとしてパッケージ化します

④ パッケージ化された app.jar を cloud-demo の対応する各サブディレクトリにコピーします

⑤ cloud-demo を仮想マシンにアップロードし、docker-compose up -d でデプロイ

構成ファイルの書き込み

各マイクロサービスは、個別のディレクトリを準備します。

在这里插入图片描述
(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服务地址

元のローカルホストをコンテナー名 nacos に置き換え、MySQL ローカルホストも置き換える必要があります

パック

次に、各マイクロサービスをパッケージ化する必要があります。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 は、サービス名に対応するディレクトリに配置されます。間違えないようにしてください。

たとえば、ユーザーサービス:
在这里插入图片描述

配備

最後に、cloud-demo フォルダー全体を仮想マシンにアップロードし、DockerCompose を介してデプロイする必要があります。

次に、cloud-demo ディレクトリに入り、次のコマンドを実行します。

docker-compose up -d

在这里插入图片描述

最後に、nacos の起動が遅すぎると、他のサービスが接続に失敗し、エラーが報告されることに注意してください. 最後に、nacos 以外のサービスを再起動すると、接続が成功します.

Docker ミラーウェアハウス

DockerHub、ミラーウェアハウス (Docker Registry) などのミラーウェアハウスには、パブリックとプライベートの 2 つの形態があり、通常、企業は独自のプライベートミラーウェアハウスを構築します。

以下では、ローカルで非公開の Docker Registry を構築し
、Docker が提供する公式の Docker Registry に基づいてミラーウェアハウスを構築する方法を紹介します。

ミラーウェアハウスの簡易バージョン
Docker の公式 Docker レジストリは、完全なウェアハウス管理機能を備えた 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接收，订阅者可以按照自己的速度去处理事件

缺点：

構造が複雑で、ビジネスに明確なプロセスラインがなく、管理が難しい
ブローカーの信頼性、セキュリティ、およびパフォーマンスに依存する必要がある

結果を返すには適時性が必要なため、ほとんどのシナリオで同期呼び出しが使用されます。非同期呼び出しは、同時実行性の高いビジネスでのみ使用されます。

MQ 共通フレームワーク

MQ、中国語はメッセージキュー (MessageQueue)、文字通りメッセージを格納するためのキューです。つまり、イベント駆動型アーキテクチャのブローカーです。

より一般的な MQ の実装:

アクティブMQ
RabbitMQ
ロケットMQ
カフカ

いくつかの一般的な MQ の比較:

	RabbitMQ	アクティブMQ	ロケットMQ	カフカ
会社・地域	うさぎ	アパッチ	アリ	アパッチ
開発言語	アーラン	ジャワ	ジャワ	Scala&Java
プロトコルのサポート	AMQP、XMPP、SMTP、STOMP	OpenWire、STOMP、REST、XMPP、AMQP	カスタムプロトコル	カスタムプロトコル
可用性	高い	一般的	高い	高い
スタンドアロンのスループット	一般的	違い	高い	すごく高い
メッセージの遅延	マイクロ秒レベル	ミリ秒	ミリ秒	ミリ秒以内
メッセージの信頼性	高い	一般的	高い	一般的

可用性の追求: Kafka、RocketMQ、RabbitMQ

信頼性の追求：RabbitMQ、RocketMQ

スループットの追求：RocketMQ、Kafka

低メッセージ遅延の追求: RabbitMQ、Kafka

RabbitMQ クイックスタート

RabbitMQ の概要とインストール

①rabbitmq:mirrorのインストール

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

在这里插入图片描述

サーバーの場合は、ファイアウォールにオープンルールを追加します

次に、MQ の管理インターフェイスにアクセスするための ip+port 番号、アカウントのパスワードは自分で設定するだけです。

在这里插入图片描述

MQ の基本構造:
在这里插入图片描述

共通メッセージモデル

2 つのメッセージキューと 3 つのサブスクリプションモード

在这里插入图片描述

在这里插入图片描述
公式の HelloWorld は、最も基本的なメッセージキューモデルに基づいて実装されており、次の 3 つのロールのみが含まれます。

パブリッシャー: メッセージパブリッシャー、メッセージをキューキューに送信します
queue: メッセージの受け入れとキャッシュを担当するメッセージキュー
consumer: キューにサブスクライブし、キュー内のメッセージを処理します

クイックスタート

次に、HelloWorld の基本的なメッセージキューを実装します。

アイデア:

接続を確立する
チャネルを作成する
キューを宣言する
メッセージを送ります
接続とチャネルを閉じる

パブリッシャーの実装

コードのアイデア:

接続を確立する
チャネルを作成する
キューを宣言する
メッセージを送ります
接続とチャネルを閉じる

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の管理インターフェースにアクセスすると、送信されたメッセージが表示されます

在这里插入图片描述

コンシューマー実装

コードのアイデア:

接続を確立する
チャネルを作成する
キューを宣言する
ニュースを購読する

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. 接続を確立する
2. チャネルを作成する
3. チャネルを使用してキューを宣言する
4. チャネルを使用してメッセージをキューに送信する

基本的なメッセージキューのメッセージ受信プロセス:
1. 接続を確立する
2. チャネルを作成する
3. チャネルを使用してキューを宣言する
4. コンシューマの消費動作を定義する handleDelivery()
5. チャネルを使用してコンシューマを列

送信コードと受信コードをどちらが最初に実行し、誰が後で実行するかは明確ではないため、送信と受信の両方で接続、チャネル、およびキューを繰り返し確立して二重保険を確立しますが、誰が実行しても接続チャネルとキューが確実に確立されるようにする必要があります。存在する必要があります。

スプリングAMQP

春のAMQPとは

在这里插入图片描述

Spring AMQP は、次の 3 つの機能を提供します。

キュー、エクスチェンジ、およびそれらのバインディングの自動宣言
メッセージを非同期的に受信するアノテーションベースのリスナーモード
メッセージを送信するための RabbitTemplate ツールをカプセル化します

Basic Queue 単純なキューモデル

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

消息的发送

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

<!--AMQP依赖，包含RabbitMQ-->
<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 模型，多个消费者共同处理消息处理，速度就能大大提高了。
在这里插入图片描述
简单来说就是让多个消费者绑定到一个队列，共同消费队列中的消息。

消息发送

大量のメッセージの蓄積をシミュレートするためにループで送信します。

パブリッシャーサービスの 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);
    }
}

メッセージ受信

同じキューにバインドする複数のコンシューマをシミュレートするために、コンシューマサービスの 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);
}

コンシューマーは 1000 秒間スリープし、シミュレーションタスクには時間がかかることに注意してください。

テストを実行

ConsumerApplication を起動したら、発行者サービスに先ほど記述した送信テストメソッド testWorkQueue を実行します。

コンシューマ 1 が 25 個のメッセージをすばやく完了したことがわかります。コンシューマ 2 は、自身の 25 個のメッセージをゆっくりと処理しています。

つまり、メッセージは各コンシューマに均等に分散され、コンシューマの処理能力は考慮されません。これは明らかに問題です。

有能な人はもっと仕事をするべきだ
メッセージのプリフェッチとは、まずメッセージを割り当て、割り当てが完了した後に処理することであり、これがメッセージのプリフェッチです。
この問題を解決できる春の簡単な構成があります。コンシューマーサービスの application.yml ファイルを変更し、構成を追加します。

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

コンシューマのアプリケーション起動クラスを有効にせずに再起動します

要約する

Work モデルの使用:

複数のコンシューマーがキューにバインドされ、同じメッセージが 1 つのコンシューマーによってのみ処理されます
prefetch を設定して、コンシューマによってプリフェッチされるメッセージの数を制御します

パブリッシュ/サブスクライブ

在这里插入图片描述

ご覧のとおり、サブスクリプションモデルでは交換の役割が追加され、プロセスが少し変更されています。

パブリッシャー: プロデューサー、つまり、メッセージを送信するプログラムですが、キューには送信されず、X (交換) に送信されます。
交換：スイッチ、図中のX。一方では、プロデューサーから送信されたメッセージを受信します。一方、メッセージを特定のキューに配信する、すべてのキューに配信する、メッセージを破棄するなど、メッセージの処理方法を知ること。どのように機能するかは、Exchange の種類によって異なります。Exchange には、次の 3 つのタイプがあります。
- ファンアウト: ブロードキャストし、交換にバインドされたすべてのキューにメッセージを渡します
- Direct: 指定されたルーティングキーに一致するキューにメッセージを配信します。
- トピック: ワイルドカード、ルーティングパターン (ルーティングパターン) に一致するキューにメッセージを送信します
コンシューマ: コンシューマは、以前と同様に、キューにサブスクライブします。変更はありません
キュー: メッセージキューは以前と同じで、メッセージを受信してメッセージをバッファリングします。

パブリッシュ、サブスクライブモデル - ファンアウト

ファンアウト、英訳はファンアウト、MQ でブロードキャストと呼んだ方が適切だと思います

在这里插入图片描述

ブロードキャストモードでのメッセージ送信プロセスは次のとおりです。

1）複数のキューが存在する可能性があります
2) 各キューは Exchange にバインドする必要があります (exchange)
3) プロデューサーによって送信されたメッセージはスイッチにのみ送信でき、スイッチはどのキューに送信するかを決定し、プロデューサーは決定できません。
4) スイッチはメッセージをすべてのバインドされたキューに送信します。
5)キューにサブスクライブするコンシューマはメッセージを取得できます

コードのアイデア

スイッチ itcast.fanout を作成します。タイプは Fanout です
スイッチ itcast.fanout にバインドされた 2 つのキュー fanout.queue1 および fanout.queue2 を作成します。

在这里插入图片描述

交換とキューを宣言する

Spring は、さまざまなタイプのスイッチを表すインターフェース Exchange を提供します。

在这里插入图片描述

キューとスイッチを宣言するクラスをコンシューマーに作成します。

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

メッセージを送る

パブリッシャーサービスの SpringAmqpTest クラスにテストメソッドを追加します。

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

メッセージ受信

コンシューマサービスの SpringRabbitListener にコンシューマとして 2 つのメソッドを追加します。

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

まとめ

スイッチの役割は何ですか？

パブリッシャーから送信されたメッセージを受信する
ルールに従って、バインドされたキューにメッセージをルーティングします
メッセージをキャッシュできない、ルーティングが失敗する、メッセージが失われる
FanoutExchange は、バインドされた各キューにメッセージをルーティングします

キュー、スイッチ、バインディング関係を宣言する Bean は何ですか?

列
ファンアウト交換
バインディング

パブリッシュ、サブスクライブモデルダイレクト

ファンアウトモードでは、メッセージはサブスクライブされたすべてのキューによって消費されます。ただし、シナリオによっては、異なるメッセージを異なるキューで消費する必要があります。このとき、Exchange の Direct タイプが使用されます。

在这里插入图片描述

直接モデルでは:

キューとスイッチ間のバインドは任意ではありませんが、RoutingKey(ルーティングキー)を指定する必要があります
メッセージの送信者は、メッセージを Exchange に送信するときにメッセージ ID も指定する必要がありますRoutingKey。
Exchange はバインドされた各キューにメッセージを配信するのではなく、Routing Keyメッセージに基づいて判断し、キューがRoutingkeyメッセージとRouting key完全にた場合にのみメッセージを受信します。

ケースの要件は次のとおりです。

@RabbitListener を使用して Exchange、Queue、RoutingKey を宣言する
コンシューマーサービスで、2 つのコンシューマーメソッドを記述して、direct.queue1 と direct.queue2 をそれぞれリッスンします。
パブリッシャーにテストメソッドを記述し、itcast.direct にメッセージを送信します。

アノテーションに基づいてキューと交換を宣言する

@Bean に基づいてキューとスイッチを宣言するのは面倒ですが、Spring はアノテーションベースの宣言も提供します。

コンシューマーの SpringRabbitListener に 2 つのコンシューマーを追加し、アノテーションに基づいてキューとスイッチを宣言します。

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

メッセージを送る

パブリッシャーサービスの SpringAmqpTest クラスにテストメソッドを追加します。

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

要約する

ダイレクトスイッチとファンアウトスイッチの違いを説明してください。

ファンアウト交換は、バインドされた各キューにメッセージをルーティングします
ダイレクトスイッチは、RoutingKey に従ってルーティングするキューを決定します。
複数のキューが同じ RoutingKey を持つ場合のファンアウト機能と同様

@RabbitListener アノテーションに基づいてキューとエクスチェンジを宣言するための一般的なアノテーションは何ですか?

@列
@エクスチェンジ

パブリッシュ、サブスクライブモデルトピック

Topic他のタイプExchangeと比較してDirect、メッセージはRoutingKeyタイプに応じて異なるキューにルーティングできます。Topicバインド時にキューがワイルドカードを使用できるようにExchangeするだけですRouting key。

Routingkey通常、これは 1 つ以上の単語で構成され、複数の単語は「.」で区切られます。次に例を示します。item.insert

ワイルドカードの規則:

#: 1 つ以上の単語に一致

*: 正確に 1 つの単語に一致

たとえば、次の図

在这里插入图片描述
説明：

Queue1: は bind であるchina.#ため、でchina.始まるrouting key一致します。china.news と china.weather を含む
Queue2: バインドはである#.newsため、で.news終わるrouting key一致します。china.news と japan.news を含む

コード実装の考え方は次のとおりです。

@RabbitListener を使用して、Exchange、Queue、RoutingKey を宣言します。
コンシューマーサービスで、topic.queue1 と topic.queue2 をリッスンする 2 つのコンシューマーメソッドをそれぞれ記述します。
パブリッシャーにテストメソッドを記述し、メッセージを itcast.topic に送信します。

在这里插入图片描述

メッセージ受信

コンシューマーサービスの 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);
}

まとめ

ダイレクトスイッチとトピックスイッチの違いを説明してください。

トピックスイッチによって受信されるメッセージ 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);
}

コンシューマーサービスを停止する

メッセージを送信した後、コンソールを確認します。

在这里插入图片描述

JSON コンバーターを構成する

明らかに、JDK のシリアル化方法は適切ではありません。メッセージ本文を小さくして読みやすくしたいので、シリアル化と逆シリアル化に JSON メソッドを使用できます。

パブリッシャーサービスとコンシューマーサービスの両方に依存関係を導入します (参照の繰り返しを避けるために、親プロジェクトに依存関係を追加するだけです)。

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

こうして得られたメッセージが本来の内容です。

在这里插入图片描述

分散検索

エラスティックサーチを理解する

エス紹介

Elasticsearch は、膨大な量のデータから必要なものをすばやく見つけるのに役立つ多くの強力な機能を備えた非常に強力なオープンソース検索エンジンです。
在这里插入图片描述

ELK テクノロジースタックの
Elasticsearch は、キバナ、Logstash、Beats を組み合わせたエラスティックスタック (ELK) です。ログデータの分析、リアルタイム監視などの分野で広く使用されています

Elasticsearch はエラスティックスタックのコアであり、データの保存、検索、分析を担当します。

lucene と比較して、elasticsearch には次の利点があります。

分散型の水平展開をサポート
どの言語からでも呼び出せる Restful インターフェイスを提供する

エラスティックサーチとは？

検索、ログ統計、分析、システム監視などの機能を実装するために使用できるオープンソースの分散型検索エンジン

エラスティックスタック (ELK) とは何ですか?

Beats、Logstash、kibana、elasticsearchなどelasticsearchを核とした技術スタック

ルセンとは？

検索エンジンのコア API を提供する Apache のオープンソース検索エンジンクラスライブラリです。

逆インデックス

転置インデックスの概念は、MySQL のような順方向インデックスに基づいています。一般に、検索エンジンは逆索引を使用してキーワードに基づいて検索します。

順方向インデックスは、データベーステーブルの id に基づいてインデックスを作成することです. キーワードに基づいて検索する場合は、あいまい一致を使用します. あいまい一致はインデックスを無効にする可能性があります. インデックスが失敗した場合は、テーブル全体を次のようにスキャンします.
在这里插入图片描述
ボリュームが大きい場合、効率を説明するのは困難です。

逆インデックス

転置インデックスの作成は、順方向インデックスの特別な処理であり、そのプロセスは次のとおりです。

アルゴリズムを使用して各ドキュメントのデータをセグメント化し、各エントリを取得します
テーブルを作成します。データの各行には、エントリ、エントリが配置されているドキュメント ID、場所などの情報が含まれます
エントリの一意性により、エントリのインデックス (ハッシュテーブル構造インデックスなど) を作成できます。

ESの基本的な考え方

Elasticsearch には多くの独自の概念があり、mysql とは少し異なりますが、類似点もあります。

ドキュメントとフィールド
elasticsearchは、データベース内の商品データまたは注文情報である可能性があるドキュメント用に保存されます。ドキュメントデータは json 形式にシリアル化され、elasticsearch に格納されます。Jsonドキュメント
在这里插入图片描述
には、データベースの列と同様に、多くのフィールド (フィールド) が含まれることがよくあります。

インデックスとマップ

インデックス (インデックス)、つまり同じ種類のドキュメントのコレクション。

例えば：

すべてのユーザードキュメントは、ユーザーインデックスと呼ばれるまとめて整理できます。
すべての商品のドキュメントはまとめて整理でき、商品インデックスと呼ばれます。
すべての注文のドキュメントはまとめて整理できます。これは注文のインデックスと呼ばれます。

在这里插入图片描述

したがって、インデックスはデータベース内のテーブルと考えることができます。

データベースのテーブルには、テーブルの構造、フィールドの名前とタイプ、およびその他の情報を定義するために使用される制約情報があります。したがって、テーブルの構造上の制約と同様に、インデックス内のドキュメントのフィールド制約情報であるインデックスライブラリ内のマッピングがあります。

mysql と Elasticsearch の比較

在这里插入图片描述

どちらも得意分野があり、補完関係にある

Mysql: トランザクションタイプの操作が得意で、データのセキュリティと一貫性を確保できます
Elasticsearch: 膨大なデータのキーワード検索、分析、計算が得意

通常、2 つの組み合わせが使用されます。

高度なセキュリティ要件を伴う書き込み操作の場合、mysql を使用して実装します
高いクエリパフォーマンスを必要とする検索要件については、elasticsearch を使用して達成します。
2つは、データの同期を実現し、一貫性を確保するための特定の方法に基づいています

es、kibanaをインストール

エラスティックサーチをインストールする

①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 ファイルを使用して、拡張辞書と無効な辞書を追加します。
拡張エントリまたは無効なエントリを辞書に追加します。

索引ライブラリ操作

インデックスライブラリはデータベーステーブルに似ており、マッピングマッピングはテーブル構造に似ています。

es にデータを保存する場合は、まず「ライブラリ」と「テーブル」を作成する必要があります。

マッピングマッピングプロパティ

マッピングは、インデックスライブラリ内のドキュメントに対する制約です。一般的なマッピング属性には次のものがあります。

type: フィールドデータ型。一般的な単純型は次のとおりです。
- 文字列:テキスト(単語分割テキスト)、キーワード(正確な値。例: ブランド、国、IP アドレスには単語分割テキストは必要ありません)
- 値: long、integer、short、byte、double、float、
- ブール値: ブール値
- 日付: 日付
- オブジェクト: オブジェクト
index: インデックスを作成するかどうか。デフォルトは true (画像の URL など、転置インデックスをすべて作成する必要があるわけではありません。転置インデックスの作成は役に立ちません)。
アナライザー: 使用するトークナイザー
プロパティ: このフィールドのサブフィールド

たとえば、次の json ドキュメント:

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

各フィールドのマッピング (マッピング) に対応:

age: 型は整数です; 検索に参加するので、インデックスは true である必要があります; トークナイザーは必要ありません
重量: 型は float です。検索に参加するため、インデックスが true である必要があります。トークナイザーは必要ありません。
isMarried: タイプはブール値です。検索に参加するため、インデックスは true である必要があります。トークナイザーは必要ありません。
情報: タイプは文字列で、単語のセグメンテーションが必要なためテキストです; 検索に参加するには、インデックスが true である必要があります; 単語セグメンタは ik_smart を使用できます
email: タイプは文字列ですが、単語の分割は必要ないのでキーワードです; 検索に参加しないので、インデックスを false にする必要があります; 単語の分割は必要ありません
スコア: 配列ですが、float である要素の型のみを調べます。検索に参加するため、インデックスが true である必要があります。トークナイザーは必要ありません。
name: タイプはオブジェクトで、複数のサブ属性を定義する必要があります
- name.firstName; タイプは文字列ですが、単語の分割は不要なのでキーワードです; 検索に参加するため、インデックスが true である必要があります; 単語の分割は必要ありません
- name.lastName; タイプは文字列ですが、単語の分割は不要なのでキーワードです; 検索に参加するため、インデックスが true である必要があります; 単語の分割は必要ありません

まとめ

マッピングの一般的な属性は何ですか?
type: データ型
index: インデックスを付けるかどうか
アナライザー: トークナイザー
プロパティ: サブフィールド

タイプの一般的なタイプは何ですか？
文字列: テキスト、キーワード
数値: long、integer、short、byte、double、float
Boolean: boolean
Date: 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中，因为不会对倒排索引产生影响。
如下示例

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 との接続を確立する必要があります。

次の 3 つのステップに分けられます。

1) es の RestHighLevelClient 依存関係を導入します。

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

2) SpringBoot のデフォルトの ES バージョンは 7.6.2 であるため、デフォルトの ES バージョンをオーバーライドする必要があります。

<properties>
    <java.version>1.8</java.version>
    <elasticsearch.version>7.12.1</elasticsearch.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();
    }

操作索引ライブラリ

インデックスライブラリを作成する

在这里插入图片描述

コードは次の 3 つのステップに分かれています。

1) Request オブジェクトを作成します。インデックスライブラリを作成する操作であるため、Request は CreateIndexRequest です。
2) リクエストパラメータの追加は、実際には DSL の JSON パラメータ部分です。json 文字列は非常に長いため、静的な文字列定数 MAPPING_TEMPLATE をここで定義して、コードをより洗練されたものにします。
3) リクエストを送信するために、client.indices() メソッドの戻り値は、インデックスライブラリ操作に関連するすべてのメソッドをカプセル化した IndicesClient 型です。

hotel-demo の cn.hotel.constants パッケージの下に、マッピングマッピングの 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 オブジェクトに反映される必要があります。それはまだ3つのステップです：

1) Request オブジェクトを作成します。今回は DeleteIndexRequest オブジェクトです
2) パラメータを準備します。ここにパラメータはありません
3) リクエストを送信します。代わりに削除メソッドを使用してください

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 コードフローに似ています。それはまだ3つのステップです：

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 ? "索引库已经存在！" : "索引库不存在！");
}

要約する

Elasticsearch を操作する JavaRestClient のプロセスは、基本的に同様です。コアは、インデックスライブラリの操作オブジェクトを取得する client.indices() メソッドです。

インデックスライブラリ操作の基本的な手順:

RestHighLevelClient の初期化
XxxIndexRequest を作成します。XXX は作成、取得、削除です
DSLを用意する（Create時に必須、他はパラメータなし）
リクエストを送信します。RestHighLevelClient#indices().xxx() メソッドを呼び出します。ここで、xxx は作成、存在、削除です。

運用ドキュメント

新しいドキュメント

データベーステーブルにデータを挿入するのと同じですが、インデックスライブラリに挿入されます。

新しく追加されたドキュメントの DSL ステートメントは次のとおりです。

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

対応する Java コードを図に示します。

在这里插入图片描述
これはインデックスライブラリの作成に似ていることがわかります。これも 3 ステップのプロセスです。

1) Request オブジェクトを作成する
2) DSL の JSON ドキュメントである要求パラメーターを準備します。
3) リクエストを送信

変更点は、client.xxx() の API がここで直接使用され、client.indices() が不要になったことです。

データベースクエリの結果はホテルタイプのオブジェクトであり、インデックスライブラリのフィールドと一致しません (たとえば、経度と緯度を場所にマージする必要があります)。ここで、一致する新しいタイプを定義する必要があります。索引ライブラリの構造:

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

データベースのホテルオブジェクトをインデックスライブラリに挿入するには、次の 3 つの点に注意してください。

ホテルデータはデータベースから取得されます。最初にクエリを実行して、ホテルオブジェクトを取得する必要があります。
ホテルオブジェクトを HotelDoc オブジェクトに変換する必要があります
HotelDoc は JSON 形式にシリアル化する必要があります

コードの全体的な手順は次のとおりです。

1) id に従ってホテルデータホテルをクエリする
2) ホテルを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}

非常に単純なので、コードは大まかに 2 つのステップに分けられます。

Request オブジェクトを準備する
リクエストを送る

ただし、クエリの目的は、HotelDoc に解析される結果を取得することであるため、問題は結果の解析です。完全なコードは次のとおりです。

在这里插入图片描述
ご覧のとおり、結果は JSON であり、ドキュメントが_source属性に配置されているため、解析ではそれを取得し_sourceて Java オブジェクトにデシリアライズします。

以前と同様に、これも 3 ステップのプロセスです。

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 コードは次の 3 つのステップで進む必要があると考えられます。

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

在这里插入图片描述

ドキュメントを変更する

ドキュメントを変更するには、次の 2 つの方法があります。

完全な変更: 本質は、最初に ID に従って削除し、次に追加することです
増分変更: ドキュメント内の指定されたフィールド値を変更します

RestClient API では、完全な変更は新しく追加された API とまったく同じであり、判断は ID に基づいています。

追加時にIDがすでに存在する場合は、それを変更します
追加時にIDが存在しない場合は追加する

完全な変更は新しいカバレッジが新しいドキュメントと一致することを意味するため、主に段階的な変更に焦点を当てます.
コード例を図に示します:

在这里插入图片描述
以前と同様に、これも 3 ステップのプロセスです。

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

ドキュメントに変更するパラメータと値をコンマで区切って記述します

結果は次のとおりです在这里插入图片描述

ドキュメントの一括インポート

ケースの要件: BulkRequest を使用して、データベースデータをインデックスライブラリにバッチでインポートします。

次のように進めます。

mybatis-plus を使用してホテルデータをクエリする
クエリされたホテルデータ (Hotel) をドキュメントタイプデータ (HotelDoc) に変換します。
JavaRestClient で BulkRequest バッチ処理を使用してドキュメントをバッチで追加する

BulkRequest のバッチ処理の本質は、複数の通常の CRUD リクエストをまとめて送信することです。

他のリクエストを追加する add メソッドを提供します。

在这里插入图片描述
ご覧のとおり、追加できるリクエストには次のものがあります。

追加するIndexRequest
変更する UpdateRequest
DeleteRequest、つまり削除

そのため、複数の IndexRequest が一括で追加される新しい機能である Bulk が追加されます。例:
在这里插入图片描述
実際には、まだ 3 つのステップがあります。

1) Request オブジェクトを作成します。これがバルクリクエストです
2) パラメータを準備します。バッチ処理のパラメーターは他の Request オブジェクトです。ここでは複数の IndexRequests
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 に必要)

エラスティックサーチ検索機能

DSL クエリのドキュメント

Elasticsearch クエリは、JSON スタイルの DSL に基づいて引き続き実装されます。
(DSL はデータベースの DQL クエリステートメントに似ています)

DSL クエリの分類

Elasticsearch は、クエリを定義するための JSON ベースの DSL (ドメイン固有言語) を提供します。一般的なクエリの種類は次のとおりです。

Query all : 一般的なテストのために、すべてのデータを照会します。例:
全文検索 (全文) クエリ: 単語セグメンターを使用してユーザー入力コンテンツをセグメント化し、転置インデックスデータベースで照合します。例えば：
- match_query
- multi_match_query
正確なクエリ: 正確な入力値に基づいてデータを検索します。通常、キーワード、数値、日付、ブール値、およびその他の種類のフィールドを検索します。例えば：
- ID
- 範囲
- 学期
地理 (geo) クエリ: 緯度と経度に基づくクエリ。例えば：
- geo_distance
- geo_bounding_box
複合 (compound) クエリ: 複合クエリは、上記のさまざまなクエリ条件を組み合わせて、クエリ条件を結合することができます。例えば：
- ブール
- function_score

すべてを照会

クエリ構文は基本的に同じです。

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

例としてすべてのクエリを見てみましょう。

クエリタイプは match_all です
クエリ条件なし

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

その他のクエリは、クエリの種類とクエリ条件の変更にすぎません。

在这里插入图片描述

全文検索クエリ

使用シナリオ:
全文検索クエリの基本的なプロセスは次のとおりです。

ユーザーの検索内容をセグメント化し、エントリを取得する
転置索引ライブラリで照合するエントリに従って、ドキュメント ID を取得します。
ドキュメント ID に従ってドキュメントを検索し、ユーザーに返します

つまり、検索すると、キーワードに従って検索結果が返されます
エントリは一致するために使用されるため、検索に参加するフィールドも、セグメント化できるテキスト型のフィールドである必要があります。

基本文法

一般的な全文検索クエリには、次のものがあります。

一致クエリ: 単一フィールドクエリ
multi_match クエリ: 複数フィールドクエリ、クエリ条件を満たしている場合でも任意のフィールドが条件を満たしている

一致クエリの構文は次のとおりです。

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

在这里插入图片描述

multi_match 構文は次のとおりです。

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

在这里插入图片描述

2 つのクエリの結果が同じであることがわかりますが、なぜでしょうか?

copy_to を使用して、ブランド、名前、ビジネスの値をall フィールドにコピーしたためです。したがって、3 つのフィールドに基づいて検索できます。もちろん、すべてのフィールドに基づいて検索するのと同じ効果があります。

ただし、検索フィールドが多いほど、クエリのパフォーマンスへの影響が大きくなるため、copy_to を使用してから単一フィールドクエリを使用することをお勧めします。

在这里插入图片描述
match と multi_match の違い

match: フィールドに基づくクエリ
multi_match: 複数のフィールドに基づくクエリ。クエリに含まれるフィールドが多いほど、クエリのパフォーマンスが低下します。

正確なクエリ

正確なクエリは、通常、キーワード、値、日付、ブール値、およびその他の種類のフィールドを検索することです。そのため、検索条件の単語分割は行いません。一般的なものは次のとおりです。

term: 用語の正確な値に基づくクエリ
range: 値の範囲に基づくクエリ

用語クエリ

完全一致クエリのフィールド検索は単語区切りのないフィールドであるため、クエリ条件も単語区切りのないエントリである必要があります。クエリを実行すると、ユーザーが入力した内容が自動値と正確に一致する場合にのみ、条件を満たしていると見なされます。ユーザーが入力する内容が多すぎると、データを検索できません。

文法の説明:

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

ただし、次の例では
在这里插入图片描述、検索の内容がエントリではなく、複数の単語からなるフレーズの場合、検索できません。

在这里插入图片描述

範囲クエリ

範囲クエリは、通常、数値型で範囲フィルタリングを実行するときに使用されます。たとえば、価格帯のフィルタリングを行います。

基本的な構文:

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

在这里插入图片描述

要約する

正確なクエリの一般的な種類は何ですか?

用語クエリ: 用語に基づく完全一致、一般的な検索キーワードタイプ、数値型、ブール型、日付型フィールド
範囲クエリ: 値と日付の範囲である値の範囲に基づくクエリ

地理座標クエリ

いわゆる地理座標クエリは、実際には緯度と経度のクエリに基づいています。公式ドキュメント: https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html

一般的な使用シナリオは次のとおりです。

Ctrip: 近くのホテルを検索
Didi: 近くのタクシーを探す
WeChat: 近くの人を検索

矩形範囲クエリ

矩形範囲クエリ、つまり 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 件のホテルが見つかりました。

複合クエリ

複合クエリ: 複合クエリでは、他の単純なクエリを組み合わせて、より複雑な検索ロジックを実装できます。一般的なものは 2 つあります。

関数スコア: ドキュメントの関連性の計算を制御し、ドキュメントのランキングを制御できる計算関数クエリ
bool query: 論理関係を使用して他の複数のクエリを組み合わせて複雑な検索を実現するブールクエリ。

関連性スコア

一致クエリを使用すると、ドキュメントの結果は検索語との関連性に応じてスコア (_score) が付けられ、返される結果はスコアの降順で並べ替えられます。

在这里插入图片描述

TF-IDF アルゴリズムには欠陥があります。つまり、用語の頻度が高いほど、ドキュメントスコアが高くなり、単一の用語がドキュメントに与える影響が大きくなります。ただし、BM25 には 1 回のエントリのスコアに上限があり、曲線はより滑らかになります。
在这里插入图片描述

後のバージョン 5.1 のアップグレードでは、elasticsearch はアルゴリズムを BM25 アルゴリズムに改善しました。

計算関数クエリ

関連性に基づいたスコアリングは合理的な要件ですが、合理的なものは必ずしもプロダクトマネージャーが必要とするものではありません。

Baidu を例にとると、検索結果では、関連性が高いほどランキングが高くなるわけではなく、ランキングが高いほど、誰がより多く支払うかがわかります。写真に示すように：
在这里插入图片描述

文法の説明

在这里插入图片描述

関数スコアクエリには、次の 4 つの部分が含まれます。

元のクエリ条件: クエリ部分、この条件に基づいてドキュメントを検索し、BM25 アルゴリズムに基づいてドキュメントをスコア付けする、元のスコア(クエリスコア)
フィルター条件: フィルター部分、この条件を満たすドキュメントは再計算されます
計算機能: フィルター条件を満たすドキュメントは、この関数に従って計算する必要があり、取得された関数スコア(関数スコア) には、4 つの関数があります。
- 重み: 関数の結果は定数です
- field_value_factor: ドキュメント内のフィールド値を関数の結果として使用します
- random_score: 関数の結果として乱数を使用します
- script_score: カスタムスコアリング関数アルゴリズム
計算モード: 計算関数の結果、元のクエリの相関計算スコア、および 2 つの間の計算方法。
- 乗算: 乗算
- replace: クエリスコアを関数スコアに置き換えます
- その他: sum、avg、max、min など

関数スコアの操作プロセスは次のとおりです。

1)元の条件に従ってドキュメントをクエリおよび検索し、元のスコア(クエリスコア)と呼ばれる関連性スコアを計算します。
2)フィルター条件に従って、ドキュメントをフィルター処理します
3)フィルタ条件を満たすドキュメントについては、スコア関数の計算に基づいて関数スコアが取得されます。
4)動作モードに基づいて、元のスコア(クエリスコア) と関数スコア(機能スコア)が計算され、最終的な結果が相関スコアとして取得されます。

重要なポイントは次のとおりです。

フィルター条件: スコアが変更されたドキュメントを特定する
スコアリング関数: 関数のスコアを決定するアルゴリズム
計算モード: 最終的な計算結果を決定します

例

条件：「ホームイン」ブランドのホテルを上位ランク

この要件を前述の 4 つのポイントに変換します。

元の状態：不明、勝手に変更可能
フィルタ条件: ブランド = 「ホームイン」
計算機能：単純で失礼なことができ、固定の計算結果、重みを直接与えることができます
演算モード：加算など

したがって、最終的な DSL ステートメントは次のようになります。

GET /hotel/_search
{
    
    
  "query": {
    
    
    "function_score": {
    
    
      "query": {
    
      .... }, // 原始查询，可以是任意条件
      "functions": [ // 算分函数
        {
    
    
          "filter": {
    
     // 满足的条件，品牌必须是如家
            "term": {
    
    
              "brand": "如家"
            }
          },
          "weight": 2 // 算分权重为2
        }
      ],
      "boost_mode": "sum" // 加权模式，求和
    }
  }
}

テスト、スコアリング機能が追加されていない場合のホームインのスコアは次のとおりです:
在这里插入图片描述
スコアリング機能を追加した後、ホームインのスコアは改善されます。

在这里插入图片描述

まとめ

フィルター条件: どのドキュメントにポイントを追加するか
計算機能：機能スコアの計算方法
重み付け方法: 関数スコアとクエリスコアの計算方法

ブールクエリ

ブールクエリは、1 つ以上のクエリ句の組み合わせであり、それぞれがサブクエリです。サブクエリは、次の方法で組み合わせることができます。

must: 「and」と同様に、各サブクエリに一致する必要があります
should: 「or」に似た選択的マッチングサブクエリ
must_not: 一致してはならない、スコアリングに参加しない、「not」と同様
フィルター: 一致する必要があります。スコアリングには参加しません

たとえば、ホテルを検索する場合、キーワード検索に加えて、ブランド、価格、都市などのフィールドに従ってフィルタリングすることもあります。このとき、クエリを組み合わせる必要があります。フィールドごとにクエリ条件とメソッドが異なります
。複数の異なるクエリである必要があり、これらのクエリを組み合わせるには、bool クエリを使用する必要があります。検索の際、スコアリングに関与するフィールドが多いほど、クエリのパフォーマンスが低下することに
注意してください。したがって、複数の条件でクエリを実行する場合は、次のようにすることをお勧めします。

検索ボックスのキーワード検索は全文検索クエリであり、must クエリを使用し、スコアリングに参加します
その他のフィルター条件については、フィルタークエリを使用します。採点に参加しない

文法説明
クエリ都市は上海、ブランドはクラウンプラザまたはラマダ、価格は 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 を中心に 10 km 以内のホテルを検索します。

分析:

名前検索は全文検索クエリであり、スコアリングに関与する必要があります。入れなければならない
価格が 400 を超えない場合は、フィルター条件に属し、ポイントの計算に参加しない範囲をクエリに使用します。must_not に入れる
10km の範囲内で、geo_distance を使用してクエリを実行します。これはフィルター条件に属し、ポイントの計算には関与しません。フィルターに入れる

在这里插入图片描述

まとめ

bool クエリにはいくつの論理関係がありますか?

must: 一致しなければならない条件で、「and」として理解できます。
should: 「または」として理解できる、選択的マッチングの条件。
must_not: 一致してはならない条件、スコアリングに参加しない
フィルター: 一致する必要がある条件、スコアリングに参加しない

検索結果の処理

分類する

デフォルトでは、Elasticsearch は相関スコア (_score) に従って並べ替えますが、検索結果を並べ替えるカスタムの方法もサポートしています。並べ替え可能なフィールドタイプには、キーワードタイプ、数値タイプ、地理座標タイプ、日付タイプなどがあります。

通常のフィールドの並べ替え

キーワード、値、および日付によるソートの構文は、基本的に同じです。

文法:

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

ソート条件は配列です。つまり、複数のソート条件を記述できます。宣言の順序に従って、最初の条件が等しい場合は、2 番目の条件に従って並べ替えます。

例：

要件の説明: ホテルデータは、ユーザーの評価 (スコア) の降順で並べ替えられ、同じ評価が価格 (価格) の昇順で並べ替えられます。

在这里插入图片描述

地理座標で並べ替え

タクシーに乗ったり、食品の配達を注文したり、旅行に出かけたりするとき、アプリは常に目の前の位置に基づいて最寄りの商人をランク付けします。

地理座標の順序はわずかに異なります。

文法説明:

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 は上位 10 件のデータのみを返します。さらに多くのデータを照会する場合は、ページングパラメーターを変更する必要があります。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）给文档中的所有关键字都添加一个标签，例如<em>标签
2）页面给<em>标签编写CSS样式

实现高亮

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

注意：

高亮是对关键字高亮，因此搜索条件必须带有关键字，而不能是范围这样的查询。
默认情况下，高亮的字段，必须与搜索指定的字段一致，否则无法高亮
如果要对非搜索字段高亮，则需要添加一个属性：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.8</java.version>
    <elasticsearch.version>7.12.1</elasticsearch.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 などで他のクエリを組み合わせたものです。コード例は次のとおりです。コードは完全に変更されていません。

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

}

ソート、ページネーション

検索結果の並べ替えやページングはクエリと同レベルのパラメータなので、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);

}

ハイライト

強調表示されたコードは、前のコードとはかなり異なります。次の 2 つの点があります。

クエリ DSL: クエリ条件に加えて、ハイライト条件も追加する必要があります。これもクエリと同じレベルです。
結果の解析: _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);

}

ハイライト結果の分析
在这里插入图片描述
コードの解釈:

ステップ 1: 結果からソースを取得します。hit.getSourceAsString()、この部分は強調表示されていない結果、json 文字列です。また、HotelDoc オブジェクトに逆シリアル化する必要があります。
ステップ 2: 強調表示された結果を取得します。hit.getHighlightFields()、戻り値はマップ、キーはハイライトフィールド名、値はハイライト値を表す HighlightField オブジェクトです。
ステップ 3: 強調表示されたフィールド名に従って、強調表示されたフィールド値オブジェクト HighlightField をマップから取得する
ステップ 4: HighlightField から Fragments を取得し、文字列に変換します。この部分が本当のハイライトされた文字列です
ステップ 5: 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.8</java.version>
    <elasticsearch.version>7.12.1</elasticsearch.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;
}

サーバーが返す応答結果エンティティクラスを定義します。

ページングクエリは、次の 2 つの属性を含むページング結果 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 を定義し、クエリインターフェイスを宣言して、次の要件を満たします。

依頼方法：郵送
リクエストパス: /hotel/list
リクエストパラメータ: RequestParam タイプのオブジェクト
戻り値: 2 つの属性を含む 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);
    }
}

次に、サービス層で検索ビジネスを実装します。
1.IHotelServiceインターフェイスでメソッドを定義します。

/**
 * 根据关键字搜索酒店信息
 * @param params 请求参数对象，包含用户输入的关键字 
 * @return 酒店文档列表
 */
PageResult search(RequestParams params);

2.で検索メソッドを実装しますcn.itcast.hotel.service.impl。HotelService

@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 オブジェクトにカプセル化されることに注意してください。

在这里插入图片描述

ホテルの結果フィルター

要件: ブランド、都市、星評価、価格などのフィルター関数を追加します。
在这里插入图片描述
渡されるパラメーターは、図に示すとおりです。

含まれるフィルターは次のとおりです。

ブランド: ブランド価値
都市: 都市
minPrice~maxPrice: 価格帯
starName: 星

次の 2 つのことを行う必要があります。

①リクエストパラメータのオブジェクト 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 の検索メソッドで、変更する必要があるのは 1 か所だけです。requet.source().query( ... ) のクエリ条件です。

これまでの業務はマッチクエリのみで、キーワードで検索していましたが、以下のような条件フィルタリングを追加する必要があります。

ブランドフィルタリング: キーワードタイプ、用語によるクエリ
スターフィルター: キーワードタイプ、用語クエリを使用
価格フィルタリング: 数値型で、範囲のあるクエリです
都市フィルター: キーワードタイプ、用語を使用したクエリ

複数のクエリ条件の組み合わせは、ブールクエリと組み合わせる必要があります。

キーワード検索をマストに入れ、スコア計算に参加する
他のフィルター条件はフィルターに配置され、ポイントの計算には関与しません

条件付き構築のロジックはより複雑であるため、最初に関数としてカプセル化されます。

在这里插入图片描述
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 パラメータを変更します。
検索メソッドのビジネスロジックを変更します。場所に値がある場合は、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);
    }
}

並べ替えが完了したら、ページは近くの各ホテルの特定の距離値も取得する必要があります.この値は応答結果とは無関係です.結果の
在这里插入图片描述
解析段階では、ソース部分の解析に加えて、取得する必要もあります.ソートされた距離であるソート部分を応答結果に入れます。

次の 2 つのことを行います。

HotelDoc を変更し、ページ表示用のソート距離フィールドを追加します
HotelServiceクラスのhandleResponseメソッドを修正し、ソート値の取得を追加

1) HotelDoc クラスを変更し、距離フィールドの距離を追加します
在这里插入图片描述

2) HotelService の handleResponse メソッドを変更する

在这里插入图片描述

最終的な結果は以下のとおりです
在这里插入图片描述

ホテル PPC

要件: 指定したホテルを検索結果で上位にするには、
関連性スコアを変更します。スコアが高いほど、ランキングが高くなります。

指定したホテルを検索結果の上位にランク付けする場合の効果は、次の図のようになります。

在这里插入图片描述
このページは、指定されたホテルに広告タグを追加します。

以前に学習した function_score クエリは、計算スコアに影響を与える可能性があり、計算スコアが高いほど、自然なランキングが高くなります。function_score には 3 つの要素が含まれます。

フィルター条件: どのドキュメントにポイントを追加するか
計算機能：機能スコアの計算方法
重み付け方法: 関数スコアとクエリスコアの計算方法

ここで求められるのは、指定ホテルのランクを高くしたいということです。したがって、これらのホテルにマークを追加して、フィルター条件で、このマークに応じてスコアを上げるかどうかを判断できるようにする必要があります。

たとえば、フィールドをホテルに追加します: isAD、ブール型:

true: 広告です
false: 広告ではありません

このように、function_score には 3 つの要素が含まれており、簡単に判断できます。

フィルター条件: isAD が true かどうかを判断する
計算機能: 最も単純な暴力的な重み、固定重み付け値を使用できます
重み付け方法: デフォルトの乗算方法を使用して、計算スコアを大幅に改善できます

したがって、ビジネスの実装手順には次のものが含まれます。

isAD フィールドを HotelDoc クラスに追加、ブール型
好きなホテルをいくつか選び、そのドキュメントデータに isAD フィールドを追加すると、値が true になります
検索方法を修正し、関数スコア関数を追加し、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 クエリ構造は次のとおりです。
在这里插入图片描述
対応する Java API は次のとおりです。

以前に作成したブールクエリを元のクエリ条件としてクエリに入れ、フィルタ条件、スコアリング関数、重み付けモードを追加できます。したがって、元のコードは引き続き使用できます。

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

データ集約

集計の種類

集約には、次の 3 つの一般的なタイプがあります。

バケット集約: 生活のゴミ分類と同じように、ドキュメントをグループ化するために使用され、異なるゴミを異なるゴミ箱に入れます。
- TermAggregation: ブランド値によるグループ、国によるグループなど、ドキュメントフィールド値によるグループ化
- 日付ヒストグラム: 日付ラダーごとにグループ化します。たとえば、グループとして週、またはグループとして月です。
メトリック集計: 最大値、最小値、平均値などの値を計算するために使用されます。
- 平均: 平均
- Max: 最大値を見つけます
- Min: 最小値を見つけます
- 統計: 最大、最小、平均、合計などを同時にシークします。
パイプライン(pipeline) ※アグリゲーション：他のアグリゲーションの結果に基づくアグリゲーション

注: 集計に参加するフィールドは、キーワード、日付、値、ブール値

集約のためのDSL

ここで、すべてのデータでホテルのブランドを数えたいと思います.実際には、ブランドに従ってデータをグループ化します. この時点で、ホテルブランドの名前に基づいて集計、つまりバケット集計を実行できます。

バケット (バケット) 集計構文

構文は次のとおりです。

GET /hotel/_search
{
    
    
  "size": 0,  // 设置size为0，结果中不包含文档，只包含聚合结果
  "aggs": {
    
     // 定义聚合
    "brandAgg": {
    
     //给聚合起个名字
      "terms": {
    
     // 聚合的类型，按照品牌值聚合，所以选择term
        "field": "brand", // 参与聚合的字段
        "size": 20 // 希望获取的聚合结果数量
      }
    }
  }
}

結果を図に示します。
在这里插入图片描述

集計結果の並べ替え

デフォルトでは、バケット集約はバケット内のドキュメントの数をカウントし、それを _count として記録し、_count の降順で並べ替えます。

order 属性を指定して、集計のソート方法をカスタマイズできます。

GET /hotel/_search
{
    
    
  "size": 0, 
  "aggs": {
    
    
    "brandAgg": {
    
    
      "terms": {
    
    
        "field": "brand",
        "order": {
    
    
          "_count": "asc" // 按照_count升序排列
        },
        "size": 20
      }
    }
  }
}

集計範囲を制限する

デフォルトでは、バケット集計はインデックスライブラリ内のすべてのドキュメントを集計しますが、実際のシナリオではユーザーが検索条件を入力するため、集計は検索結果の集計である必要があります。次に、集約を修飾する必要があります。

クエリ条件を追加することで、集計するドキュメントの範囲を制限できます。

GET /hotel/_search
{
    
    
  "query": {
    
    
    "range": {
    
    
      "price": {
    
    
        "lte": 200 // 只对200元以下的文档聚合
      }
    }
  }, 
  "size": 0, 
  "aggs": {
    
    
    "brandAgg": {
    
    
      "terms": {
    
    
        "field": "brand",
        "size": 20
      }
    }
  }
}

今回は、集約されたブランドが大幅に少なくなっています。

在这里插入图片描述

メトリック (メトリック) 集計構文

ホテルをブランドごとにグループ化してバケットを形成します。次に、バケット内のホテルに対して計算を実行して、各ブランドのユーザー評価の最小値、最大値、および平均値を取得する必要があります。

これには、統計集計などのメトリック集計を使用する必要があります。最小、最大、平均などの結果を取得できます。

構文は次のとおりです。

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 は Aggregation の略で、query と同じレベルですが、このときの query の機能は何ですか?

集約されたドキュメントのスコープ

集計に必要な 3 つの要素:

集合体名
集計タイプ
集約フィールド

集合的な構成可能なプロパティは次のとおりです。

size: 集計結果の数を指定します
order: 集計結果のソート方法を指定します
field: 集計フィールドを指定します

RestAPI は集計を実装します

API 構文

集計条件はクエリ条件と同じレベルなので、request.source() を使用して集計条件を指定する必要があります。

集計条件の構文:

在这里插入图片描述
集計結果もクエリ結果とは異なり、APIも特殊です。ただし、 JSONもレイヤーごとに解析されます。

ビジネスニーズ

要件: 検索ページのブランド、都市、およびその他の情報は、ページにハードコーディングするのではなく、集約されたインデックスデータベース内のホテルデータから取得する必要があります。つまり、毎回条件を選択した後、列の
コンテンツ関連する滞在、関連する削除なし。

たとえば、最初に 100 元未満の価格を選択した場合、星の列にある 5 つ星ホテルと 4 つ星ホテルは存在しないはずです。データ。

在这里插入图片描述

分析:

現在、ページ上の都市リスト、スターリスト、ブランドリストはすべてハードコーディングされており、検索結果が変化しても変化しません。しかし、ユーザーの検索条件が変わると、それに応じて検索結果も変わります。

たとえば、ユーザーが「東方明珠」を検索した場合、検索されたホテルは上海東方明珠電視塔の近くにある必要があります.したがって、都市は上海しかあり得ません.このとき、北京、深セン、杭州は、都市リスト。

つまり、どの都市を検索結果に含め、どの都市をページに掲載するか、どのブランドを検索結果に含め、どのブランドをページに掲載するかを決定します。

集計機能とバケット集計を使用して、ブランドと都市に基づいて検索結果のドキュメントをグループ化し、どのブランドと都市が含まれているかを知ることができます。

検索結果の集計であるため、集計は範囲限定集計、つまり、集計の限定条件が検索文書の条件と一致している。
ブラウザーを見ると、フロントエンドが実際にそのような要求を送信したことがわかります。
在这里插入图片描述
要求パラメーターは、検索ドキュメントのパラメーターとまったく同じです。

戻り値の型は、ページに表示される最終結果です。

在这里插入图片描述
結果は Map 構造です。

キーは文字列、都市、星、ブランド、価格です
値は、複数の都市の名前などのコレクションです

ビジネス実現

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

オートコンプリート

ユーザーが検索ボックスに文字を入力すると、図に示すように、その文字に関連する検索項目を表示する必要があります。

在这里插入图片描述
ユーザーが入力した文字に基づいて完全な入力を促すこの機能は、オートコンプリートです。

ピンイン文字に基づいて推測する必要があるため、ピンイン単語セグメンテーション関数が使用されます。

ピンインワードブレーカー

文字に基づいて完成させるには、ピンインに従って文書を分割する必要があります。GitHub には、elasticsearch 用のピンインワードセグメンテーションプラグインがあります。アドレス: https://github.com/medcl/elasticsearch-analysis-pinyin

インストール方法は IK トークナイザーと同じで、次の 3 つのステップがあります。

①減圧

②elasticsearchのpluginディレクトリを仮想マシンにアップロード

③エラスティックサーチを再起動

テストの使用方法は次のとおりです。

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

結果：
在这里插入图片描述

カスタムトークナイザー

デフォルトのピンインワードブレーカーは各漢字をピンインに分割しますが、各エントリでピンインのセットを形成する必要があるため、ピンインワードブレーカーをカスタマイズしてカスタムワードブレーカーを作成する必要があります。

Elasticsearch のアナライザーの構成は、次の 3 つの部分で構成されます。

文字フィルター: トークナイザーの前にテキストを処理します。例: 文字の削除、文字の置換
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数据修改

解決策 3: バイナリログを監視する

在这里插入图片描述
プロセスは次のとおりです。

mysql の binlog 機能を有効にする
mysql の追加、削除、変更操作は binlog に記録されます
Hotel-demo は canal に基づいて binlog の変更を監視し、elasticsearch のコンテンツをリアルタイムで更新します

まとめ

方法 1: 同期呼び出し

利点: 実装が簡単、ラフ
短所: 高度なビジネス結合

方法 2: 非同期通知

利点: カップリングが低く、一般的に実装が難しい
短所: mq の信頼性に依存する

方法 3: バイナリログを監視する

利点: サービス間の完全な分離
短所: binlog を有効にすると、データベースの負荷が増加し、実装が非常に複雑になります。

データ同期を実現

コードのアイデア

ここでは先ほど学んだMQという技術を中間リスナーとして使い、
ホテルのデータを追加・削除・変更する場合、elasticsearchのデータに対しても同様の操作が必要です。

ステップ：

コース前の資料で提供される hotel-admin プロジェクトをインポートし、ホテルデータの CRUD を開始してテストします
exchange、キュー、RoutingKey を宣言する
hotel-admin でのビジネスの追加、削除、および変更でメッセージ送信を完了する
hotel-demo でメッセージの監視を完了し、elasticsearch でデータを更新する
データ同期機能の開始とテスト

デモプロジェクトのインポート

事前教材で提供されている hotel-admin プロジェクトをインポートし、yml でデータベースの構成情報を変更します。
実行後、http://localhost:8099 にアクセスします。

在这里插入图片描述
ホテルの CRUD 機能が含まれています。

これらはすべて mp の API であり、直接呼び出すことができます。

キューと交換を宣言する

MQ 構造を図に示します。依存関係の
在这里插入图片描述
インポート

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

mq コンテナーを開始する
以前に mq コンテナーを実行したことがある場合は、

docker start 容器名

以前に 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: /

キュースイッチの名前を宣言する
キュースイッチの名前を書き間違えないように、定数クラスで名前を定義し、
constnts パッケージの下に新しい 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 の add、delete、および modify サービスでそれぞれ MQ メッセージを送信します。

3 つのパラメータ: switch、RoundingKey、message
在这里插入图片描述

hotel-admin でデータベースの crud が実行されるたびに、メッセージが列に送信され、サブスクリプションメッセージの受信者は hotel-demo に通知され、es インデックスライブラリ内のドキュメントを更新してデータの同期を確保します。

MQ メッセージを受信する

hotel-demo が MQ メッセージを受信したときに行うことは次のとおりです。

新しいメッセージ: 渡されたホテル ID に従ってホテル情報をクエリし、データの一部をインデックスライブラリに追加します
削除メッセージ: 渡されたホテル ID に従ってインデックスライブラリ内のデータを削除します

1) まず、 hotel-demo のserviceパッケージIHotelServiceの下に新しいサービスを追加および削除します。

void deleteById(Long id);

void insertById(Long id);

2) service.implhotel-demo のパッケージの下にある 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 は、大量のデータストレージと単一障害点という 2 つの問題に必然的に直面します。

大量のデータストレージの問題: インデックスライブラリを論理的に N 個のシャード (シャード) に分割し、それらを複数のノードに格納する
単一障害点の問題: 断片化されたデータを異なるノード (レプリカ) にバックアップする

ES クラスター関連の概念:

クラスター (クラスター): 共通のクラスター名を持つノードのグループ。
Node (ノード) : クラスター内の Elasticsearch インスタンス
シャード: インデックスは、シャードと呼ばれるストレージ用のさまざまな部分に分割できます。クラスタ環境では、インデックスのさまざまなシャードをさまざまなノードに分割できます

問題を解決します。データ量が多すぎて、1 つのポイントのストレージ容量が制限されています。
在这里插入图片描述

ここでは、データを 3 つの部分に分割します: shard0、shard1、shard2

プライマリシャード (プライマリシャード): レプリカシャードの定義に関連します。
レプリカシャード (レプリカシャード) 各プライマリシャードは 1 つ以上のコピーを持つことができ、データはプライマリシャードと同じです。

な

データのバックアップは高可用性を確保できますが、シャードごとにバックアップすると、必要なノードの数が 2 倍になり、コストが高すぎます。

高可用性とコストのバランスを見つけるには、次のようにします。

最初にデータを分割し、異なるノードに保存します
次に、各シャードをバックアップし、他のノードに配置して相互バックアップを完了します

これにより、必要なサービスノードの数を大幅に減らすことができます. 図に示すように、例として 3 つのシャードと各シャードをバックアップコピーとして使用します。

在这里插入图片描述
現在、各シャードには 1 つのバックアップがあり、3 つのノードに保存されています。

node0: シャード 0 と 1 を保持
node1: シャード 0 と 2 を保持
node2: 保存されたシャード 1 と 2

ES クラスターを構築する

docker-compose を使用して es クラスターを直接展開できますが、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

準備した構成ファイルを仮想マシンにアップロードします
在这里插入图片描述

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：

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

目录

前言

Docker

初见小鲸鱼

Docker アーキテクチャ

Docker のインストール

Docker の基本

Dockerfile カスタム イメージ

Docker-Compose

Docker ミラー ウェアハウス

异步通信

初识MQ

同步通讯

异步通讯

MQ 共通フレームワーク

RabbitMQ クイック スタート

RabbitMQ の概要とインストール

共通メッセージ モデル

クイックスタート

スプリングAMQP

Basic Queue 単純なキューモデル

Work Queue 工作队列模型

パブリッシュ/サブスクライブ

パブリッシュ、サブスクライブ モデル - ファンアウト

パブリッシュ、サブスクライブ モデル ダイレクト

パブリッシュ、サブスクライブ モデル トピック

メッセージコンバーター

分散検索

エラスティックサーチを理解する

エス紹介

逆インデックス

ESの基本的な考え方

es、kibanaをインストール

索引ライブラリ操作

マッピング マッピング プロパティ

インデックス ライブラリの CRUD

インデックス リポジトリとマッピングを作成する

インデックス ライブラリのクエリと削除

インデックス ライブラリの変更

文档操作

新增文档

查询和删除文档

修改文档

小结

RestAPI

快速入门

操作索引ライブラリ

運用ドキュメント

エラスティックサーチ検索機能

DSL クエリのドキュメント

DSL クエリの分類

すべてを照会

全文検索クエリ

正確なクエリ

地理座標クエリ

複合クエリ

ブールクエリ

検索結果の処理

分類する

ページング

高亮

总结

RestClient查询文档

快速入门

match查询

精确查询

布尔查询

ソート、ページネーション

ハイライト

観光事業事例

ホテル検索とページネーション

ホテルの結果フィルター

近くのホテル

ホテル PPC

データ集約

集計の種類

集約のためのDSL

RestAPI は集計を実装します

オートコンプリート

Dockerfile カスタムイメージ

Docker ミラーウェアハウス

RabbitMQ クイックスタート

共通メッセージモデル

パブリッシュ、サブスクライブモデル - ファンアウト

パブリッシュ、サブスクライブモデルダイレクト

パブリッシュ、サブスクライブモデルトピック

マッピングマッピングプロパティ

インデックスライブラリの CRUD

インデックスリポジトリとマッピングを作成する

インデックスライブラリのクエリと削除

インデックスライブラリの変更

デモプロジェクトのインポート