SpringCloud

发表于2024-05-15|更新于2024-09-27|微服务

|字数总计:108.1k|阅读时长:420分钟|阅读量:

认识微服务

服务架构演变

单体架构

单体架构：将业务中的所有功能集合在一个项目中开发，打包成一个包部署

优点：

架构简单
部署成本低

缺点：

耦合度高

分布式架构

分布式架构：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务

优点：

降低服务耦合度
有利于服务升级扩展

缺点：

服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

服务拆分的粒度如何界定？
服务之间如何调用？
服务的调用关系如何管理？
服务之间的健康状态如何感知？

微服务

微服务：是一种经过良好架构设计的分布式架构方案，微服务架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
自治：团队独立、技术独立、数据独立，独立部署和交付
面向服务：服务提供统一标准的接口，与语言和技术无关
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

国内知名的微服务技术：SpringCloud和阿里巴巴的Dubbo

微服务技术对比

企业需求

SpringCloud

SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的体验。

常见组件：

另外，SpringCloud底层是依赖于SpringBoot的，并且有版本的兼容关系，如下：

服务的拆分及远程调用

服务拆分原则

不同微服务，不要重复开发相同业务
微服务数据独立，不要访问其它微服务的数据库
微服务可以将自己的业务暴露为接口，供其它微服务调用

服务拆分实例

以cloud-demo为例，其结构如下：

cloud-demo：父工程，管理依赖

order-service：订单微服务，负责订单相关业务
user-service：用户微服务，负责用户相关业务

要求：

订单微服务和用户微服务都必须有各自的数据库，相互独立
订单服务和用户服务都对外暴露Restful的接口
订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

导入sql

cloud-user表中初始数据如下：

cloud-order表中初始数据如下：

cloud-order表中持有cloud-user表中的id字段。

导入demo

该项目中的启动为不同的端口

…

服务远程调用案例

在order-service服务中，有一个根据id查询订单的接口：

根据id查询订单，返回值是Order对象，如图：

其中的user为null

在user-service中有一个根据id查询用户的接口：

查询的结果如图：

案例需求

修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。

因此，我们需要在order-service中向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。

大概的步骤是这样的：

注册一个RestTemplate的实例到Spring容器
修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User
将查询的User填充到Order对象，一起返回

注册RestTemplate

在启动类/配置类中注册RestTemplate

package cn.itcast.order;

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    /**
    * 注册RestTemplate
    */
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

实现远程调用

在Order的服务类中添加发送远程调用的代码

提供者和消费者

在服务调用关系中，会有两个不同的角色：

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

但是，服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。

如果服务A调用了服务B，而服务B又调用了服务C，服务B的角色是什么？

对于A调用B的业务而言：A是服务消费者，B是服务提供者
对于B调用C的业务而言：B是服务消费者，C是服务提供者

因此，服务B既可以是服务提供者，也可以是服务消费者。

Eureka注册中心

假如我们的服务提供者user-service部署了多个实例，如图：

大家思考几个问题：

order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
有多个user-service实例地址，order-service调用时该如何选择？
order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

Eureka的结构和作用

这些问题都需要利用SpringCloud中的注册中心来解决，其中最广为人知的注册中心就是Eureka，其结构如下：

思考的解答。

1、order-service如何得知user-service实例地址？

获取地址信息的流程如下：

user-service服务实例启动后，将自己的信息注册到eureka-server（Eureka服务端）。这个叫服务注册
eureka-server保存服务名称到服务实例地址列表的映射关系
order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取

2、order-service如何从多个user-service实例中选择具体的实例？

order-service从实例列表中利用负载均衡算法选中一个实例地址
向该实例地址发起远程调用

3、order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳
当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
order-service拉取服务时，就能将故障实例排除了

注意：一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端

因此，接下来我们动手实践的步骤包括：

搭建EurekaService

首先注册中心服务端：eureka-server，这必须是一个独立的微服务

创建eureka-server服务

在cloud-demo父工程下，创建一个子模块：

填写模块信息：

然后填写服务信息：

引入eureka依赖

引入SpringCloud为eureka提供的starter依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

编写启动类

给eureka-server服务编写一个启动类，一定要添加一个**@EnableEurekaServer**注解，开启eureka的注册中心功能：

package cn.itcast.eureka;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class, args);
    }
}

编写配置文件

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka

启动服务

启动微服务，然后在浏览器访问：http://127.0.0.1:10086

服务注册

下面，我们将user-service注册到eureka-server中去。 order-service同理

引入依赖

在user-service的pom文件中，引入下面的eureka-client依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

配置文件

在user-service中，修改application.yml文件，添加服务名称、eureka地址：

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

启动多个user-service实例

为了演示一个服务有多个实例的场景，我们添加一个SpringBoot的启动配置，再启动一个user-service。

首先，复制原来的user-service启动配置：

然后，在弹出的窗口中，填写信息：

现在，SpringBoot窗口会出现两个user-service启动配置：

启动并查看 eureka-server管理页面

服务发现

下面，我们将order-service的逻辑修改：向eureka-server拉取user-service的信息，实现服务发现。

引入依赖

服务发现、服务注册统一都封装在eureka-client依赖，因此这一步与服务注册时一致。

在order-service的pom文件中，引入下面的eureka-client依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

配置文件

服务发现也需要知道eureka地址，因此第二步与服务注册一致，都是配置eureka信息：

在order-service中，修改application.yml文件，添加服务名称、eureka地址：

spring:
  application:
    name: orderservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

服务拉取和负载均衡

最后，我们要去eureka-server中拉取user-service服务的实例列表，并且实现负载均衡。

不过这些动作不用我们去做，只需要添加一些注解即可。

在order-service的OrderApplication中，给RestTemplate这个Bean添加一个@LoadBalanced注解：

修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法。修改访问的url路径，用服务名代替ip、端口：

spring会自动帮助我们从eureka-server端，根据userservice这个服务名称，获取实例列表，而后完成负载均衡。

Ribbon负载均衡

上一节中，我们添加了@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？

负载均衡原理

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。

那么我们发出的请求明明是http://userservice/user/1，怎么变成了http://localhost:8081的呢？

源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

我们进行源码跟踪：

LoadBalancerIntercepor

可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：

request.getURI()：获取请求uri，本例中就是 http://user-service/user/8
originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-service
this.loadBalancer.execute()：处理服务id，和用户请求。

这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。

LoadBalancerClient

继续跟入execute方法：

代码是这样的：

getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。
getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务

放行后，再次访问并跟踪，发现获取的是8081：

果然实现了负载均衡。

负载均衡策略IRule

在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:

我们继续跟入：

继续跟踪源码chooseServer方法，发现这么一段代码：

我们看看这个rule是谁：

这里的rule默认值是一个RoundRobinRule，看类的介绍：

这不就是轮询的意思嘛。

到这里，整个负载均衡的流程我们就清楚了。

总结

SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。用一幅图来总结一下：

基本流程如下：

拦截我们的RestTemplate请求http://userservice/user/1
RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service
DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表
eureka返回列表，localhost:8081、localhost:8082
IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081
RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求

负载均衡策略

负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：

不同规则的含义如下：

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

默认的实现就是ZoneAvoidanceRule，是一种轮询方案

自定义负载均衡策略

通过定义IRule实现可以修改负载均衡规则，有两种方式：

代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：

@Bean
public IRule randomRule(){
    return new RandomRule();
}

配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

1
2
3

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

注意，一般用默认的负载均衡规则，不做修改。

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true
    clients: userservice

Nacos注册中心

认识和安装Nacos

国内公司一般都推崇阿里巴巴的技术，比如注册中心，SpringCloudAlibaba也推出了一个名为Nacos的注册中心。

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

windows安装

开发阶段采用单机安装即可。

下载安装包

在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：

GitHub主页：https://github.com/alibaba/nacos

GitHub的Release下载页：https://github.com/alibaba/nacos/releases

如图：

解压

将这个包解压到任意非中文目录下，如图：

目录说明：

bin：启动脚本
conf：配置文件

端口配置

Nacos的默认端口是8848，如果你电脑上的其它进程占用了8848端口，请先尝试关闭该进程。

如果无法关闭占用8848端口的进程，也可以进入nacos的conf目录，修改配置文件中的端口：

修改其中的内容：

启动

启动非常简单，进入bin目录，结构如下：

然后执行命令即可：

windows命令：

1	.\startup.cmd -m standalone

执行后的效果如图：

访问

在浏览器输入地址：http://127.0.0.1:8848/nacos即可：

默认的账号和密码都是nacos，进入后：

服务注册到nacos

Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。

主要差异在于：

依赖不同
服务地址不同

引入依赖

在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

然后在user-service和order-service中的pom文件中引入nacos-discovery依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

注意：不要忘了注释掉eureka的依赖。

配置nacos地址

在user-service和order-service的application.yml中添加nacos地址：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

注意：不要忘了注释掉eureka的地址

重启

重启微服务后，登录nacos管理页面，可以看到微服务信息：

服务分级存储模型

一个服务可以有多个实例，例如我们的user-service，可以有:

127.0.0.1:8081
127.0.0.1:8082
127.0.0.1:8083

假如这些实例分布于全国各地的不同机房，例如：

127.0.0.1:8081，在上海机房
127.0.0.1:8082，在上海机房
127.0.0.1:8083，在杭州机房

Nacos就将同一机房内的实例划分为一个集群。

也就是说，user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图：

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。例如：

杭州机房内的order-service应该优先访问同机房的user-service。

给user-service配置集群

修改user-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HB # 集群名称

重启两个user-service实例后，我们可以在nacos控制台看到下面结果：

我们再次复制一个user-service启动配置，添加属性：

1	-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=BJ

配置如图所示：

启动UserApplication3后再次查看nacos控制台：

同集群优先的负载均衡

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。

因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

1、给order-service配置集群信息

修改order-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

2、修改负载均衡规则

修改order-service的application.yml文件，修改负载均衡规则：

1
2
3

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

也可以用用过bean注入的方式修改

@Bean
public IRule nacosRule() {
	return new NacosRule();
}

权重配置

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。

在nacos控制台，找到user-service的实例列表，点击编辑，即可修改权重：

在弹出的编辑窗口，修改权重：

注意：如果权重修改为0，则该实例永远不会被访问

环境隔离

Nacos提供了namespace来实现环境隔离功能。

nacos中可以有多个namespace
namespace下可以有group、service等
不同namespace之间相互隔离，例如不同namespace的服务互相不可见

创建namespace

默认情况下，所有service、data、group都在同一个namespace，名为public：

我们可以点击页面新增按钮，添加一个namespace：

然后，填写表单：

就能在页面看到一个新的namespace：

给微服务配置namespace

给微服务配置namespace只能通过修改配置来实现。

例如，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

重启order-service后，访问控制台，可以看到下面的结果：

此时访问order-service，因为namespace不同，会导致找不到userservice，控制台会报错：

Nacos与Eureka的区别

Nacos的服务实例分为两种l类型：

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

Nacos配置管理

Nacos除了可以做注册中心，同样可以做配置管理来使用。

统一配置管理

当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。

Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。

在nacos中添加配置文件

如何在nacos中管理配置呢？

然后在弹出的表单中，填写配置信息：

注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。

从微服务拉取配置

微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。

但如果尚未读取application.yml，又如何得知nacos地址呢？

因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程如下：

引入nacos-config依赖

首先，在user-service服务中，引入nacos-config的客户端依赖：

<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

添加bootstrap.yaml

然后，在user-service中添加一个bootstrap.yaml文件，内容如下：

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

这里会根据spring.cloud.nacos.server-addr获取nacos地址，再根据

${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id，来读取配置。

本例中，就是去读取userservice-dev.yaml：

读取nacos配置

在user-service中的UserController中添加业务逻辑，读取pattern.dateformat配置：

完整代码：

package cn.itcast.user.web;

import cn.itcast.user.pojo.User;
import cn.itcast.user.service.UserService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.*;

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;

@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    @Value("${pattern.dateformat}")
    private String dateformat;
    
    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateformat));
    }
    // ...略
}

在页面访问，可以看到效果：

配置热更新

我们最终的目的，是修改nacos中的配置后，微服务中无需重启即可让配置生效，也就是配置热更新。

要实现配置热更新，可以使用两种方式：

@Value + @RefreshScope

在@Value注入的变量所在类上添加注解@RefreshScope：

@ConfigurationPropeties

使用@ConfigurationProperties注解代替@Value注解。

在user-service服务中，添加一个类，读取patterrn.dateformat属性：

package cn.itcast.user.config;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

在UserController中使用这个类代替@Value：

完整代码：

package cn.itcast.user.web;

import cn.itcast.user.config.PatternProperties;
import cn.itcast.user.pojo.User;
import cn.itcast.user.service.UserService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;

@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    @Autowired
    private PatternProperties patternProperties;

    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
    }

    // 略
}

配置共享

其实微服务启动时，会去nacos读取多个配置文件，例如：

[spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml
[spring.application.name].yaml，例如：userservice.yaml

而[spring.application.name].yaml不包含环境，因此可以被多个环境共享。

下面我们通过案例来测试配置共享

添加一个环境共享配置

我们在nacos中添加一个userservice.yaml文件：

在user-service中读取共享配置

在user-service服务中，修改PatternProperties类，读取新添加的属性：

在user-service服务中，修改UserController，添加一个方法：

运行两个UserApplication，使用不同的profile

修改UserApplication2这个启动项，改变其profile值：

这样，UserApplication(8081)使用的profile是dev，UserApplication2(8082)使用的profile是test。

启动UserApplication和UserApplication2

访问http://localhost:8081/user/prop，结果：

访问http://localhost:8082/user/prop，结果：

可以看出来，不管是dev，还是test环境，都读取到了envSharedValue这个属性的值。

配置共享的优先级

当nacos、服务本地同时出现相同属性时，优先级有高低之分：

搭建Nacos集群

集群结构图

官方给出的Nacos集群图：

其中包含3个nacos节点，然后一个负载均衡器代理3个Nacos。这里负载均衡器可以使用nginx。

我们计划的集群结构：

三个nacos节点的地址：

节点	ip	port
nacos1	192.168.150.1	8845
nacos2	192.168.150.1	8846
nacos3	192.168.150.1	8847

搭建集群

搭建集群的基本步骤：

搭建数据库，初始化数据库表结构
下载nacos安装包
配置nacos
启动nacos集群
nginx反向代理

初始化数据库

Nacos默认数据存储在内嵌数据库Derby中，不属于生产可用的数据库。

官方推荐的最佳实践是使用带有主从的高可用数据库集群，主从模式的高可用数据库可以参考传智教育的后续高手课程。

这里我们以单点的数据库为例来讲解。

首先新建一个数据库，命名为nacos，而后导入下面的SQL：

CREATE TABLE `config_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(255) DEFAULT NULL,
  `content` longtext NOT NULL COMMENT 'content',
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  `src_user` text COMMENT 'source user',
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
  `app_name` varchar(128) DEFAULT NULL,
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  `c_desc` varchar(256) DEFAULT NULL,
  `c_use` varchar(64) DEFAULT NULL,
  `effect` varchar(64) DEFAULT NULL,
  `type` varchar(64) DEFAULT NULL,
  `c_schema` text,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfo_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_info_aggr   */
/******************************************/
CREATE TABLE `config_info_aggr` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(255) NOT NULL COMMENT 'group_id',
  `datum_id` varchar(255) NOT NULL COMMENT 'datum_id',
  `content` longtext NOT NULL COMMENT '内容',
  `gmt_modified` datetime NOT NULL COMMENT '修改时间',
  `app_name` varchar(128) DEFAULT NULL,
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfoaggr_datagrouptenantdatum` (`data_id`,`group_id`,`tenant_id`,`datum_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='增加租户字段';


/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_info_beta   */
/******************************************/
CREATE TABLE `config_info_beta` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
  `content` longtext NOT NULL COMMENT 'content',
  `beta_ips` varchar(1024) DEFAULT NULL COMMENT 'betaIps',
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  `src_user` text COMMENT 'source user',
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfobeta_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info_beta';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_info_tag   */
/******************************************/
CREATE TABLE `config_info_tag` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
  `tenant_id` varchar(128) DEFAULT '' COMMENT 'tenant_id',
  `tag_id` varchar(128) NOT NULL COMMENT 'tag_id',
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
  `content` longtext NOT NULL COMMENT 'content',
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  `src_user` text COMMENT 'source user',
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfotag_datagrouptenanttag` (`data_id`,`group_id`,`tenant_id`,`tag_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info_tag';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_tags_relation   */
/******************************************/
CREATE TABLE `config_tags_relation` (
  `id` bigint(20) NOT NULL COMMENT 'id',
  `tag_name` varchar(128) NOT NULL COMMENT 'tag_name',
  `tag_type` varchar(64) DEFAULT NULL COMMENT 'tag_type',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
  `tenant_id` varchar(128) DEFAULT '' COMMENT 'tenant_id',
  `nid` bigint(20) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`nid`),
  UNIQUE KEY `uk_configtagrelation_configidtag` (`id`,`tag_name`,`tag_type`),
  KEY `idx_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_tag_relation';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = group_capacity   */
/******************************************/
CREATE TABLE `group_capacity` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `group_id` varchar(128) NOT NULL DEFAULT '' COMMENT 'Group ID，空字符表示整个集群',
  `quota` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值',
  `usage` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '使用量',
  `max_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值',
  `max_aggr_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数，，0表示使用默认值',
  `max_aggr_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值',
  `max_history_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_group_id` (`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='集群、各Group容量信息表';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = his_config_info   */
/******************************************/
CREATE TABLE `his_config_info` (
  `id` bigint(64) unsigned NOT NULL,
  `nid` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `data_id` varchar(255) NOT NULL,
  `group_id` varchar(128) NOT NULL,
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
  `content` longtext NOT NULL,
  `md5` varchar(32) DEFAULT NULL,
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `src_user` text,
  `src_ip` varchar(50) DEFAULT NULL,
  `op_type` char(10) DEFAULT NULL,
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  PRIMARY KEY (`nid`),
  KEY `idx_gmt_create` (`gmt_create`),
  KEY `idx_gmt_modified` (`gmt_modified`),
  KEY `idx_did` (`data_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='多租户改造';


/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = tenant_capacity   */
/******************************************/
CREATE TABLE `tenant_capacity` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `tenant_id` varchar(128) NOT NULL DEFAULT '' COMMENT 'Tenant ID',
  `quota` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值',
  `usage` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '使用量',
  `max_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值',
  `max_aggr_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数',
  `max_aggr_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值',
  `max_history_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='租户容量信息表';


CREATE TABLE `tenant_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `kp` varchar(128) NOT NULL COMMENT 'kp',
  `tenant_id` varchar(128) default '' COMMENT 'tenant_id',
  `tenant_name` varchar(128) default '' COMMENT 'tenant_name',
  `tenant_desc` varchar(256) DEFAULT NULL COMMENT 'tenant_desc',
  `create_source` varchar(32) DEFAULT NULL COMMENT 'create_source',
  `gmt_create` bigint(20) NOT NULL COMMENT '创建时间',
  `gmt_modified` bigint(20) NOT NULL COMMENT '修改时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_tenant_info_kptenantid` (`kp`,`tenant_id`),
  KEY `idx_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='tenant_info';

CREATE TABLE `users` (
	`username` varchar(50) NOT NULL PRIMARY KEY,
	`password` varchar(500) NOT NULL,
	`enabled` boolean NOT NULL
);

CREATE TABLE `roles` (
	`username` varchar(50) NOT NULL,
	`role` varchar(50) NOT NULL,
	UNIQUE INDEX `idx_user_role` (`username` ASC, `role` ASC) USING BTREE
);

CREATE TABLE `permissions` (
    `role` varchar(50) NOT NULL,
    `resource` varchar(255) NOT NULL,
    `action` varchar(8) NOT NULL,
    UNIQUE INDEX `uk_role_permission` (`role`,`resource`,`action`) USING BTREE
);

INSERT INTO users (username, password, enabled) VALUES ('nacos', '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu', TRUE);

INSERT INTO roles (username, role) VALUES ('nacos', 'ROLE_ADMIN');

下载nacos

nacos在GitHub上有下载地址：https://github.com/alibaba/nacos/tags，可以选择任意版本下载。

本例中才用1.4.1版本：

配置Nacos

将这个包解压到任意非中文目录下，如图：

目录说明：

bin：启动脚本
conf：配置文件

进入nacos的conf目录，修改配置文件cluster.conf.example，重命名为cluster.conf：

然后添加内容：

1
2
3

127.0.0.1:8845
127.0.0.1.8846
127.0.0.1.8847

然后修改application.properties文件，添加数据库配置

spring.datasource.platform=mysql

db.num=1

db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=123

启动

将nacos文件夹复制三份，分别命名为：nacos1、nacos2、nacos3

然后分别修改三个文件夹中的application.properties，

nacos1:

1	server.port=8845

nacos2:

1	server.port=8846

nacos3:

1	server.port=8847

然后分别启动三个nacos节点：

1	startup.cmd

nginx反向代理

下载nginx

解压到任意非中文目录下：

修改conf/nginx.conf文件，配置如下：

upstream nacos-cluster {
    server 127.0.0.1:8845;
	server 127.0.0.1:8846;
	server 127.0.0.1:8847;
}

server {
    listen       80;
    server_name  localhost;

    location /nacos {
        proxy_pass http://nacos-cluster;
    }
}

而后在浏览器访问：http://localhost/nacos即可。

代码中application.yml文件配置如下：

spring:
  cloud:
    nacos:
      server-addr: localhost:80 # Nacos地址

Feign远程调用

先来看我们以前利用RestTemplate发起远程调用的代码：

存在下面的问题：

•代码可读性差，编程体验不统一

•参数复杂URL难以维护

Feign是一个声明式的http客户端，官方地址：https://github.com/OpenFeign/feign

其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题。

Feign替代RestTemplate

Fegin的使用步骤如下：

引入依赖

我们在order-service服务的pom文件中引入feign的依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

添加注解

在order-service的启动类添加注解开启Feign的功能：

编写Feign的客户端

在order-service中新建一个接口，内容如下：

package cn.itcast.order.client;

import cn.itcast.order.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient("userservice")
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

这个客户端主要是基于SpringMVC的注解来声明远程调用的信息，比如：

服务名称：userservice
请求方式：GET
请求路径：/user/{id}
请求参数：Long id
返回值类型：User

这样，Feign就可以帮助我们发送http请求，无需自己使用RestTemplate来发送了。

测试

修改order-service中的OrderService类中的queryOrderById方法，使用Feign客户端代替RestTemplate：

总结

使用Feign的步骤：

① 引入依赖

② 添加@EnableFeignClients注解

③ 编写FeignClient接口

④ 使用FeignClient中定义的方法代替RestTemplate

自定义配置

Feign可以支持很多的自定义配置，如下表所示：

类型	作用	说明
feign.Logger.Level	修改日志级别	包含四种不同的级别：NONE、BASIC、HEADERS、FULL
feign.codec.Decoder	响应结果的解析器	http远程调用的结果做解析，例如解析json字符串为java对象
feign.codec.Encoder	请求参数编码	将请求参数编码，便于通过http请求发送
feign. Contract	支持的注解格式	默认是SpringMVC的注解
feign. Retryer	失败重试机制	请求失败的重试机制，默认是没有，不过会使用Ribbon的重试

一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认Bean即可。

下面以日志为例来演示如何自定义配置。

配置文件方式

基于配置文件修改feign的日志级别可以针对单个服务：

feign:  
  client:
    config: 
      userservice: # 针对某个微服务的配置
        loggerLevel: FULL #  日志级别

也可以针对所有服务：

feign:  
  client:
    config: 
      default: # 这里用default就是全局配置，如果是写服务名称，则是针对某个微服务的配置
        loggerLevel: FULL #  日志级别

而日志的级别分为四种：

NONE：不记录任何日志信息，这是默认值。
BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

Java代码方式

也可以基于Java代码来修改日志级别，先声明一个类，然后声明一个Logger.Level的对象：

public class DefaultFeignConfiguration  {
    @Bean
    public Logger.Level feignLogLevel(){
        return Logger.Level.BASIC; // 日志级别为BASIC
    }
}

如果要全局生效，将其放到启动类的@EnableFeignClients这个注解中：

1	@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class)

如果是局部生效，则把它放到对应的@FeignClient这个注解中：

1	@FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class)

Feign优化

Feign底层发起http请求，依赖于其它的框架。其底层客户端实现包括：

•URLConnection：默认实现，不支持连接池

•Apache HttpClient ：支持连接池

•OKHttp：支持连接池

因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection。

这里用Apache的HttpClient来演示。

引入依赖

在order-service的pom文件中引入Apache的HttpClient依赖：

<!--httpClient的依赖 -->
<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-httpclient</artifactId>
</dependency>

配置连接池

在order-service的application.yml中添加配置：

feign:
  client:
    config:
      default: # default全局的配置
        loggerLevel: BASIC # 日志级别，BASIC就是基本的请求和响应信息
  httpclient:
    enabled: true # 开启feign对HttpClient的支持
    max-connections: 200 # 最大的连接数
    max-connections-per-route: 50 # 每个路径的最大连接数

Feign的优化：

1.日志级别尽量用basic

2.使用HttpClient或OKHttp代替URLConnection

① 引入feign-httpClient依赖

② 配置文件开启httpClient功能，设置连接池参数

Feign的最佳实践

所谓最佳实践，就是使用过程中总结的经验，最好的一种使用方式。

自习观察可以发现，Feign的客户端与服务提供者的controller代码非常相似：

feign客户端：

userController：

有没有一种办法简化这种重复的代码编写呢？

继承方式

一样的代码可以通过继承来共享：

1）定义一个API接口，利用定义方法，并基于SpringMVC注解做声明。

2）Feign客户端和Controller都集成改接口

优点：

简单
实现了代码共享

缺点：

服务提供方、服务消费方紧耦合
参数列表中的注解映射并不会继承，因此Controller中必须再次声明方法、参数列表、注解

抽取方式

将Feign的Client抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用。

例如，将UserClient、User、Feign的默认配置都抽取到一个feign-api包中，所有微服务引用该依赖包，即可直接使用。

实现基于抽取的最佳实践

抽取

首先创建一个module，命名为feign-api：

项目结构：

在feign-api中然后引入feign的starter依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

然后，order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中

在order-service中使用feign-api

首先，删除order-service中的UserClient、User、DefaultFeignConfiguration等类或接口。

在order-service的pom文件中中引入feign-api的依赖：

<dependency>
    <groupId>cn.itcast.demo</groupId>
    <artifactId>feign-api</artifactId>
    <version>1.0</version>
</dependency>

修改order-service中的所有与上述三个组件有关的导包部分，改成导入feign-api中的包

重启测试

重启后，发现服务报错了：

这是因为UserClient现在在cn.itcast.feign.clients包下，

而order-service的@EnableFeignClients注解是在cn.itcast.order包下，不在同一个包，无法扫描到UserClient。

解决扫描包问题

方式一：

指定Feign应该扫描的包：

1	@EnableFeignClients(basePackages = "cn.itcast.feign.clients")

方式二：

指定需要加载的Client接口：

1	@EnableFeignClients(clients = {UserClient.class})

Gateway网关

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

为什么需要网关

Gateway网关是我们服务的守门神，所有微服务的统一入口。

网关的核心功能特性：

请求路由
权限控制
限流

架构图：

权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。

路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。

限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

在SpringCloud中网关的实现包括两种：

gateway
zuul

Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。

gateway快速入门

下面，我们就演示下网关的基本路由功能。基本步骤如下：

创建SpringBoot工程gateway，引入网关依赖
编写启动类
编写基础配置和路由规则
启动网关服务进行测试

创建gateway服务，引入依赖

创建服务：

引入依赖

<!--网关-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!--nacos服务发现依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

编写启动类

package cn.itcast.gateway;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class GatewayApplication {

	public static void main(String[] args) {
		SpringApplication.run(GatewayApplication.class, args);
	}
}

编写基础配置和路由规则

创建application.yml文件，内容如下：

server:
  port: 10010 # 网关端口
spring:
  application:
    name: gateway # 服务名称
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos地址
    gateway:
      routes: # 网关路由配置
        - id: user-service # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://userservice # 路由的目标地址 lb就是负载均衡，后面跟服务名称
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求

重启测试

重启网关，访问http://localhost:10010/user/1时，符合`/user/**`规则，请求转发到uri：http://userservice/user/1，得到了结果：

网关路由的流程图

整个访问的流程如下：

总结：

网关搭建步骤：

创建项目，引入nacos服务发现和gateway依赖
配置application.yml，包括服务基本信息、nacos地址、路由

路由配置包括：

路由id：路由的唯一标示
路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡
路由断言（predicates）：判断路由的规则，
路由过滤器（filters）：对请求或响应做处理

断言工厂

我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件

例如Path=/user/**是按照路径匹配，这个规则是由

org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来

处理的，像这样的断言工厂在SpringCloudGateway还有十几个:

名称	说明	示例
After	是某个时间点后的请求	- After=2037-01-20T17:42:47.789-07:00[America/Denver]
Before	是某个时间点之前的请求	- Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]
Between	是某两个时间点之前的请求	- Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver]
Cookie	请求必须包含某些cookie	- Cookie=chocolate, ch.p
Header	请求必须包含某些header	- Header=X-Request-Id, \d+
Host	请求必须是访问某个host（域名）	- Host=.somehost.org,.anotherhost.org
Method	请求方式必须是指定方式	- Method=GET,POST
Path	请求路径必须符合指定规则	- Path=/red/{segment},/blue/**
Query	请求参数必须包含指定参数	- Query=name, Jack或者- Query=name
RemoteAddr	请求者的ip必须是指定范围	- RemoteAddr=192.168.1.1/24
Weight	权重处理

我们只需要掌握Path这种路由工程就可以了。

过滤器工厂

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理：

路由过滤器的种类

Spring提供了31种不同的路由过滤器工厂。例如：

名称	说明
AddRequestHeader	给当前请求添加一个请求头
RemoveRequestHeader	移除请求中的一个请求头
AddResponseHeader	给响应结果中添加一个响应头
RemoveResponseHeader	从响应结果中移除有一个响应头
RequestRateLimiter	限制请求的流量

请求头过滤器

下面我们以AddRequestHeader 为例来讲解。

需求：给所有进入userservice的请求添加一个请求头：Truth=xxx is freaking awesome!

只需要修改gateway服务的application.yml文件，添加路由过滤即可：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://userservice 
        predicates: 
        - Path=/user/** 
        filters: # 过滤器
        - AddRequestHeader=Truth, Itcast is freaking awesome! # 添加请求头

当前过滤器写在userservice路由下，因此仅仅对访问userservice的请求有效。

默认过滤器

如果要对所有的路由都生效，则可以将过滤器工厂写到default下。格式如下：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://userservice 
        predicates: 
        - Path=/user/**
      default-filters: # 默认过滤项
      - AddRequestHeader=Truth, Itcast is freaking awesome!

总结

过滤器的作用是什么？

① 对路由的请求或响应做加工处理，比如添加请求头

② 配置在路由下的过滤器只对当前路由的请求生效

defaultFilters的作用是什么？

① 对所有路由都生效的过滤器

全局过滤器

上一节学习的过滤器，网关提供了31种，但每一种过滤器的作用都是固定的。如果我们希望拦截请求，做自己的业务逻辑则没办法实现。

3.5.1.全局过滤器作用

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义，处理逻辑是固定的；而GlobalFilter的逻辑需要自己写代码实现。

定义方式是实现GlobalFilter接口。

public interface GlobalFilter {
    /**
     *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
     *
     * @param exchange 请求上下文，里面可以获取Request、Response等信息
     * @param chain 用来把请求委托给下一个过滤器 
     * @return {@code Mono<Void>} 返回标示当前过滤器业务结束
     */
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

在filter中编写自定义逻辑，可以实现下列功能：

登录状态判断
权限校验
请求限流等

自定义全局过滤器

需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：

参数中是否有authorization，
authorization参数值是否为admin

如果同时满足则放行，否则拦截

实现：

在gateway中定义一个过滤器：

package cn.itcast.gateway.filters;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.annotation.Order;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Order(-1)
@Component
public class AuthorizeFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取请求参数
        MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
        // 2.获取authorization参数
        String auth = params.getFirst("authorization");
        // 3.校验
        if ("admin".equals(auth)) {
            // 放行
            return chain.filter(exchange);
        }
        // 4.拦截
        // 4.1.禁止访问，设置状态码
        exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
        // 4.2.结束处理
        return exchange.getResponse().setComplete();
    }
}

过滤器执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter

请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器：

排序的规则是什么呢？

每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定
路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

详细内容，可以查看源码：

org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getFilters()方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。

org.springframework.cloud.gateway.handler.FilteringWebHandler#handle()方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链

跨域问题

什么是跨域问题

跨域：域名不一致就是跨域，主要包括：

域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com
域名相同，端口不同：localhost:8080和localhost8081

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题

解决方案：CORS，这个以前应该学习过，这里不再赘述了。不知道的小伙伴可以查看https://www.ruanyifeng.com/blog/2016/04/cors.html

3.6.2.模拟跨域问题

创建一个html页面

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Document</title>
</head>
<body>
<pre>
spring:
  cloud:
    gateway:
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求
              - "http://localhost:8090"
              - "http://www.leyou.com"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期
</pre>
</body>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
<script>
  axios.get("http://localhost:10010/user/1?authorization=admin")
  .then(resp => console.log(resp.data))
  .catch(err => console.log(err))
</script>
</html>

放入tomcat或者nginx这样的web服务器中，启动并访问。

可以在浏览器控制台看到下面的错误：

从localhost:8090访问localhost:10010，端口不同，显然是跨域的请求。

解决跨域问题

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      # 。。。
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "http://localhost:8090"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期

Docker

初识Docker

什么是Docker

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

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

应用部署的环境问题

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

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

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

Docker解决依赖兼容问题

而Docker确巧妙的解决了这些问题，Docker是如何实现的呢？

Docker为了解决依赖的兼容问题的，采用了两个手段：

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

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

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

Docker解决操作系统环境差异

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

结构包括：

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

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

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

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

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

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

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

Docker如何解决不同系统环境的问题？

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

如图：

小结

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

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

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

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

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

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

Docker和虚拟机的区别

Docker可以让一个应用在任何操作系统中非常方便的运行。而以前我们接触的虚拟机，也能在一个操作系统中，运行另外一个操作系统，保护系统中的任何应用。

两者有什么差异呢？

虚拟机（virtual machine）是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行 Ubuntu 系统，这样就可以运行任意的Ubuntu应用了。

Docker仅仅是封装函数库，并没有模拟完整的操作系统，如图：

对比来看：

小结：

Docker和虚拟机的差异：

docker是一个系统进程；虚拟机是在操作系统中的操作系统
docker体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般

Docker架构

镜像和容器

Docker中有几个重要的概念：

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

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

一切应用最终都是代码组成，都是硬盘中的一个个的字节形成的文件。只有运行时，才会加载到内存，形成进程。

而镜像，就是把一个应用在硬盘上的文件、及其运行环境、部分系统函数库文件一起打包形成的文件包。这个文件包是只读的。

容器呢，就是将这些文件中编写的程序、函数加载到内存中允许，形成进程，只不过要隔离起来。因此一个镜像可以启动多次，形成多个容器进程。

例如你下载了一个QQ，如果我们将QQ在磁盘上的运行文件及其运行的操作系统依赖打包，形成QQ镜像。然后你可以启动多次，双开、甚至三开QQ，跟多个妹子聊天。

DockerHub

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

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

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

Docker架构

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

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

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

如图：

小结

镜像：

将应用程序及其依赖、环境、配置打包在一起

容器：

镜像运行起来就是容器，一个镜像可以运行多个容器

Docker结构：

服务端：接收命令或远程请求，操作镜像或容器
客户端：发送命令或者请求到Docker服务端

DockerHub：

一个镜像托管的服务器，类似的还有阿里云镜像服务，统称为DockerRegistry

Docker安装

详见笔记Docker.md

Docker基本操作

镜像操作

镜像名称

首先来看下镜像的名称组成：

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

如图：

这里的mysql就是repository，5.7就是tag，合一起就是镜像名称，代表5.7版本的MySQL镜像。

镜像命令

常见的镜像操作命令如图：

拉取、查看镜像

从DockerHub中拉取一个nginx镜像并查看

镜像仓库搜索nginx镜像，如：DockerHUB

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

保存、导入镜像

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

利用docker xx –help命令查看docker save和docker load的语法

1 2	# 查看save命令的用法 docker save --help

命令格式：

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

使用docker save导出镜像到磁盘
1
dicker save -o nginx.tar nginx:latest
使用docker load加载镜像

先删除本地的nginx镜像：

1	docker rmi nginx:latest

加载本地文件：

1	docker load -i nginx.tar

容器操作

容器相关命令

容器操作的命令如图：

容器保护三个状态：

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

其中：

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

创建并运行一个容器

创建并运行nginx容器的命令：

1	docker run --name containerName -p 80:80 -d nginx

命令解读：

docker run ：创建并运行一个容器
–name : 给容器起一个名字，比如叫做mn
-p ：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口
-d：后台运行容器
nginx：镜像名称，例如nginx

这里的-p参数，是将容器端口映射到宿主机端口。

默认情况下，容器是隔离环境，我们直接访问宿主机的80端口，肯定访问不到容器中的nginx。

现在，将容器的80与宿主机的80关联起来，当我们访问宿主机的80端口时，就会被映射到容器的80，这样就能访问到nginx了：

进入容器修改文件

进入Nginx容器，修改HTML文件内容，添加“nginx欢迎您”

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

1	docker exec -it mn bash

命令解读：

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

进入nginx的HTML所在目录 /usr/share/nginx/html

容器内部会模拟一个独立的Linux文件系统，看起来如同一个linux服务器一样：

nginx的环境、配置、运行文件全部都在这个文件系统中，包括我们要修改的html文件。

查看DockerHub网站中的nginx页面，可以知道nginx的html目录位置在/usr/share/nginx/html

我们执行命令，进入该目录：

1	cd /usr/share/nginx/html

查看目录下文件：

修改index.html的内容

容器内没有vi命令，无法直接修改，我们用下面的命令来修改：

1	sed -i -e 's#Welcome to nginx#nginx欢迎您#g' -e 's#<head>#<head><meta charset="utf-8">#g' index.html

在浏览器访问自己的虚拟机地址，例如我的是：http://192.168.88.155:81，即可看到结果：

小结

docker run命令的常见参数有哪些？

–name：指定容器名称
-p：指定端口映射
-d：让容器后台运行

查看容器日志的命令：

docker logs
添加 -f 参数可以持续查看日志

查看容器状态：

docker ps
docker ps -a 查看所有容器，包括已经停止的

数据卷（容器数据管理）

在之前的nginx案例中，修改nginx的html页面时，需要进入nginx内部。并且因为没有编辑器，修改文件也很麻烦。

这就是因为容器与数据（容器内文件）耦合带来的后果。

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

什么是数据卷

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

一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。

这样，我们操作宿主机的/var/lib/docker/volumes/html目录，就等于操作容器内的/usr/share/nginx/html目录了

数据集操作命令

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

1	docker volume [COMMAND]

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

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

创建和查看数据卷

需求：创建一个数据卷，并查看数据卷在宿主机的目录位置

① 创建数据卷

1	docker volume create 数据卷名

② 查看数据卷

1	docker volume ls

结果：

③ 查看数据卷详细信息卷

1	docker volume inspect fds

小结：

数据卷的作用：

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

数据卷操作：

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内容

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

1	docker volume create html

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

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

Dockerfile自定义镜像

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

而要自定义镜像，就必须先了解镜像的结构才行。

镜像结构

镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。

我们以MySQL为例，来看看镜像的组成结构：

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

我们要构建镜像，其实就是实现上述打包的过程。

Dockerfile语法

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

我们只需要告诉Docker，我们的镜像的组成，需要哪些BaseImage、需要拷贝什么文件、需要安装什么依赖、启动脚本是什么，将来Docker会帮助我们构建镜像。

而描述上述信息的文件就是Dockerfile文件。

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

更新详细语法说明，请参考官网文档： https://docs.docker.com/engine/reference/builder

构建Java项目

基于Ubuntu构建Java项目

需求：基于Ubuntu镜像构建一个新镜像，运行一个java项目

步骤1：新建一个空文件夹docker-demo

步骤2：拷贝课前资料中的docker-demo.jar文件到docker-demo这个目录

步骤3：拷贝课前资料中的jdk8.tar.gz文件到docker-demo这个目录

步骤4：拷贝课前资料提供的Dockerfile到docker-demo这个目录

其中的内容如下：

# 指定基础镜像
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

步骤5：进入docker-demo

将准备好的docker-demo上传到虚拟机任意目录，然后进入docker-demo目录下
步骤6：运行命令：
1
docker build -t javaweb:1.0 .

最后访问 http://192.168.150.101:8090/hello/count，其中的ip改成你的虚拟机ip

基于java8构建Java项目

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

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

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

实现思路如下：

① 新建一个空的目录，然后在目录中新建一个文件，命名为Dockerfile
② 拷贝课前资料提供的docker-demo.jar到这个目录中
③ 编写Dockerfile文件：
- a ）基于java:8-alpine作为基础镜像
- b ）将app.jar拷贝到镜像中
- c ）暴露端口
- d ）编写入口ENTRYPOINT
  
  内容如下：
  1
  2
  3
  4
  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。也可以是其他人制作好的镜像，例如：java:8-alpine

DockerCompose

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

初识DockerCompose

Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行。格式如下：

version: "3.8"
 services:
  mysql:
    image: mysql:5.7.25
    environment:
     MYSQL_ROOT_PASSWORD: 123 
    volumes:
     - "/tmp/mysql/data:/var/lib/mysql"
     - "/tmp/mysql/conf/hmy.cnf:/etc/mysql/conf.d/hmy.cnf"
  web:
    build: .
    ports:
     - "8090:8090"

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

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

DockerCompose的详细语法参考官网：https://docs.docker.com/compose/compose-file/

其实DockerCompose文件可以看做是将多个docker run命令写到一个文件，只是语法稍有差异。

安装DockerCompose

下载

Linux下需要通过命令下载：

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

如果下载速度较慢，或者下载失败，可以使用课前资料提供的docker-compose文件：

上传到/usr/local/bin/目录也可以。

修改文件权限

修改文件权限：

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

Base自动补全命令

1 2	# 补全命令 curl -L https://raw.githubusercontent.com/docker/compose/1.29.1/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

如果这里出现错误，需要修改自己的hosts文件：

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

部署微服务集群

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

实现思路：

① 查看课前资料提供的cloud-demo文件夹，里面已经编写好了docker-compose文件

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

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

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

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

compose文件

查看课前资料提供的cloud-demo文件夹，里面已经编写好了docker-compose文件，而且每个微服务都准备了一个独立的目录：

内容如下：

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"

可以看到，其中包含5个service服务：

nacos：作为注册中心和配置中心
- image: nacos/nacos-server：基于nacos/nacos-server镜像构建
- environment：环境变量
  - MODE: standalone：单点模式启动
- ports：端口映射，这里暴露了8848端口
mysql：数据库
- image: mysql:5.7.25：镜像版本是mysql:5.7.25
- environment：环境变量
  - MYSQL_ROOT_PASSWORD: 123：设置数据库root账户的密码为123
- volumes：数据卷挂载，这里挂载了mysql的data、conf目录，其中有我提前准备好的数据
userservice、orderservice、gateway：都是基于Dockerfile临时构建的

查看mysql目录，可以看到其中已经准备好了cloud_order、cloud_user表：

查看微服务目录，可以看到都包含Dockerfile文件：

内容如下：

1
2
3

FROM java:8-alpine
COPY ./app.jar /tmp/app.jar
ENTRYPOINT java -jar /tmp/app.jar

修改微服务配置

因为微服务将来要部署为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服务地址

打包

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

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

<build>
  <!-- 服务打包的最终名称 -->
  <finalName>app</finalName>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

打包后：

拷贝jar包到部署目录

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

user-service：

order-service：

gateway：

部署

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

上传到任意目录：

部署：

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

1	docker-compose up -d

Docker镜像仓库

搭建镜像仓库可以基于Docker官方提供的DockerRegistry来实现。

官网地址：https://hub.docker.com/_/registry

搭建私有镜像仓库

简化版镜像仓库

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

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

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

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

访问http://YourIp:5000/v2/_catalog 可以查看当前私有镜像服务中包含的镜像

带有图形化界面版本

使用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://192.168.150.101:8080"]
# 重加载
systemctl daemon-reload
# 重启docker
systemctl restart docker

推送拉去镜像

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

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

1	docker tag nginx:latest 192.168.150.101:8080/nginx:1.0

② 推送镜像

1	docker push 192.168.150.101:8080/nginx:1.0

③ 拉取镜像

1	docker pull 192.168.150.101:8080/nginx:1.0

RabbitMQ

初识MQ

同步和异步通讯

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

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

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

两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件，但是往往响应会有延迟。

同步通讯

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

总结：

同步调用的优点：

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

同步调用的问题：

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

异步通讯

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

我们以购买商品为例，用户支付后需要调用订单服务完成订单状态修改，调用物流服务，从仓库分配响应的库存并准备发货。

在事件模式中，支付服务是事件发布者（publisher），在支付完成后只需要发布一个支付成功的事件（event），事件中带上订单id。

订单服务和物流服务是事件订阅者（Consumer），订阅支付成功的事件，监听到事件后完成自己业务即可。

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

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

好处：

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

缺点：

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

技术对比

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

比较常见的MQ实现：

ActiveMQ
RabbitMQ
RocketMQ
Kafka

几种常见MQ的对比：

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

追求可用性：Kafka、 RocketMQ 、RabbitMQ

追求可靠性：RabbitMQ、RocketMQ

追求吞吐能力：RocketMQ、Kafka

追求消息低延迟：RabbitMQ、Kafka

快速入门

安装RabbitMQ

单机部署

我们在Centos7虚拟机中使用Docker来安装。

下载镜像

方式一：在线拉取

1	docker pull rabbitmq:3-management

方式二：从本地加载

…….

上传到虚拟机中后，使用命令加载镜像即可：

1	docker load -i mq.tar

安装MQ

执行下面的命令来运行MQ容器：

docker run \
 -e RABBITMQ_DEFAULT_USER=raehp \ # 账号
 -e RABBITMQ_DEFAULT_PASS=123456 \ # 密码
 --name mq \ # 别名
 --hostname mq1 \ # 主机名（集群使用）
 -p 15672:15672 \
 -p 5672:5672 \
 -d \
 rabbitmq:3-management

集群部署

接下来，我们看看如何安装RabbitMQ的集群。

集群分类

在RabbitMQ的官方文档中，讲述了两种集群的配置方式：

普通模式：普通模式集群不进行数据同步，每个MQ都有自己的队列、数据信息（其它元数据信息如交换机等会同步）。例如我们有2个MQ：mq1，和mq2，如果你的消息在mq1，而你连接到了mq2，那么mq2会去mq1拉取消息，然后返回给你。如果mq1宕机，消息就会丢失。
镜像模式：与普通模式不同，队列会在各个mq的镜像节点之间同步，因此你连接到任何一个镜像节点，均可获取到消息。而且如果一个节点宕机，并不会导致数据丢失。不过，这种方式增加了数据同步的带宽消耗。

我们先来看普通模式集群。

设置网络

首先，我们需要让3台MQ互相知道对方的存在。

分别在3台机器中，设置 /etc/hosts文件，添加如下内容：

1
2
3

192.168.150.101 mq1
192.168.150.102 mq2
192.168.150.103 mq3

并在每台机器上测试，是否可以ping通对方：

MQ基本结构

RabbitMQ中的一些角色：

publisher：生产者
consumer：消费者
exchange个：交换机，负责消息路由
queue：队列，存储消息
virtualHost：虚拟主机，隔离不同租户的exchange、queue、消息的隔离

RabbitMQ消息模型

RabbitMQ官方提供了5个不同的Demo示例，对应了不同的消息模型：

入门案例

简单队列模式的模型图：

官方的HelloWorld是基于最基础的消息队列模型来实现的，只包括三个角色：

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

publisher实现

思路：

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

代码实现：

package cn.itcast.mq.helloworld;

import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import org.junit.Test;

import java.io.IOException;
import java.util.concurrent.TimeoutException;

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

    }
}

consumer实现

代码思路：

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

代码实现：

package cn.itcast.mq.helloworld;

import com.rabbitmq.client.*;

import java.io.IOException;
import java.util.concurrent.TimeoutException;

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

总结

基本消息队列的消息发送流程：

建立connection
创建channel
利用channel声明队列
利用channel向队列发送消息

基本消息队列的消息接收流程：

建立connection
创建channel
利用channel声明队列
定义consumer的消费行为handleDelivery()
利用channel将消费者与队列绑定

SpringAMQP

SpringAMQP是基于RabbitMQ封装的一套模板，并且还利用SpringBoot对其实现了自动装配，使用起来非常方便。

SpringAmqp的官方地址：https://spring.io/projects/spring-amqp

SpringAMQP提供了三个功能：

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

Basic Queue 简单队列模型

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

<!--AMQP依赖，包含RabbitMQ-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

消息发送

首先配置MQ地址，在publisher服务的application.yml中添加配置：

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

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

package cn.itcast.mq.spring;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAmqpTest {

    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    public void testSimpleQueue() {
        // 队列名称
        String queueName = "simple.queue";
        // 消息
        String message = "这是使用RabbitTemplate发送的消息!";
        // 发送消息
        rabbitTemplate.convertAndSend(queueName, message);
    }
}

消息接收

首先配置MQ地址，在consumer服务的application.yml中添加配置：

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

然后在consumer服务的cn.itcast.mq.listener包中新建一个类SpringRabbitListener，代码如下：

package cn.itcast.mq.listener;

import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

@Component
public class SpringRabbitListener {

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

测试

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

WorkQueue

Work queues，也被称为（Task queues），任务模型。简单来说就是让多个消费者绑定到一个队列，共同消费队列中的消息。

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

此时就可以使用work 模型，多个消费者共同处理消息处理，速度就能大大提高了。

消息发送

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

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

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

消息接收

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

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

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

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

测试

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

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

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

能者多劳

在spring中有一个简单的配置，可以解决这个问题。我们修改consumer服务的application.yml文件，添加配置：

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

总结

Work模型的使用：

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

发布/订阅

发布订阅的模型如图：

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

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

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

Fanout

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

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

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

我们的计划是这样的：

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

声明队列和交换机

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

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

package cn.itcast.mq.config;

import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.FanoutExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FanoutConfig {
    /**
     * 声明交换机
     * @return Fanout类型交换机
     */
    @Bean
    public FanoutExchange fanoutExchange(){
        return new FanoutExchange("itcast.fanout");
    }

    /**
     * 第1个队列
     */
    @Bean
    public Queue fanoutQueue1(){
        return new Queue("fanout.queue1");
    }

    /**
     * 绑定队列和交换机
     */
    @Bean
    public Binding bindingQueue1(Queue fanoutQueue1, FanoutExchange fanoutExchange){
        return BindingBuilder.bind(fanoutQueue1).to(fanoutExchange);
    }

    /**
     * 第2个队列
     */
    @Bean
    public Queue fanoutQueue2(){
        return new Queue("fanout.queue2");
    }

    /**
     * 绑定队列和交换机
     */
    @Bean
    public Binding bindingQueue2(Queue fanoutQueue2, FanoutExchange fanoutExchange){
        return BindingBuilder.bind(fanoutQueue2).to(fanoutExchange);
    }
}

消息发送

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

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

消息接收

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

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

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

总结

交换机的作用是什么？

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

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

Queue
FanoutExchange
Binding

Direct

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

在Direct模型下：

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

案例需求如下：

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

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

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

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

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

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

消息发送

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

@Test
public void testSendDirectExchange() {
    // 交换机名称
    String exchangeName = "itcast.direct";
    // 消息
    String message = "红色警报！日本乱排核废水，导致海洋生物变异，惊现哥斯拉！";
    // 发送消息
    rabbitTemplate.convertAndSend(exchangeName, "red", message);
}

总结

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

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

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

@Queue
@Exchange

Topic

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

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

通配符规则：

#：匹配一个或多个词

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

举例：

item.#：能够匹配item.spu.insert 或者 item.spu

item.*：只能匹配item.spu

图示：

解释：

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

案例需求：

实现思路如下：

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

消息发送

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

/**
     * topicExchange
     */
@Test
public void testSendTopicExchange() {
    // 交换机名称
    String exchangeName = "itcast.topic";
    // 消息
    String message = "喜报！孙悟空大战哥斯拉，胜!";
    // 发送消息
    rabbitTemplate.convertAndSend(exchangeName, "china.news", message);
}

消息接收

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

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

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

总结

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

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

消息转换器

测试默认转换器

我们修改消息发送的代码，发送一个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方式来做序列化和反序列化。

在publisher和consumer两个服务中都引入依赖：

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

配置消息转换器。

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

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

分布式搜索引擎

初识elasticsearch

了解ES

elasticsearch的作用

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

例如：

在GitHub搜索代码

在电商网站搜索商品

在谷歌搜索答案

在打车软件搜索附近的车

ELK技术栈

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

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

elasticsearch和lucene

elasticsearch底层是基于lucene来实现的。

Lucene是一个Java语言的搜索引擎类库，是Apache公司的顶级项目，由DougCutting于1999年研发。官网地址：https://lucene.apache.org/ 。

elasticsearch的发展历史：

2004年Shay Banon基于Lucene开发了Compass
2010年Shay Banon 重写了Compass，取名为Elasticsearch。

为什么不是其他搜索技术？

目前比较知名的搜索引擎技术排名：

虽然在早期，Apache Solr是最主要的搜索引擎技术，但随着发展elasticsearch已经渐渐超越了Solr，独占鳌头：

总结

什么是elasticsearch？

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

什么是elastic stack（ELK）？

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

什么是Lucene？

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

倒排索引

倒排索引的概念是基于MySQL这样的正向索引而言的。

正向索引

那么什么是正向索引呢？例如给下表（tb_goods）中的id创建索引：

如果是根据id查询，那么直接走索引，查询速度非常快。

但如果是基于title做模糊查询，只能是逐行扫描数据，流程如下：

1）用户搜索数据，条件是title符合"%手机%"

2）逐行获取数据，比如id为1的数据

3）判断数据中的title是否符合用户搜索条件

4）如果符合则放入结果集，不符合则丢弃。回到步骤1

逐行扫描，也就是全表扫描，随着数据量增加，其查询效率也会越来越低。当数据量达到数百万时，就是一场灾难。

倒排索引

倒排索引中有两个非常重要的概念：

文档（Document）：用来搜索的数据，其中的每一条数据就是一个文档。例如一个网页、一个商品信息
词条（Term）：对文档数据或用户搜索数据，利用某种算法分词，得到的具备含义的词语就是词条。例如：我是中国人，就可以分为：我、是、中国人、中国、国人这样的几个词条

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

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

如：

倒排索引的搜索流程如下（以搜索”华为手机”为例）：

1）用户输入条件"华为手机"进行搜索。

2）对用户输入内容分词，得到词条：华为、手机。

3）拿着词条在倒排索引中查找，可以得到包含词条的文档id：1、2、3。

4）拿着文档id到正向索引中查找具体文档。

如图：

虽然要先查询倒排索引，再查询倒排索引，但是无论是词条、还是文档id都建立了索引，查询速度非常快！无需全表扫描。

正向和倒排

那么为什么一个叫做正向索引，一个叫做倒排索引呢？

正向索引是最传统的，根据id索引的方式。但根据词条查询时，必须先逐条获取每个文档，然后判断文档中是否包含所需要的词条，是根据文档找词条的过程。
而倒排索引则相反，是先找到用户要搜索的词条，根据词条得到保护词条的文档的id，然后根据id获取文档。是根据词条找文档的过程。

两者方式的优缺点：

正向索引：

优点：
- 可以给多个字段创建索引
- 根据索引字段搜索、排序速度非常快
缺点：
- 根据非索引字段，或者索引字段中的部分词条查找时，只能全表扫描。

倒排索引：

优点：
- 根据词条搜索、模糊搜索时，速度非常快
缺点：
- 只能给词条创建索引，而不是字段
- 无法根据字段做排序

es的一些概念

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

文档和字段

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

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

索引和映射

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

例如：

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

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

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

mysql与elasticsearch

我们统一的把mysql与elasticsearch的概念做一下对比：

MySQL	Elasticsearch	说明
Table	Index	索引(index)，就是文档的集合，类似数据库的表(table)
Row	Document	文档（Document），就是一条条的数据，类似数据库中的行（Row），文档都是JSON格式
Column	Field	字段（Field），就是JSON文档中的字段，类似数据库中的列（Column）
Schema	Mapping	Mapping（映射）是索引中文档的约束，例如字段类型约束。类似数据库的表结构（Schema）
SQL	DSL	DSL是elasticsearch提供的JSON风格的请求语句，用来操作elasticsearch，实现CRUD

是不是说，我们学习了elasticsearch就不再需要mysql了呢？

并不是如此，两者各自有自己的擅长支出：

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

因此在企业中，往往是两者结合使用：

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

安装es、kibana

部署单点es

创建网络

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

1	docker network create es-net

加载镜像

这里我们采用elasticsearch的7.12.1版本的镜像

1	docker pull elasticsearch:7.12.1

然后运行命令加载即可：

1 2	# 导入数据 docker load -i es.tar

同理还有kibana的tar包也需要这样做。

运行

运行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：端口映射配置

在浏览器中输入：http://192.168.88.155:9200 即可看到elasticsearch的响应结果：

部署kibana

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

部署

运行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启动一般比较慢，需要多等待一会，可以通过命令：

1	docker logs -f kibana

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

此时，在浏览器输入地址访问：http://192.168.88.155:5601，即可看到结果

DevTools

kibana中提供了一个DevTools界面：

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

安装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

重启容器

1 2	# 4、重启容器 docker restart es

1 2	# 查看es日志 docker logs -f es

测试：

IK分词器包含两种模式：

ik_smart：最少切分
ik_max_word：最细切分

GET /_analyze
{
  "analyzer": "ik_max_word",
  "text": "学习es真的太棒了"
}

结果：

{
  "tokens" : [
    {
      "token" : "学习",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "CN_WORD",
      "position" : 0
    },
    {
      "token" : "es",
      "start_offset" : 2,
      "end_offset" : 4,
      "type" : "ENGLISH",
      "position" : 1
    },
    {
      "token" : "真的",
      "start_offset" : 4,
      "end_offset" : 6,
      "type" : "CN_WORD",
      "position" : 2
    },
    {
      "token" : "太棒了",
      "start_offset" : 6,
      "end_offset" : 9,
      "type" : "CN_WORD",
      "position" : 3
    },
    {
      "token" : "太棒",
      "start_offset" : 6,
      "end_offset" : 8,
      "type" : "CN_WORD",
      "position" : 4
    },
    {
      "token" : "了",
      "start_offset" : 8,
      "end_offset" : 9,
      "type" : "CN_CHAR",
      "position" : 5
    }
  ]
}

扩用词词典

随着互联网的发展，“造词运动”也越发的频繁。出现了很多新的词语，在原有的词汇列表中并不存在。比如：“奥力给”，“传智播客” 等。

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

IKAnalyzer.cfg.xml配置文件内容添加：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
        <comment>IK Analyzer 扩展配置</comment>
        <!--用户可以在这里配置自己的扩展字典 *** 添加扩展词典-->
        <entry key="ext_dict">ext.dic</entry>
</properties>

新建一个 ext.dic，可以参考config目录下复制一个配置文件进行修改

1
2
3

奥里给
鸡你太美
巴雷特

重启elasticsearch

docker restart es

# 查看 日志
docker logs -f elasticsearch

测试

GET /_analyze
{
  "analyzer": "ik_smart",
  "text": "鸡你太美的巴雷特真是奥里给"
}

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

停用词词典

在互联网项目中，在网络间传输的速度很快，所以很多语言是不允许在网络上传递的，如：关于宗教、政治等敏感词语，那么我们在搜索时也应该忽略当前词汇。

IK分词器也提供了强大的停用词功能，让我们在索引时就直接忽略当前的停用词汇表中的内容。

IKAnalyzer.cfg.xml配置文件内容添加：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
        <comment>IK Analyzer 扩展配置</comment>
        <!--用户可以在这里配置自己的扩展字典-->
        <entry key="ext_dict">ext.dic</entry>
         <!--用户可以在这里配置自己的扩展停止词字典  *** 添加停用词词典-->
        <entry key="ext_stopwords">stopword.dic</entry>
</properties>

在 stopword.dic 添加停用词

的
了
哦
嗯
啊
吗

重启elasticsearch

# 重启服务
docker restart elasticsearch
docker restart kibana

# 查看 日志
docker logs -f elasticsearch

测试效果：

GET /_analyze
{
  "analyzer": "ik_max_word",
  "text": "你吃饭了吗？你吃的饭好吃吗？你在干嘛啊？"
}

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

部署es集群

部署es集群可以直接使用docker-compose来完成，不过要求你的Linux虚拟机至少有4G的内存空间

创建一个es集群

首先编写一个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文件

1	vi /etc/sysctl.conf

添加下面的内容：

1	vm.max_map_count=262144

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

sysctl -p

通过docker-compose启动集群：

1	docker-compose up -d

集群状态监控

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

这里推荐使用cerebro来监控es集群状态，官方网址：https://github.com/lmenezes/cerebro

下载好的目录如下：

进入对应的bin目录：

双击其中的cerebro.bat文件即可启动服务。

访问http://localhost:9000 即可进入管理界面：

输入你的elasticsearch的任意节点的地址和端口，点击connect即可：

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

创建索引库

1. 利用kibana的DevTools创建索引库

在DevTools中输入指令：

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

2. 利用cerebro创建索引库

利用cerebro还可以创建索引库：

填写索引库信息：

点击右下角的create按钮：

查看分片效果

回到首页，即可查看索引库分片效果：

索引库操作

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

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

mapping映射属性

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

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

{
    "age": 21,
    "weight": 52.1,
    "isMarried": false,
    "info": "重庆邮电大学学长",
    "email": "zl@raehp.cn",
    "score": [99.1, 99.5, 98.9],
    "name": {
        "firstName": "云",
        "lastName": "赵"
    }
}

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

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

索引库的CRUD

这里我们统一使用Kibana编写DSL的方式来演示。

创建索引库和映射

基本语法：

请求方式：PUT
请求路径：/索引库名，可以自定义
请求参数：mapping映射

格式：

PUT /索引库名称
{
  "mappings": {
    "properties": {
      "字段名":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "字段名2":{
        "type": "keyword",
        "index": "false"
      },
      "字段名3":{
        "properties": {
          "子字段": {
            "type": "keyword"
          }
        }
      },
      // ...略
    }
  }
}

示例：

PUT /raehp
{
  "mappings": {
    "properties": {
      "info":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "email":{
        "type": "keyword",
        "index": "falsae"
      },
      "name":{
        "properties": {
          "firstName": {
            "type": "keyword"
          }
        }
      },
      // ... 略
    }
  }
}

查询索引库

基本语法：

请求方式：GET
请求路径：/索引库名
请求参数：无

格式：

GET /索引库名

示例：

修改索引库

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

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

语法说明：

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

示例

删除索引库

语法：

请求方式：DELETE
请求路径：/索引库名
请求参数：无

格式：

1	DELETE /索引库名

在kibana中测试：

总结

索引库操作有哪些？

创建索引库：PUT /索引库名
查询索引库：GET /索引库名
删除索引库：DELETE /索引库名
添加字段：PUT /索引库名/_mapping

文档操作

新增文档

语法：

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

示例：

POST /raehp/_doc/1
{
    "info": "黑马程序员Java讲师",
    "email": "zy@itcast.cn",
    "name": {
        "firstName": "云",
        "lastName": "赵"
    }
}

响应：

查询文档

根据rest风格，新增是post，查询应该是get，不过查询一般都需要条件，这里我们把文档id带上。

语法：

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

通过kibana查看数据：

1	GET /raehp/_doc/1

查看结果：

删除文档

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

语法：

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

示例：

1 2	# 根据id删除数据 DELETE /raehp/_doc/1

结果：

修改文档

修改有两种方式：

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

全量修改

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

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

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

语法：

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

示例：

PUT /raehp/_doc/1
{
  "info":"重庆邮电大学大三学长",
  "email":"wuyanzu406@gmail.com",
  "age":"22",
  "name": {
    "firstName":"彦祖",
    "lastName":"吴"
  }
}

增量修改

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

语法：

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

示例：

POST /raehp/_update/1
{
  "doc": {
    "age":"24"
  }
}

总结

文档操作有哪些？

创建文档：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客户端

导入Demo工程

导入数据

这里笔记参考黑马程序员SpringCloud课程

导入数据库文件：

/*
 Navicat Premium Data Transfer

 Source Server         : local
 Source Server Type    : MySQL
 Source Server Version : 50622
 Source Host           : localhost:3306
 Source Schema         : heima

 Target Server Type    : MySQL
 Target Server Version : 50622
 File Encoding         : 65001

 Date: 06/05/2021 18:31:05
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for tb_hotel
-- ----------------------------
DROP TABLE IF EXISTS `tb_hotel`;
CREATE TABLE `tb_hotel`  (
  `id` bigint(20) NOT NULL COMMENT '酒店id',
  `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '酒店名称',
  `address` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '酒店地址',
  `price` int(10) NOT NULL COMMENT '酒店价格',
  `score` int(2) NOT NULL COMMENT '酒店评分',
  `brand` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '酒店品牌',
  `city` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '所在城市',
  `star_name` varchar(16) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '酒店星级，1星到5星，1钻到5钻',
  `business` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '商圈',
  `latitude` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '纬度',
  `longitude` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '经度',
  `pic` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '酒店图片',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Compact;

-- ----------------------------
-- Records of tb_hotel
-- ----------------------------
INSERT INTO `tb_hotel` VALUES (36934, '7天连锁酒店(上海宝山路地铁站店)', '静安交通路40号', 336, 37, '7天酒店', '上海', '二钻', '四川北路商业区', '31.251433', '121.47522', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3E/40/Cii9EVkyLrKIXo1vAAHgrxo_pUcAALcKQLD688AAeDH564_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (38609, '速8酒店(上海赤峰路店)', '广灵二路126号', 249, 35, '速8', '上海', '二钻', '四川北路商业区', '31.282444', '121.479385', 'https://m.tuniucdn.com/fb2/t1/G2/M00/DF/96/Cii-TFkx0ImIQZeiAAITil0LM7cAALCYwKXHQ4AAhOi377_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (38665, '速8酒店上海中山北路兰田路店', '兰田路38号', 226, 35, '速8', '上海', '二钻', '长风公园地区', '31.244288', '121.422419', 'https://m.tuniucdn.com/fb2/t1/G2/M00/EF/86/Cii-Tlk2mV2IMZ-_AAEucgG3dx4AALaawEjiycAAS6K083_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (38812, '7天连锁酒店(上海漕溪路地铁站店)', '徐汇龙华西路315弄58号', 298, 37, '7天酒店', '上海', '二钻', '八万人体育场地区', '31.174377', '121.442875', 'https://m.tuniucdn.com/fb2/t1/G2/M00/E0/0E/Cii-TlkyIr2IEWNoAAHQYv7i5CkAALD-QP2iJwAAdB6245_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (39106, '7天连锁酒店（上海莘庄地铁站店）', '闵行莘庄镇七莘路299号', 348, 41, '7天酒店', '上海', '二钻', '莘庄工业区', '31.113812', '121.375869', 'https://m.tuniucdn.com/fb2/t1/G2/M00/D8/11/Cii-T1ku2zGIGR7uAAF1NYY9clwAAKxZAHO8HgAAXVN368_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (39141, '7天连锁酒店(上海五角场复旦同济大学店)', '杨浦国权路315号', 349, 38, '7天酒店', '上海', '二钻', '江湾、五角场商业区', '31.290057', '121.508804', 'https://m.tuniucdn.com/fb2/t1/G2/M00/C7/E3/Cii-T1knFXCIJzNYAAFB8-uFNAEAAKYkQPcw1IAAUIL012_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (45845, '上海西藏大厦万怡酒店', '虹桥路100号', 589, 45, '万怡', '上海', '四钻', '徐家汇地区', '31.192714', '121.434717', 'https://m.tuniucdn.com/fb3/s1/2n9c/48GNb9GZpJDCejVAcQHYWwYyU8T_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (45870, '上海临港豪生大酒店', '新元南路555号', 896, 45, '豪生', '上海', '四星级', '滴水湖临港地区', '30.871729', '121.81959', 'https://m.tuniucdn.com/fb3/s1/2n9c/2F5HoQvBgypoDUE46752ppnQaTqs_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (46829, '上海浦西万怡酒店', '恒丰路338号', 726, 46, '万怡', '上海', '四钻', '上海火车站地区', '31.242977', '121.455864', 'https://m.tuniucdn.com/fb3/s1/2n9c/x87VCoyaR8cTuYFZmKHe8VC6Wk1_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (47066, '上海浦东东站华美达酒店', '施新路958号', 408, 46, '华美达', '上海', '四钻', '浦东机场核心区', '31.147989', '121.759199', 'https://m.tuniucdn.com/fb3/s1/2n9c/2pNujAVaQbXACzkHp8bQMm6zqwhp_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (47478, '速8酒店(上海松江中心店)', '松江荣乐东路677号', 428, 35, '速8', '上海', '二钻', '佘山、松江大学城', '31.016712', '121.261606', 'https://m.tuniucdn.com/filebroker/cdn/res/07/36/073662e1718fccefb7130a9da44ddf5c_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56201, '上海齐鲁万怡大酒店', '东方路838号', 873, 44, '万怡', '上海', '四星级', '浦东陆家嘴金融贸易区', '31.226031', '121.525801', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/B6/Cii-TF3eXKeIJeN7AASiKHbTtx4AAGRegDSBzMABKJA111_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56214, '上海浦东华美达大酒店', '新金桥路18号', 830, 45, '华美达', '上海', '四星级', '浦东金桥地区', '31.244916', '121.590752', 'https://m.tuniucdn.com/fb3/s1/2n9c/3jtXiuMKZEXJAuKuAkc47yLCjUBt_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56227, '上海圣淘沙万怡酒店', '南桥镇南桥路1号', 899, 45, '万怡', '上海', '四星级', '奉贤开发区', '30.910917', '121.456525', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/B9/Cii-U13eXSiIdJjXAARSA6FywFYAAGRnwHvy1AABFIb158_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56392, '上海银星皇冠假日酒店', '番禺路400号', 809, 47, '皇冠假日', '上海', '五星级', '徐家汇地区', '31.202768', '121.429524', 'https://m.tuniucdn.com/fb3/s1/2n9c/37ucQ38K3UFdcRqntJ8M5dt884HR_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56852, '上海财大豪生大酒店', '武东路188号', 592, 46, '豪生', '上海', '五钻', '江湾/五角场商业区', '31.304182', '121.492936', 'https://m.tuniucdn.com/fb3/s1/2n9c/2jGHezLZvPZqC9cBGesbP5vAhCXi_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56912, '上海华凯华美达广场酒店', '月华路9号', 747, 40, '华美达', '上海', '四钻', '奉贤开发区', '30.814382', '121.464521', 'https://m.tuniucdn.com/fb3/s1/2n9c/45iaCNCuZavJTxwTLskhVKzwynLD_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (56977, '上海五角场华美达大酒店', '黄兴路1888号', 499, 40, '华美达', '上海', '三钻', '江湾/五角场商业区', '31.292932', '121.519759', 'https://m.tuniucdn.com/fb3/s1/2n9c/26VREqAQdaGFvJdAJALVtjxcNMpL_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60214, '上海金茂君悦大酒店', '世纪大道88号（54楼办理入住）', 699, 46, '君悦', '上海', '五星级', '浦东陆家嘴金融贸易区', '31.235152', '121.506082', 'https://m.tuniucdn.com/fb3/s1/2n9c/7Azm3jvGUHuXe3eS1DrixAWVTXY_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60223, '上海希尔顿酒店', '静安华山路250号', 2688, 37, '希尔顿', '上海', '五星级', '静安寺地区', '31.219306', '121.445427', 'https://m.tuniucdn.com/filebroker/cdn/res/92/10/9210e74442aceceaf6e196d61fc3b6b1_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60359, '上海外高桥皇冠假日酒店', '杨高北路1000号', 3299, 46, '皇冠假日', '上海', '五星级', '浦东外高桥地区', '31.338944', '121.590611', 'https://m.tuniucdn.com/fb3/s1/2n9c/VcKUM9zUSiVgDhFioc6mWQoX9ES_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60363, '上海新世界丽笙大酒店', '南京西路88号', 1341, 46, '丽笙', '上海', '五星级', '人民广场地区', '31.23462', '121.47327', 'https://m.tuniucdn.com/fb3/s1/2n9c/2j31b7X3YzGkf4Li3phS6TG1mtwm_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60398, '上海复旦皇冠假日酒店', '邯郸路199号', 924, 47, '皇冠假日', '上海', '五星级', '江湾/五角场商业区', '31.295382', '121.502537', 'https://m.tuniucdn.com/fb3/s1/2n9c/2H1Gk8LHaBWZfYvR6NYYcGTvACmL_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60487, '上海外滩茂悦大酒店', '黄浦路199号', 689, 44, '君悦', '上海', '五星级', '外滩地区', '31.245409', '121.492969', 'https://m.tuniucdn.com/fb3/s1/2n9c/2Swp2h1fdj9zCUKsk63BQvVgKLTo_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60522, '上海嘉豪淮海国际豪生酒店', '汾阳路1号', 425, 45, '豪生', '上海', '四钻', '淮海路/新天地地区', '31.215497', '121.456297', 'https://m.tuniucdn.com/fb3/s1/2n9c/38UBi4QYuaF8jN94CxQ7tb7tjtmZ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60916, '上海绿地万怡酒店', '沪宜公路3101号', 328, 45, '万怡', '上海', '四钻', '嘉定新城', '31.368523', '121.258567', 'https://m.tuniucdn.com/fb3/s1/2n9c/3VLwG9tTQQnp3M3MTeMTdx9nas9B_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60922, '上海虹桥祥源希尔顿酒店', '红松东路1116号', 1108, 45, '希尔顿', '上海', '五钻', '虹桥地区', '31.18746', '121.395312', 'https://m.tuniucdn.com/fb3/s1/2n9c/tQRqDTFkHnHzMZiDKjcGV81ekvc_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (60935, '上海虹口三至喜来登酒店', '四平路59号', 1899, 46, '喜来登', '上海', '五星级', '四川北路商业区', '31.2579', '121.487954', 'https://m.tuniucdn.com/fb3/s1/2n9c/3C3gxLxLjVwnkxJwJm8rd3f38kcd_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (61075, '上海雅居乐万豪酒店', '西藏中路555号', 1152, 46, '万豪', '上海', '五钻', '人民广场地区', '31.236681', '121.473529', 'https://m.tuniucdn.com/fb3/s1/2n9c/3FoT16PkXavKsssvktVvVq5Si6Cr_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (61083, '上海滴水湖皇冠假日酒店', '自由贸易试验区临港新片区南岛1号', 971, 44, '皇冠假日', '上海', '五钻', '滴水湖临港地区', '30.890867', '121.937241', 'https://m.tuniucdn.com/fb3/s1/2n9c/312e971Rnj9qFyR3pPv4bTtpj1hX_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (309208, '北京王府井希尔顿酒店', '王府井东街8号', 1679, 46, '希尔顿', '北京', '五钻', '天安门/王府井地区', '39.914539', '116.413392', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/10/Cii-TF3ePt2IX9UEAALb6VYBSmoAAGKMgGsuW8AAtwB147_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (394559, '北京东方君悦大酒店', '长安街1号东方广场', 686, 45, '君悦', '北京', '五星级', '天安门/王府井地区', '39.909635', '116.414621', 'https://m.tuniucdn.com/fb3/s1/2n9c/3mFqcNSh7eEo9yc3Rw2P5HDNTdDe_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (394617, '北京宝辰饭店', '建国门内大街甲18号', 418, 44, '豪生', '北京', '四星级', '北京站/建国门地区', '39.905768', '116.428153', 'https://m.tuniucdn.com/fb3/s1/2n9c/NEYa6EfDHuhhb19Ct85WBbkKHZU_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (394796, '北京新云南皇冠假日酒店', '东北三环西坝河太阳宫桥东北角云南大厦', 485, 46, '皇冠假日', '北京', '五星级', '国展中心地区', '39.972409', '116.434698', 'https://m.tuniucdn.com/fb3/s1/2n9c/dfP8K782eTsohQWSRdkd7St9LA2_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (395434, '北京希尔顿酒店', '东三环北路东方路1号', 350, 45, '希尔顿', '北京', '五星级', '燕莎/朝阳公园商业区', '39.952703', '116.462387', 'https://m.tuniucdn.com/fb3/s1/2n9c/3fwNbKGhk6XCrkdVyxwhC5uGpLVy_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (395702, '北京首都机场希尔顿酒店', '首都机场3号航站楼三经路1号', 222, 46, '希尔顿', '北京', '五钻', '首都机场/新国展地区', '40.048969', '116.619566', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/10/Cii-U13ePtuIMRSjAAFZ58NGQrMAAGKMgADZ1QAAVn_167_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (395787, '北京海航大厦万豪酒店', '霄云路甲26号', 1302, 46, '万豪', '北京', '五钻', '燕莎/朝阳公园商业区', '39.959861', '116.467363', 'https://m.tuniucdn.com/fb3/s1/2n9c/3zFiWi2C9SmbcQwCZgJFQC9ahvs5_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (395799, '北京国际艺苑皇冠假日酒店', '王府井大街48号', 636, 44, '皇冠假日', '北京', '五星级', '天安门/王府井地区', '39.918994', '116.411277', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/10/Cii-U13ePvyIahjPAAMykV278aEAAGKOQO9e4UAAzKp283_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (395815, '北京明豪华美达酒店', '天竺镇府前一街13号', 558, 46, '华美达', '北京', '四钻', '首都机场/新国展地区', '40.062832', '116.580678', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/13/Cii-U13eP2mIKCwvAAODTZXT-fAAAGKVAA9taIAA4Nl245_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (396189, '北京朝阳悠唐皇冠假日酒店', '三丰北里3号', 944, 46, '皇冠假日', '北京', '五钻', '三里屯/工体/东直门地区', '39.92129', '116.43847', 'https://m.tuniucdn.com/fb3/s1/2n9c/tT6ipLain1ZovR5gnQ7tJ4KKym5_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (396471, '维也纳酒店（北京花园路店）', '海淀北太平庄花园路甲17号', 381, 36, '维也纳', '北京', '三钻', '马甸、安贞地区', '39.970837', '116.365244', 'https://m.tuniucdn.com/filebroker/cdn/res/17/00/1700926908bae6ba3e5ef96de7b7d4cc_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (396506, '北京金隅喜来登酒店', '北三环东路36号', 357, 47, '喜来登', '北京', '五星级', '马甸/安贞地区', '39.967163', '116.4099', 'https://m.tuniucdn.com/fb3/s1/2n9c/29FW2WtGzzUtPhWR1LKxcFZAVa9P_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (413460, '7天连锁酒店(北京天坛店)', '东城天坛东里甲48号', 753, 38, '7天酒店', '北京', '二钻', '前门、崇文门商贸区', '39.875786', '116.421987', 'https://m.tuniucdn.com/fb2/t1/G2/M00/C7/D8/Cii-T1knCK6IWTtxAAI0plLButMAAKYTAJu-woAAjS-422_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (413476, '7天连锁酒店(北京南站店)', '丰台马家堡西路22号', 478, 37, '7天酒店', '北京', '二钻', '永定门、南站、大红门、南苑地区', '39.845363', '116.372327', 'https://m.tuniucdn.com/fb2/t1/G1/M00/26/B7/Cii-U1knCtaISM4VAAHkEQd-mrAAAKw0ALVCwEAAeQp741_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (414168, '7天连锁酒店(北京西直门店)', '西城平安里西大街翠花街育幼胡同甲20-22号', 419, 37, '7天酒店', '北京', '二钻', '西单、金融街地区', '39.931338', '116.364982', 'https://m2.tuniucdn.com/filebroker/cdn/res/bc/66/bc666859edf4fc072a8006c66758058d_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (414481, '7天连锁酒店(北京团结湖地铁站店)', '朝阳团结湖北里9号楼', 525, 36, '7天酒店', '北京', '二钻', '燕莎、三里屯商业区', '39.928457', '116.466132', 'https://m.tuniucdn.com/fb2/t1/G1/M00/38/2D/Cii9EFkv2-uIPTaBAALX6P-rbdUAALPpwHv4ykAAtgA277_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (414698, '7天连锁酒店（北京798艺术区店）', '朝阳北京市朝阳区酒仙桥北路（798艺术区北门）彩虹路6号-电通创意广场大院内', 553, 37, '7天酒店', '北京', '二钻', '望京、酒仙桥、798地区', '39.990671', '116.498452', 'https://m.tuniucdn.com/fb2/t1/G2/M00/D8/11/Cii-T1ku2zqIN7SiAAEdvT6RrjUAAKxZQKFooYAAR3V090_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (415600, '如家酒店(北京朝阳北路传媒大学褡裢坡地铁站店)', '三间房乡褡裢坡村青年沟西侧558号', 259, 47, '如家', '北京', '二钻', '传媒大学/管庄地区', '39.923212', '116.560023', 'https://m.tuniucdn.com/fb3/s1/2n9c/3NezpxNZWQMdNXibwbMkQuAZjDyJ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (415659, '7天连锁酒店（北京紫竹桥店）', '海淀北洼路甲3号', 781, 42, '7天酒店', '北京', '二钻', '西直门及北京展览馆地区', '39.936138', '116.302405', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3C/22/Cii9EVkxPMqIZJz-AAIh0esETAIAALXbgNQkH8AAiHp053_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (416121, '如家酒店(北京西客站北广场店)', '莲花池东路120-2号6层', 275, 43, '如家', '北京', '二钻', '北京西站/丽泽商务区', '39.896449', '116.317382', 'https://m.tuniucdn.com/fb3/s1/2n9c/42DTRnKbiYoiGFVzrV9ZJUxNbvRo_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (416260, '7天连锁酒店(北京通州八里桥店)', '永顺镇西马庄小区', 534, 38, '7天酒店', '北京', '二钻', '果园环岛、通州区', '39.915443', '116.631871', 'https://m.tuniucdn.com/fb2/t1/G2/M00/DF/5A/Cii-TlkxkeGIKM0oAAGOb64RvToAALBAAH9Fg8AAY6H201_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (416268, '和颐酒店(北京传媒大学财满街店)', '朝阳路高井176号', 524, 46, '和颐', '北京', '三钻', '国贸地区', '39.918277', '116.53015', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/13/Cii-TF3eP5GIJIOLAAUwsIVCxdAAAGKXgK5a0IABTDI239_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (416307, '速8酒店(北京新国展首都机场后沙峪店)', '后沙峪镇裕民大街32号', 350, 39, '速8', '北京', '二钻', '首都机场/新国展地区', '40.099019', '116.543655', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/3E/Cii-TF3eRgGIHCkKAAP_ATvriiQAAGL0AIoLtUAA_8Z513_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (432335, '7天连锁酒店(上海北外滩国际客运中心地铁站店)', '唐山路145号', 249, 35, '7天酒店', '上海', '二钻', '北外滩地区', '31.252585', '121.498753', 'https://m2.tuniucdn.com/filebroker/cdn/res/c1/ba/c1baf64418437c56617f89840c6411ef_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (433576, '如家酒店(上海南京路步行街店)', '南京东路480号保安坊内', 379, 44, '如家', '上海', '二钻', '人民广场地区', '31.236454', '121.480948', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/BA/Cii-U13eXVaIQmdaAAWxgzdXXxEAAGRrgNIOkoABbGb143_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (434082, '如家酒店·neo(上海外滩城隍庙小南门地铁站店)', '复兴东路260号', 392, 44, '如家', '上海', '二钻', '豫园地区', '31.220706', '121.498769', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/B6/Cii-U13eXLGIdHFzAAIG-5cEwDEAAGRfQNNIV0AAgcT627_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (441836, '如家酒店(北京国展三元桥店)', '西坝河东里36号', 458, 47, '如家', '北京', '二钻', '国展中心地区', '39.966238', '116.450142', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/39/Cii-TF3eRTGITp1UAAYIilRD7skAAGLngIuAnQABgii479_w200_h200_c1_t0.png');
INSERT INTO `tb_hotel` VALUES (485775, '如家酒店(上海闵行华东师范大学吴泾店)', '吴泾镇宝秀路977号', 161, 45, '如家', '上海', '二钻', '交大/闵行经济开发区', '31.047135', '121.46224', 'https://m.tuniucdn.com/fb3/s1/2n9c/V8pz15CkiMX5xYJRmbbp5zkKWJ8_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (489756, '7天连锁酒店(北京平谷店)', '文化北街4-16号', 544, 40, '7天酒店', '北京', '二钻', '平谷城区', '40.14308', '117.111554', 'https://m2.tuniucdn.com/filebroker/cdn/res/2e/b4/2eb4edb22ddb981307d8570beb1d746d_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (517915, '如家酒店·neo(深圳草埔地铁站店)', '布吉路1036号', 159, 44, '如家', '深圳', '二钻', '田贝/水贝珠宝城', '22.583191', '114.118499', 'https://m.tuniucdn.com/fb3/s1/2n9c/228vhBCQmFRFWQBYX1cgoFQb6x58_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (527938, '深圳好日子皇冠假日酒店', '福华一路28号', 590, 46, '皇冠假日', '深圳', '五星级', '会展中心/CBD', '22.537153', '114.053529', 'https://m.tuniucdn.com/fb3/s1/2n9c/b6Ztz5jn4MngK3Hzfxuu9JGsjrm_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (541619, '如家酒店(上海莘庄地铁站龙之梦商业广场店)', '莘庄镇莘浜路172号', 149, 44, '如家', '上海', '二钻', '莘庄工业区', '31.105797', '121.37755', 'https://m.tuniucdn.com/fb3/s1/2n9c/3mKs3jETvJDj3dDdkRB9UyLLvPna_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (542068, '上海茂业华美达广场酒店', '沪南路938号', 646, 40, '华美达', '上海', '三钻', '浦东新国际博览中心', '31.182761', '121.554106', 'https://m.tuniucdn.com/fb3/s1/2n9c/2139uDFUZ2VKxrathwSeeE4DwyFU_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (546869, '深圳彭年万丽酒店', '嘉宾路2002号（毗邻金光华购物广场）', 701, 46, '万丽', '深圳', '五钻', '罗湖口岸/火车站', '22.540989', '114.122665', 'https://m.tuniucdn.com/fb3/s1/2n9c/gwAbqEXFUpjUBmnxUfK89p3zBBT_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (581859, '维也纳酒店（北京丰益桥店）（原申晨酒店）', '丰台丰管路8号', 648, 45, '维也纳', '北京', '三钻', '北京西站、丽泽商务区', '39.857707', '116.312482', 'https://m2.tuniucdn.com/filebroker/cdn/res/97/43/97438481b9e79abad429e5c30d7f303f_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (584697, '7天连锁酒店（深圳华强赛格广场店）', '华强南路3024号赛格苑1栋', 362, 36, '7天酒店', '深圳', '二钻', '华强北商业区', '22.539831', '114.087899', 'https://m.tuniucdn.com/fb2/t1/G2/M00/D8/11/Cii-T1ku2zmIcP4sAAEw8iuLXFgAAKxZQH7HVYAATEK972_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (593228, '7天连锁酒店（北京颐和园店）', '海淀厢红旗路功德寺桥北侧', 730, 38, '7天酒店', '北京', '二钻', '香山、八大处风景区', '40.003959', '116.256718', 'https://m2.tuniucdn.com/filebroker/cdn/res/55/84/55841f502c5a711e66dd5454b64f559b_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (598591, '上海丽昂豪生大酒店', '金新路99号', 529, 47, '豪生', '上海', '四钻', '浦东金桥地区', '31.252496', '121.600085', 'https://m.tuniucdn.com/fb3/s1/2n9c/2KfPPyPx9rWyVXif2CUuxv61Nryc_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (607915, '汉庭酒店(深圳皇岗店)', '滨河大道6033号海滨广场国皇大厦3楼', 313, 42, '汉庭', '深圳', '二钻', '皇岗口岸/福田口岸', '22.528101', '114.064221', 'https://m.tuniucdn.com/fb3/s1/2n9c/qMyCJVYuW21nsCeEBt8CMfmEhra_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (608374, '如家酒店(上海浦东机场龙东大道合庆店)', '东川公路5863号', 160, 45, '如家', '上海', '二钻', '浦东机场核心区', '31.237662', '121.718556', 'https://m.tuniucdn.com/fb3/s1/2n9c/LUYxGGV4pzjKeN5a69K4deU8JD8_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (609023, '如家酒店·neo(上海外高桥保税区北地铁站店)', '花山路1209号', 266, 45, '如家', '上海', '二钻', '浦东外高桥地区', '31.351148', '121.585606', 'https://m.tuniucdn.com/fb3/s1/2n9c/3cJ6KTfms9cfEnME8WRkQQBXBkYm_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (609372, '豪派特华美达广场酒店(深圳北站店)', '民治街道梅龙路与民旺路交汇处', 498, 45, '华美达', '深圳', '四钻', '深圳北站地区', '22.620501', '114.033874', 'https://m.tuniucdn.com/fb3/s1/2n9c/3G5TnUCPbjGYHAVWfvuixw8bs69t_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (624417, '深圳君悦酒店', '宝安南路1881号', 442, 47, '君悦', '深圳', '五钻', '万象城/京基100', '22.537247', '114.111182', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EA/Cii-TF3ZpVmIVDJ9AAXvJftz_AgAAFrrQKbI4oABe89086_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (628327, '如家酒店·neo(深圳罗湖口岸国贸地铁站店)', '人民南路2011号', 223, 45, '如家', '深圳', '二钻', '罗湖口岸/火车站', '22.536734', '114.118336', 'https://m.tuniucdn.com/fb3/s1/2n9c/2rKHmQWHYiY8GZA3xBHpFKCLZwZo_w200_h200_c1_t0.png');
INSERT INTO `tb_hotel` VALUES (629023, '和颐酒店(北京十里河欢乐谷店)', '十八里店乡周家庄288号', 390, 47, '和颐', '北京', '四钻', '劲松/潘家园地区', '39.853354', '116.483437', 'https://m.tuniucdn.com/fb3/s1/2n9c/28hnDdqn5uzuzCKYkw2x4pYmunXM_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (629729, '7天连锁酒店(上海张江高科园区店)', '浦东新区蔡伦路103号', 267, 36, '7天酒店', '上海', '二钻', '浦东张江地区', '31.196154', '121.62071', 'https://m2.tuniucdn.com/filebroker/cdn/res/d9/61/d961508a10865b9b29c033064f31b913_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (635963, '深圳龙岗珠江皇冠假日酒店', '龙岗中心城龙翔大道9009号珠江广场', 737, 46, '皇冠假日', '深圳', '五星级', '龙岗中心区/大运新城', '22.722941', '114.250002', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EA/Cii-U13ZpWGIasKjAAY1SNE36KMAAFrrwMNoAwABjVg973_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (636080, '深圳大中华喜来登酒店', '福华路一号大中华国际交易广场', 1556, 47, '喜来登', '深圳', '五星级', '会展中心/CBD', '22.535567', '114.062005', 'https://m.tuniucdn.com/fb3/s1/2n9c/3hQRTmAUW9PegTjxMiEfYwh2HnKp_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (644417, '上海外高桥喜来登酒店', '自由贸易试验区基隆路28号（二号门内）', 2419, 46, '喜来登', '上海', '五钻', '浦东外高桥地区', '31.350989', '121.588751', 'https://m.tuniucdn.com/fb3/s1/2n9c/1Rrtg9n7PdMEivVDhsehbJBrEre_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (648219, '上海金桥红枫万豪酒店', '新金桥路15号', 891, 47, '万豪', '上海', '五钻', '浦东金桥地区', '31.244061', '121.591153', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/B6/Cii-TF3eXKuIR_a0AAUx-Xd2JLQAAGRfACSpvUABTIR560_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (657192, '深圳宝安中天美景华美达酒店', '新桥街道万丰社区中心路7-1号', 498, 45, '华美达', '深圳', '四钻', '深圳国际会展中心商圈', '22.716473', '113.826391', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EA/Cii-U13ZpVeIRbhTAAOzGZSDtlcAAFrrQEWM-AAA7Mx626_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (659496, '维也纳酒店(深圳国王店)', '龙华新区龙华龙观西路95号', 714, 37, '维也纳', '深圳', '三钻', '深圳北站地区', '22.65892', '114.006817', 'https://m2.tuniucdn.com/filebroker/cdn/res/b4/76/b476cacc575a7ff237128ba2fd63923a_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (670673, '北京龙城华美达酒店', '昌平路319号', 506, 45, '华美达', '北京', '四钻', '回龙观/天通苑地区', '40.084219', '116.304313', 'https://m.tuniucdn.com/fb3/s1/2n9c/T3WruZV3S4MfcxdD1HFVhZjaBLW_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (672207, '和颐至尊酒店(北京望京798店)', '酒仙桥北路9号荧屏里4号楼', 579, 44, '和颐', '北京', '四钻', '望京/酒仙桥/798地区', '39.98835', '116.491217', 'https://m.tuniucdn.com/fb3/s1/2n9c/2y56zwK8kd2tBuRUyF7XeJ2ucvWM_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (684720, '和颐酒店(深圳罗湖口岸火车地铁站店)', '沿河南路1064号', 208, 47, '和颐', '深圳', '四钻', '罗湖口岸/火车站', '22.533753', '114.122491', 'https://m.tuniucdn.com/fb3/s1/2n9c/2LFgB2iFawKKoGADwzhW6jpCSaJT_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (696948, '上海新园华美达广场酒店', '漕宝路509号', 1290, 45, '华美达', '上海', '四星级', '光大会展中心/漕河泾地区', '31.163802', '121.405618', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/B6/Cii-TF3eXHuIE57sAAZx8iP6rMIAAGRbgAH09gABnIK621_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (706343, '速8酒店（北京西客站北广场店）', '丰台莲花池东路126号', 268, 39, '速8', '北京', '二钻', '北京西站、丽泽商务区', '39.896623', '116.315586', 'https://m.tuniucdn.com/fb2/t1/G2/M00/E3/46/Cii-TlkzMXWIL0sAAAGG8a3YwiwAALJlgG-r5YAAYcJ067_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (707357, '维也纳酒店（上海南站光大店）', '徐汇桂林路46号（钦州南路路口往南100米）', 3288, 36, '维也纳', '上海', '三钻', '光大会展中心', '31.156297', '121.419948', 'https://m2.tuniucdn.com/filebroker/cdn/res/f7/13/f713f8f98d777d8d53aafefb37a79ef6_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (711837, '速8酒店（北京立水桥店）', '朝阳安立路3号1幢3层', 268, 36, '速8', '北京', '二钻', '亚运村、奥体中心地区', '40.043717', '116.410962', 'https://m2.tuniucdn.com/filebroker/cdn/res/b3/87/b3876eaf16af62521cf6fb474504b8ca_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (727679, '7天连锁酒店(深圳步行街老街地铁站二店)', '罗湖区东门中路2216号华佳广场12-14楼（东门天桥东头）', 742, 40, '7天酒店', '深圳', '二钻', '东门商业区', '22.54585', '114.122227', 'https://m.tuniucdn.com/fb2/t1/G1/M00/39/99/Cii9EFkwVMKIP_mCAAI3fOHlS1wAALSDAMeO2MAAjeU309_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (728180, '如家酒店(深圳宝安西乡地铁站店)', '西乡大道298-7号（富通城二期公交站旁）', 184, 43, '如家', '深圳', '二钻', '宝安体育中心商圈', '22.569693', '113.860186', 'https://m.tuniucdn.com/fb3/s1/2n9c/FHdugqgUgYLPMoC4u4rdTbAPrVF_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (728415, '如家酒店·neo(深圳东门步行街晒布地铁站店)', '晒布路67号', 152, 46, '如家', '深圳', '二钻', '东门商业区', '22.550183', '114.120771', 'https://m.tuniucdn.com/fb2/t1/G6/M00/25/57/Cii-U13PFNWISSnQAAEpTtoilsQAAEVWgEvur8AASlm647_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (728461, '汉庭酒店(深圳会展中心店)', '新洲路世纪工艺品广场307栋', 258, 44, '汉庭', '深圳', '二钻', '皇岗口岸/福田口岸', '22.518026', '114.046061', 'https://m.tuniucdn.com/fb2/t1/G6/M00/25/56/Cii-TF3PFKOIPl0JAANm4ge6DdMAAEVTQK2SP8AA2b6365_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (728604, '如家酒店·neo(深圳南山地铁站南山市场店)', '南新路顺富街18号化州大厦', 198, 43, '如家', '深圳', '二钻', '科技园', '22.525561', '113.920058', 'https://m.tuniucdn.com/fb2/t1/G6/M00/25/57/Cii-TF3PFLmIDGWiAAPHkaNTuOIAAEVVQBGazAAA8ep611_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (730454, '7天连锁酒店(深圳万象城店)', '罗湖区嘉宾路4025号城市天地广场内', 552, 43, '7天酒店', '深圳', '二钻', '罗湖口岸/火车站', '22.537078', '114.113733', 'https://m.tuniucdn.com/fb2/t1/G2/M00/C8/4C/Cii-Tlknhz2IFnYNAAInF2jEK14AAKbcQNB5M8AAicv660_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (730569, '7天连锁酒店(深圳梅林卓越城店)', '孖岭地铁口C出口左手边，青年学院对面', 269, 39, '7天酒店', '深圳', '二钻', '莲花山/梅林', '22.568701', '114.068464', 'https://m.tuniucdn.com/fb2/t1/G2/M00/D8/0B/Cii-Tlku2dOISeGXAAAUw3MvPrIAAKxYALB2VAAABTb555_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (730968, '7天连锁酒店(深圳宝安地铁站店)', '宝安区宝安25区创业二路步行街金麒麟服装广场4栋', 314, 36, '7天酒店', '深圳', '二钻', '宝安中心区/前海', '22.568162', '113.900968', 'https://m.tuniucdn.com/fb2/t1/G2/M00/D8/0B/Cii-T1ku2cqIWTOOAAAS_bvRI5UAAKxXwILCFYAABMV285_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (751035, '7天连锁酒店(上海自贸区北门地铁站店)(原外高桥地铁北站店)', '花山路706号', 328, 39, '7天酒店', '上海', '二钻', '浦东外高桥地区', '31.348029', '121.576896', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3A/21/Cii-U1kwxUCINXaHAAGmh7z6qRAAALUdwMKGREAAaaf928_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (844350, '7天连锁酒店(深圳世界之窗店)', '南山区白石洲沙河街2号金三角大厦', 769, 36, '7天酒店', '深圳', '二钻', '华侨城', '22.540501', '113.968858', 'https://m.tuniucdn.com/fb2/t1/G2/M00/D8/11/Cii-TFku2zmIOdjCAAAQJpLFhEEAAKxZQIEvQ0AABA-920_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2316304, '如家酒店(深圳双龙地铁站店)', '龙岗街道龙岗墟社区龙平东路62号', 135, 45, '如家', '深圳', '二钻', '龙岗中心区/大运新城', '22.730828', '114.278337', 'https://m.tuniucdn.com/fb3/s1/2n9c/4AzEoQ44awd1D2g95a6XDtJf3dkw_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2329005, '维也纳酒店(深圳华之沙店)', '福强路新洲九街28号', 651, 39, '维也纳', '深圳', '三钻', '皇岗口岸/福田口岸', '22.524835', '114.048214', 'https://m2.tuniucdn.com/filebroker/cdn/res/88/f0/88f05cd11990ef39ae187886c76f40a5_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2351601, '深圳蛇口希尔顿南海酒店', '望海路1177号', 509, 47, '希尔顿', '深圳', '五钻', '深圳湾口岸/蛇口', '22.479373', '113.916013', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EA/Cii-TF3ZpXOIfa6fAAJjiUOiuYgAAFrtgDtgpQAAmOh799_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2359697, '如家酒店(北京上地安宁庄东路店)', '清河小营安宁庄东路18号20号楼', 420, 46, '如家', '北京', '二钻', '上地产业园/西三旗', '40.041322', '116.333316', 'https://m.tuniucdn.com/fb3/s1/2n9c/2wj2f8mo9WZQCmzm51cwkZ9zvyp8_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (5865979, '北京丽都皇冠假日酒店', '将台路6号', 1168, 47, '皇冠假日', '北京', '五钻', '望京/酒仙桥/798地区', '39.978133', '116.478642', 'https://m.tuniucdn.com/fb3/s1/2n9c/Yo4xL3RUsYUnDDc5QcQWj7sCrUX_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (5870456, '上海宝华万豪酒店', '广中西路333号', 922, 47, '万豪', '上海', '五钻', '大宁国际商业区', '31.279371', '121.446327', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/BA/Cii-U13eXVqIZXDFAAUC_xbrQDAAAGRrwPRyOcABQMX057_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (5871652, '上海圣诺亚皇冠假日酒店', '金沙江路1699号', 770, 46, '皇冠假日', '上海', '五钻', '长风公园地区', '31.232346', '121.377709', 'https://m.tuniucdn.com/fb3/s1/2n9c/J4sP7qRSHa9rFYnKTW75ZPB393M_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (5872067, '崇明金茂凯悦酒店', '陈家镇揽海路799弄', 1024, 46, '凯悦', '上海', '五钻', '崇明岛/长兴岛/横沙岛', '31.466563', '121.799671', 'https://m.tuniucdn.com/fb3/s1/2n9c/fsKrbnNsmSsYnNLmhh3ZvVjZ5cA_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (5873072, '速8酒店（上海火车站北广场店）', '闸北芷江西路796号', 190, 41, '速8', '上海', '二钻', '上海火车站地区', '31.255579', '121.452903', 'https://m2.tuniucdn.com/filebroker/cdn/res/96/6d/966d6596e6cb7b48c9cc1d7da79b57c8_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (7094829, '汉庭酒店(深圳华强南店)', '松岭路9号（南园小学对面）', 215, 40, '汉庭', '深圳', '二钻', '华强北商业区', '22.536842', '114.094316', 'https://m.tuniucdn.com/fb3/s1/2n9c/3WDhaZZ9yALHw8yNiU6HJyrdC3u5_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (189429168, '7天连锁酒店(北京大兴黄村清源路地铁站店)', '清源西路55号', 392, 38, '7天酒店', '北京', '二钻', '大兴农业生态观光区', '39.743751', '116.321676', 'https://m.tuniucdn.com/fb2/t1/G1/M00/4F/25/Cii9EFk3LmOIFtnDAAHm5kdIiM8AAL1FQM8kG0AAeb-418_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197487869, '如家酒店(北京第二外国语大学南门双桥地铁站店)', '三间房乡新房村1号', 321, 47, '如家', '北京', '二钻', '传媒大学/管庄地区', '39.90635', '116.565528', 'https://m.tuniucdn.com/fb3/s1/2n9c/ZkgDAs8tTMvgFHdVPpikNqENEn1_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197488318, '速8酒店（北京立水桥地铁南站店）', '朝阳北苑路18号院3号楼4层', 344, 36, '速8', '北京', '二钻', '亚运村、奥体中心地区', '40.043689', '116.414138', 'https://m.tuniucdn.com/fb2/t1/G1/M00/36/4D/Cii9EVkvP72IYYjgAAF7yZeWV-wAALMQACOARMAAXvh983_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197492277, '速8酒店（北京平谷兴谷环岛店）', '平谷平谷大街31号', 614, 39, '速8', '北京', '二钻', '平谷城区', '40.159255', '117.12401', 'https://m.tuniucdn.com/fb2/t1/G1/M00/38/D5/Cii9EFkwFCiII79zAAHKsXy_LAoAALQuQEmEZ4AAcrJ339_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197492479, '如家酒店(北京顺义中心地铁站店)', '光明南大街14号', 306, 45, '如家', '北京', '二钻', '顺义温泉休闲区', '40.124783', '116.65751', 'https://m.tuniucdn.com/fb3/s1/2n9c/2hNBSjmMTk6JQ2o8ixr5s3ioevhB_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197496182, '和颐酒店(北京团结湖地铁站店)', '团结湖路9号楼', 341, 44, '和颐', '北京', '三钻', '燕莎/朝阳公园商业区', '39.930731', '116.466602', 'https://m.tuniucdn.com/fb3/s1/2n9c/2gK41VpMb4AwyNkwQEkfFo83uTUU_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197496980, '速8酒店(北京温都水城王府店)', '昌平北七家镇平西府村（温都水城东200米）', 585, 39, '速8', '北京', '二钻', '小汤山温泉度假区', '40.10144', '116.380641', 'https://m.tuniucdn.com/fb2/t1/G2/M00/C7/CB/Cii-T1km_5eICnpJAAHOWN1GylMAAKYJwF0Hp8AAc5w000_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197516492, '速8酒店（北京南苑东高地店）', '丰台南大红门路东营房15号', 651, 39, '速8', '北京', '二钻', '永定门、南站、大红门、南苑地区', '39.78996', '116.42081', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3B/D8/Cii-U1kxKGWIQlaxAAIdkjkSALkAALXDQMFbTsAAh2q158_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197835483, '7天连锁酒店(深圳大学桃园店)', '南山区桃园西路160号', 431, 36, '7天酒店', '深圳', '二钻', '科技园', '22.532576', '113.916362', 'https://m.tuniucdn.com/fb2/t1/G1/M00/38/40/Cii9EFkv4XKIQN85AAFUcDrkXe0AALPvwPRn08AAVSI037_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (197837109, '如家酒店·neo(深圳龙岗大道布吉地铁站店)', '布吉镇深惠路龙珠商城', 127, 43, '如家', '深圳', '二钻', '布吉/深圳东站', '22.602482', '114.123284', 'https://m.tuniucdn.com/fb2/t1/G6/M00/25/58/Cii-TF3PFZOIA7jwAAKInGFN4xgAAEVbAGeP4AAAoi0485_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (198323591, '汉庭酒店(深圳北站龙华汽车站店)', '龙华新区建辉路2号', 209, 46, '汉庭', '深圳', '二钻', '深圳北站地区', '22.671313', '114.02784', 'https://m.tuniucdn.com/fb3/s1/2n9c/2dkB2HzbaBUJ7adZZfZaeS9JCvjP_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200208940, '上海浦东喜来登由由公寓', '浦建路38号', 3168, 45, '喜来登', '上海', '五钻', '浦东新国际博览中心', '31.208553', '121.518552', 'https://m.tuniucdn.com/fb3/s1/2n9c/m3Nrm37Yx6YV4NwqRvSYnFRNSGk_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200210163, '7天连锁酒店(上海徐家汇宜山路地铁站店)', '徐汇钦州北路78号', 219, 35, '7天酒店', '上海', '二钻', '光大会展中心', '31.180615', '121.422916', 'https://m.tuniucdn.com/fb2/t1/G2/M00/DF/96/Cii-Tlkx0TOIGtOzAAEe_xcDxeIAALCZQJyxf4AAR8X941_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200214437, '上海浦东机场华美达广场酒店', '浦东机场启航路1100号', 600, 45, '华美达', '上海', '四星级', '浦东机场核心区', '31.160969', '121.799086', 'https://m.tuniucdn.com/fb3/s1/2n9c/2D2gbXDgrMx76uWfwzmoWpmSCCXx_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200214538, '上海绿地万豪酒店', '江滨路99号（打浦路底）', 720, 43, '万豪', '上海', '五星级', '打浦桥地区', '31.192103', '121.47298', 'https://m.tuniucdn.com/fb3/s1/2n9c/268jVMuWdYok5ehGFhQ2QNhBhUhs_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200214715, '上海浦东喜来登由由大酒店', '浦建路38号', 2489, 45, '喜来登', '上海', '五星级', '浦东新国际博览中心', '31.208739', '121.518305', 'https://m.tuniucdn.com/fb3/s1/2n9c/36t2KUGs4h5YgYSaLSkr5pMXLM54_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200214824, '7天连锁酒店(上海陆家嘴八佰伴店)', '崂山路689号', 249, 36, '7天酒店', '上海', '二钻', '浦东陆家嘴金融贸易区', '31.220656', '121.525127', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3D/95/Cii9EVkx0JCIRDFfAAIMnl8npiYAALaawHMG2kAAgy2536_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200215226, '上海颖奕皇冠假日酒店', '博园路6555号', 907, 45, '皇冠假日', '上海', '五钻', '嘉定新城', '31.272533', '121.19179', 'https://m.tuniucdn.com/fb3/s1/2n9c/3Uyfi2aBRETE1K5PChiLVZCwtDLF_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200215286, '上海万豪虹桥大酒店', '虹桥路2270号', 910, 46, '万豪', '上海', '五星级', '虹桥地区', '31.191529', '121.375577', 'https://m.tuniucdn.com/fb2/t1/G6/M00/52/B6/Cii-TF3eXK6IBQoRAAbgs1dyxJwAAGRfAPXbPQABuDL314_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200215365, '如家酒店(上海虹桥漕河泾古北店)', '虹梅路2971号', 189, 44, '如家', '上海', '二钻', '虹桥地区', '31.180968', '121.392415', 'https://m.tuniucdn.com/fb3/s1/2n9c/2WPfVp6auQkYoHzAdSbxwHAtQFfa_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200215548, '速8酒店（上海虹桥枢纽九亭中心路店）', '松江九亭镇中心路128号', 198, 39, '速8', '上海', '二钻', '七宝古镇', '31.119363', '121.322768', 'https://m.tuniucdn.com/fb2/t1/G1/M00/42/40/Cii-U1kziVOIGTw-AAGRMfcIwJwAALi6ACRnUsAAZFJ536_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (200216665, '维也纳酒店（上海奉贤南桥中心店）', '奉贤沪杭公路1758-8号', 1289, 38, '维也纳', '上海', '三钻', '奉贤开发区', '30.934646', '121.451449', 'https://m.tuniucdn.com/fb2/t1/G2/M00/DC/A8/Cii-T1kw5leIQAA3AAFzNYtL4loAAK9OQOyk4sAAXNN152_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (219484323, '7天连锁酒店(深圳观澜章阁店）', '宝安区章阁村桂月路章阁市场汇龙峰景一期A栋2-4层', 725, 40, '7天酒店', '深圳', '二钻', '观澜', '22.746493', '114.023', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3C/8C/Cii-U1kxXqaIeqeuAAHwF4GDmOcAALYFQI9zMMAAfAv100_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (223318960, '和颐酒店(深圳深南大道华强路地铁站店)', '深南中路2081号', 637, 46, '和颐', '深圳', '四钻', '华强北商业区', '22.540313', '114.088611', 'https://m.tuniucdn.com/fb3/s1/2n9c/2M7am7D8rPTeTQAhxqBeMSANaqGr_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (233036941, '7天连锁酒店(上海东林寺店)', '朱泾镇文商路79号', 218, 37, '7天酒店', '上海', '二钻', '金山枫泾古镇地区', '30.895912', '121.160238', 'https://m.tuniucdn.com/fb2/t1/G4/M00/35/13/Cii_J1zr5PyIY3acAAFCnHJPxLUAAGX-ABvcIMAAUK0087_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (234719711, '如家酒店·neo(北京朝阳北路十里堡地铁站店)', '朝阳北路八里庄南里26号', 378, 47, '如家', '北京', '二钻', '国贸地区', '39.922472', '116.501118', 'https://m.tuniucdn.com/fb3/s1/2n9c/2rHdXNCmycnUxw99AniFC25ZDSfJ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (234719728, '速8酒店（北京房山城关店）', '房山城关镇城隍庙街10号(原房山老公安局)', 392, 47, '速8', '北京', '二钻', '', '39.705216', '115.981904', 'https://m.tuniucdn.com/fb2/t1/G1/M00/3F/66/Cii9EFkyeImIB3ZVAAHcTtTFt4oAALdsgICDO0AAdxm378_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (235196477, '和颐酒店(北京总部基地店)', '丰葆路106号', 379, 45, '和颐', '北京', '四钻', '总部基地/丰台体育中心/南宫地区', '39.815383', '116.291012', 'https://m.tuniucdn.com/fb3/s1/2n9c/3J7Hcvwt5xZJL3NkS4wPJ6csmFb9_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (339777429, '上海嘉定喜来登酒店', '菊园新区嘉唐公路66号', 1286, 44, '喜来登', '上海', '五钻', '嘉定新城', '31.394595', '121.245773', 'https://m.tuniucdn.com/fb3/s1/2n9c/2v2fKuo5bzhunSBC1n1E42cLTkZV_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (339952837, '如家酒店(北京良乡西路店)', '良乡西路7号', 159, 46, '如家', '北京', '二钻', '房山风景区', '39.73167', '116.132482', 'https://m.tuniucdn.com/fb3/s1/2n9c/3Dpgf5RTTzrxpeN5y3RLnRVtxMEA_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (343341695, '和颐酒店(北京中关村软件园店)', '东北旺西路8号中关村软件园一期9号楼', 245, 47, '和颐', '北京', '四钻', '上地产业园/西三旗', '40.044663', '116.29607', 'https://m.tuniucdn.com/fb3/s1/2n9c/3hSkPeWRQ3VK1heRQpHzJNMTanQz_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (365011120, '和颐酒店(北京石景山万达广场店)', '鲁谷东街甲26号', 505, 47, '和颐', '北京', '四钻', '公主坟/五棵松/石景山游乐园地区', '39.895479', '116.240386', 'https://m.tuniucdn.com/fb3/s1/2n9c/3iwohdQzyZP9azUkYAwTFj7WzBwd_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (368343863, '如家酒店(上海金桥博兴路地铁站店)', '博兴路1119号', 218, 45, '如家', '上海', '二钻', '浦东金桥地区', '31.266272', '121.593829', 'https://m.tuniucdn.com/fb3/s1/2n9c/w5ERtGJEmdgdgy5qtLPatR1xfm4_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (368701368, '深圳大中华希尔顿酒店', '福田深南大道1003号', 1666, 46, '希尔顿', '深圳', '五钻', '会展中心/CBD', '22.539313', '114.069763', 'https://m.tuniucdn.com/fb3/s1/2n9c/4EnHseZ73LXdFJY7DSdJ8xqAcjXe_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1393017952, '汉庭酒店(深圳宝安松岗地铁站店)', '松岗镇河滨北路12号盛华大厦', 166, 47, '汉庭', '深圳', '二钻', '松岗商业中心区', '22.768912', '113.83325', 'https://m.tuniucdn.com/fb3/s1/2n9c/4NehRjdHyZDKxTjAxTYv27FHq8LJ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1400304687, '如家酒店(深圳横岗地铁站新马商贸城店)', '龙岗大道横岗段4004号', 149, 43, '如家', '深圳', '二钻', '龙岗中心区/大运新城', '22.642629', '114.202799', 'https://m.tuniucdn.com/fb2/t1/G6/M00/25/5A/Cii-TF3PFkiIb27dAAEqdDcKl3YAAEViQGVWY0AASqM960_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1406627919, '深圳中洲万豪酒店', '海德一道88号中洲控股中心A座', 204, 47, '万豪', '深圳', '五钻', '海岸城/后海', '22.517293', '113.933785', 'https://m.tuniucdn.com/fb3/s1/2n9c/3wsinQAcuWtCdmv1yxauVG2PSYpC_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1418471719, '上海宝龙丽笙酒店', '金海路2449弄2号', 860, 46, '丽笙', '上海', '五钻', '浦东金桥地区', '31.26571', '121.650132', 'https://m.tuniucdn.com/fb3/s1/2n9c/3myGUurFCriEVMGPy9yYMPFdb9Zh_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1455383931, '如家酒店(深圳宝安客运中心站店)', '西乡河西金雅新苑34栋', 169, 45, '如家', '深圳', '二钻', '宝安商业区', '22.590272', '113.881933', 'https://m.tuniucdn.com/fb3/s1/2n9c/2w9cbbpzjjsyd2wRhFrnUpBMT8b4_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1457521002, '7天连锁酒店(深圳西丽茶光地铁站店)', '珠光北路280号天下湘军1楼', 517, 39, '7天酒店', '深圳', '二钻', '大学城/西丽动物园', '22.576187', '113.956166', 'https://m.tuniucdn.com/fb2/t1/G2/M00/E3/E0/Cii-Tlkzdl6IfQYfAAHCgNVDe1sAALK6gPBDhQAAcKY242_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1463484295, '上海和平豪生酒店', '沪南公路2653-2号', 650, 41, '豪生', '上海', '四钻', '周浦康桥地区', '31.146478', '121.568218', 'https://m.tuniucdn.com/fb3/s1/2n9c/ZxM9gWHqj657ndRsHw4j4p3CQ5k_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1514269829, '如家酒店(上海东川路碧江商业广场店)', '东川路2645号', 218, 45, '如家', '上海', '二钻', '交大/闵行经济开发区', '31.008875', '121.402813', 'https://m.tuniucdn.com/fb3/s1/2n9c/R92UunuCRXiG826G9Ptu7orqs7b_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1557882030, '维也纳酒店（深圳东门老街店）', '罗湖区东门新园路37号益德楼', 336, 43, '维也纳', '深圳', '三钻', '东门商业区', '22.549413', '114.118866', 'https://m.tuniucdn.com/fb2/t1/G1/M00/45/83/Cii9EFk0opCIPl9CAAKHl3Egm6oAALoKwLNWlwAAoev470_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1557997004, '上海五角场凯悦酒店', '国定东路88号', 1104, 46, '凯悦', '上海', '五钻', '江湾/五角场商业区', '31.300645', '121.51918', 'https://m.tuniucdn.com/fb3/s1/2n9c/3a3Zz9cDgbJEEJ1GcXzKhTh21YqK_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1565094427, '上海国际旅游度假区万怡酒店', '秀浦路3999弄17号', 713, 45, '万怡', '上海', '四钻', '迪士尼度假区', '31.132913', '121.63464', 'https://m.tuniucdn.com/fb3/s1/2n9c/KPBUPunPDETYWg8WaJDSmiZC65z_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1584362548, '如家酒店(上海浦东国际旅游度假区御桥地铁站店)', '御青路315-317号', 339, 44, '如家', '上海', '二钻', '周浦康桥地区', '31.15719', '121.572392', 'https://m.tuniucdn.com/fb3/s1/2n9c/2ybd3wqdoBtBeKcPxmyso9y1hNXa_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1630005459, '7天连锁酒店（深圳地王大厦红桂路店）（原红桂路店）', '罗湖区宝安南路2078号深港豪苑（与红桂路交汇处）', 143, 39, '7天酒店', '深圳', '二钻', '', '22.550341', '114.10965', 'https://m.tuniucdn.com/fb2/t1/G2/M00/EA/18/Cii-T1k1KaGIIkQVAAD4fD_T3FcAALTtABiCJ8AAPiU164_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1637944903, '速8酒店北京后海店', '西城北京市西城区德胜门内大街兴华胡同五福里2号', 213, 39, '速8', '北京', '二钻', '后海', '39.934452', '116.38184', 'https://m.tuniucdn.com/fb2/t1/G1/M00/48/0C/Cii9EVk1JNuILdBWAAHv5O89TjMAALrFgJ8bwcAAe_8197_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1649956165, '上海南青华美达酒店', '华夏东路811号', 299, 47, '华美达', '上海', '四钻', '迪士尼度假区', '31.195206', '121.664791', 'https://m.tuniucdn.com/fb3/s1/2n9c/2RHmQgTpte3UVSDJ5KbqobbZGRnE_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1714520967, '速8酒店(北京安华桥黄寺大街店)', '黄寺大街12号院16号楼', 559, 43, '速8', '北京', '二钻', '马甸、安贞地区', '39.962742', '116.388431', 'https://m.tuniucdn.com/fb2/t1/G1/M00/4A/21/Cii-U1k1o-uIdcUZAAIbmIKVlKAAALtvQGBb6kAAhuw170_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1725781423, '上海三迪华美达酒店', '广富林路600弄7号', 690, 43, '华美达', '上海', '四钻', '佘山/松江大学城', '31.058023', '121.246536', 'https://m.tuniucdn.com/fb3/s1/2n9c/NoHym6tuKwVazxy33wRNTNuQWd2_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1734220581, '汉庭酒店(深圳大鹏佳兆业店)', '大鹏街道新园街12号', 378, 43, '汉庭', '深圳', '二钻', '较场尾/大鹏所城', '22.592661', '114.475167', 'https://m.tuniucdn.com/fb3/s1/2n9c/3nWzyWt63gtwPzRf5xbHvwKM27vU_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1754929048, '上海环球港凯悦酒店', '宁夏路718号', 1336, 45, '凯悦', '上海', '五钻', '中山公园商业区', '31.232041', '121.412492', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/B6/Cii-U13ZY-CIF-8MAAXkwQoY7FIAAFpQgEE1bgABeTZ750_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1762661667, '深圳佳兆业万豪酒店', '棕榈大道33号', 223, 46, '万豪', '深圳', '五钻', '较场尾/大鹏所城', '22.569193', '114.459325', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EC/Cii-TF3ZqE-IYM0NAAY6GIHLZNsAAFr2QDhR8EABjow444_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1765008760, '如家酒店(北京西直门北京北站店)', '西直门北大街49号', 356, 44, '如家', '北京', '二钻', '西直门/北京展览馆地区', '39.945106', '116.353827', 'https://m.tuniucdn.com/fb3/s1/2n9c/4CLwbCE9346jYn7nFsJTQXuBExTJ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1880614409, '上海崇明由由喜来登酒店', '揽海路2888号', 2198, 45, '喜来登', '上海', '五钻', '崇明岛/长兴岛/横沙岛', '31.462167', '121.823103', 'https://m.tuniucdn.com/fb3/s1/2n9c/21gDCGgRT3xFqCd3FxBh633j6Qsu_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1889333146, '如家酒店(北京西客站丽泽桥店)', '西三环南路44号-218', 459, 47, '如家', '北京', '二钻', '北京西站/丽泽商务区', '39.869638', '116.313075', 'https://m.tuniucdn.com/fb3/s1/2n9c/kG5corYUDC7U1qE8RAY6xCVnGxq_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1908594080, '上海建工浦江皇冠假日酒店', '陈行公路3701号', 843, 46, '皇冠假日', '上海', '五钻', '浦江镇地区', '31.090063', '121.489728', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/B7/Cii-U13ZZDWIePrGAAPyImW93N0AAFpRgMmj4MAA_I6005_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1913922369, '上海中建万怡酒店', '蟠文路333号', 889, 47, '万怡', '上海', '四钻', '虹桥机场/国家会展中心', '31.185504', '121.287709', 'https://m.tuniucdn.com/fb3/s1/2n9c/39Afm5Bxgd784eMeFB5DrcsPnhT_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1916002015, '上海苏宁环球万怡酒店', '丹巴路99号', 689, 45, '万怡', '上海', '四钻', '长风公园地区', '31.22292', '121.379912', 'https://m.tuniucdn.com/fb3/s1/2n9c/svpYHdmVDck91NqAhjtngcXth2G_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1928731731, '上海康桥万豪酒店', '康新公路4499号', 811, 46, '万豪', '上海', '五钻', '迪士尼度假区', '31.119187', '121.618966', 'https://m.tuniucdn.com/fb3/s1/2n9c/3inpPxTnvRjMCEB39K9FuHaXohYw_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1931442052, '深圳机场凯悦酒店', '宝安国际机场地面交通中心（GTC）18号出口', 291, 47, '凯悦', '深圳', '五钻', '宝安机场商圈', '22.622498', '113.812341', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EC/Cii-TF3ZqVeIJcTPAAUq_Ou_CrcAAFr4gKufPUABSsU446_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1931602865, '深圳联投东方万怡酒店', '松岗东方大道46号', 688, 45, '万怡', '深圳', '五钻', '松岗商业中心区', '22.760746', '113.856961', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/EC/Cii-U13ZqVyIOjdpAARI9aeBh-IAAFr4gOQh7oABEkN297_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1937347815, '北京望京凯悦酒店', '广顺南大街8号院2号楼', 617, 46, '凯悦', '北京', '五钻', '望京/酒仙桥/798地区', '39.991546', '116.476288', 'https://m.tuniucdn.com/fb3/s1/2n9c/2gLT4ZgJ8ZuS7sSmXzYoCXnV248p_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1942938880, '北京乐多港万豪酒店', '城南街道南口路29号', 227, 45, '万豪', '北京', '五钻', '昌平城区/十三陵度假区', '40.23264', '116.188888', 'https://m.tuniucdn.com/fb3/s1/2n9c/3mBWaZeaqq54E7kX2n7g9b2CZX6q_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1942992995, '上海嘉定凯悦酒店', '裕民南路1366号', 758, 46, '凯悦', '上海', '五钻', '嘉定新城', '31.352298', '121.263314', 'https://m.tuniucdn.com/fb2/t1/G6/M00/53/2D/Cii-U13edkqIfZhLAAJEW25WIF4AAGVxQIg38sAAkRz517_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1951709780, '深圳同泰万怡酒店', '福海街道宝安大道 6259号', 617, 48, '万怡', '深圳', '五钻', '深圳国际会展中心商圈', '22.678611', '113.805695', 'https://m.tuniucdn.com/fb3/s1/2n9c/3oUfktphxMAWq9hUxD9uqdjRdZGB_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1973839294, '深圳湾万怡酒店', '科技南路16号', 508, 47, '万怡', '深圳', '五钻', '科技园', '22.531101', '113.950615', 'https://m.tuniucdn.com/fb3/s1/2n9c/8C9QscRsvTWCx92wt17GAegEMFn_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1975922994, '如家酒店·neo(深圳南山海岸城南油地铁站店)', '南商路84-6号', 238, 44, '如家', '深圳', '二钻', '海岸城/后海', '22.513566', '113.9291', 'https://m.tuniucdn.com/fb2/t1/G6/M00/25/5E/Cii-TF3PGD-IQ0FcAAFIZC82AnkAAEVvAKdj4YAAUh8638_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1989806195, '深圳博林天瑞喜来登酒店', '留仙大道4088号', 1369, 48, '喜来登', '深圳', '五钻', '大学城/西丽动物园', '22.582918', '113.97219', 'https://m.tuniucdn.com/fb3/s1/2n9c/4Rx55fZoneUeKbE3TCRSPB6WQ6bw_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1996823660, '上海紫竹万怡酒店', '紫星路588号3幢', 642, 46, '万怡', '上海', '四钻', '交大/闵行经济开发区', '31.02118', '121.465186', 'https://m.tuniucdn.com/fb2/t1/G6/M00/53/2F/Cii-TF3edraIPzK9AAH_p8vdHKoAAGV3AJgSVEAAf-_019_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (1997830708, '和颐至尚酒店(北京上地软件园店)', '清河小营西路48号汇苑仁和大厦一层', 753, 47, '和颐', '北京', '四钻', '上地产业园/西三旗', '40.034623', '116.323925', 'https://m.tuniucdn.com/fb3/s1/2n9c/2sKjxS1hFYyBFVKVBqo2x2hSFvGj_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2003479905, '上海榕港万怡酒店', '新松江路1277号', 798, 46, '万怡', '上海', '四钻', '佘山/松江大学城', '31.038198', '121.210178', 'https://m.tuniucdn.com/fb3/s1/2n9c/2GM761BYH8k15qkNrJrja3cwfr2D_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2009548883, '和颐至尚酒店(北京首都机场新国展店)', '府前二街6号', 611, 46, '和颐', '北京', '三钻', '首都机场/新国展地区', '40.063953', '116.576829', 'https://m.tuniucdn.com/fb3/s1/2n9c/43zCTomkMSkUfZByZxn77YH2XidJ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2011785622, '北京世园凯悦酒店', '阜康南路1号院1号楼A', 558, 47, '凯悦', '北京', '五星级', '延庆休闲度假区', '40.440732', '115.963259', 'https://m.tuniucdn.com/fb3/s1/2n9c/uhGcQze3zZQxe4avSU8BysgYVvx_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2022598930, '上海宝华喜来登酒店', '南奉公路3111弄228号', 2899, 46, '喜来登', '上海', '五钻', '奉贤开发区', '30.921659', '121.575572', 'https://m.tuniucdn.com/fb2/t1/G6/M00/45/BD/Cii-TF3ZaBmIStrbAASnoOyg7FoAAFpYwEoz9oABKe4992_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2022881967, '深圳盐田凯悦酒店', '海景二路1025号1-6层、30-50层', 650, 47, '凯悦', '深圳', '五钻', '盐田区政府/沙头角', '22.551323', '114.23781', 'https://m.tuniucdn.com/fb3/s1/2n9c/2RFMLSujkczEn1HoybD6dUpN9pzr_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2031683181, '和颐至尚酒店(北京雍和宫和平里店)', '小黄庄1区15号', 299, 47, '和颐', '北京', '四钻', '马甸/安贞地区', '39.962361', '116.412931', 'https://m.tuniucdn.com/fb3/s1/2n9c/4Xqm5BN9pZTamwmYS3eLxL417YYt_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2045052822, '深圳国际会展中心皇冠假日酒店', '展云路6号', 675, 47, '皇冠假日', '深圳', '五钻', '深圳国际会展中心商圈', '22.686581', '113.777655', 'https://m.tuniucdn.com/fb3/s1/2n9c/4DGZygQpE4iSpcBDCoXJvjNr4oiR_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2048042240, '北京大兴希尔顿酒店', '高米店南里18号楼', 1283, 48, '希尔顿', '北京', '五钻', '大兴北京新机场地区', '39.76875', '116.339199', 'https://m.tuniucdn.com/fb3/s1/2n9c/3B32F8zSU2CJCWzs1hoH2o4WcquR_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2048047291, '北京新青海喜来登酒店', '丽泽金融商务区凤凰嘴北路与金中都西路交叉口西营街8号院1号楼', 723, 47, '喜来登', '北京', '五钻', '北京西站/丽泽商务区', '39.864026', '116.322505', 'https://m.tuniucdn.com/fb3/s1/2n9c/4DPQMu5sMM7XR1mvcjoqtWngc7TF_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2048050570, '汉庭酒店（深圳坪山火车站店）', '新和路127-2号', 436, 47, '汉庭', '深圳', '二钻', '坪山高铁站商圈', '22.700753', '114.339089', 'https://m.tuniucdn.com/fb3/s1/2n9c/2nXN2bWjfoqoTkPwHvLJQPYz17qD_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2048671293, '汉庭酒店(深圳观澜五和大道店)', '观湖街道五和大道327号', 234, 43, '汉庭', '深圳', '二钻', '观澜', '22.684459', '114.07708', 'https://m.tuniucdn.com/fb3/s1/2n9c/2JrQi83S9qgDEkXqWpe5iyi44Uh2_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2051661320, '汉庭酒店(深圳罗湖口岸万象城二店)', '桂园街道宝安南路1050号嘉宾花园C栋', 667, 47, '汉庭', '深圳', '三钻', '万象城/京基100', '22.540352', '114.112668', 'https://m.tuniucdn.com/fb3/s1/2n9c/34FRP7HLPhvKZP1a6tXu4XrJeiaw_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2056105938, '北京通州北投希尔顿酒店', '新华东街289号2号楼', 1068, 48, '希尔顿', '北京', '五钻', '果园环岛/通州区', '39.908805', '116.659748', 'https://m.tuniucdn.com/fb3/s1/2n9c/NGKdpec3tZJNUUNWJ5pd67Cp5AY_w200_h200_c1_t0.png');
INSERT INTO `tb_hotel` VALUES (2056126831, '上海虹桥金臣皇冠假日酒店', '申长路630弄1-3 号', 2488, 48, '皇冠假日', '上海', '五钻', '虹桥机场/国家会展中心', '31.19036', '121.31535', 'https://m.tuniucdn.com/fb3/s1/2n9c/PvFh4Vzc84xXhm5N41F6AqdAqyJ_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2056132395, '深圳深铁皇冠假日酒店', '深南大道9819号', 340, 47, '皇冠假日', '深圳', '五钻', '科技园', '22.538923', '113.944794', 'https://m.tuniucdn.com/fb3/s1/2n9c/eBLtrED2uJs7yURWfjnWge9dT1P_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2056298828, '上海中优城市万豪酒店', '沪南公路7688弄1号', 1200, 45, '万豪', '上海', '五钻', '南汇/野生动物园', '31.030053', '121.662943', 'https://m.tuniucdn.com/fb3/s1/2n9c/2gBATEyysyQWmw3wZL863HGdqjaq_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2058250574, '深圳湾万丽酒店', '粤海街道高新区社区科技南路18号', 351, 47, '万丽', '深圳', '五钻', '科技园', '22.531674', '113.951882', 'https://m.tuniucdn.com/fb3/s1/2n9c/2YWUpZsvPVkRiKgdPg95LJxaFmB6_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2060510277, '北京金隅八达岭皇冠假日酒店', '妫水北街1号1-14幢', 1026, 44, '皇冠假日', '北京', '五钻', '延庆休闲度假区', '40.476483', '115.97481', 'https://m.tuniucdn.com/fb3/s1/2n9c/3Dzq2KxgiQbmb1sbc5iK6xqpVuFr_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2060618247, '汉庭酒店(深圳海岸城店)', '粤海街道后海社区后海第二统建楼商业裙楼第二层B', 562, 49, '汉庭', '深圳', '二钻', '海岸城/后海', '22.507276', '113.931251', 'https://m.tuniucdn.com/fb3/s1/2n9c/TBoXdgEx5Yjc2HobeC3fPWWnSJi_w200_h200_c1_t0.jpg');
INSERT INTO `tb_hotel` VALUES (2062643512, '深圳国际会展中心希尔顿酒店', '展丰路80号', 285, 46, '希尔顿', '深圳', '五钻', '深圳国际会展中心商圈', '22.705335', '113.77794', 'https://m.tuniucdn.com/fb3/s1/2n9c/2SHUVXNrN5NsXsTUwcd1yaHKbrGq_w200_h200_c1_t0.jpg');

SET FOREIGN_KEY_CHECKS = 1;

数据库表结构为：

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;

导入项目

项目为黑马程序员SpringCloud P93中提到的hotel-demo

项目结构如图：

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说明：

初始化RestClient

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

分为三步：

引入es的RestHighLevelClient依赖：

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

初始化RestHighLevelClient：

初始化的代码如下：

1
2
3

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

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

package cn.itcast.hotel;

import org.apache.http.HttpHost;
import org.elasticsearch.client.RestHighLevelClient;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import java.io.IOException;

public class HotelIndexTest {
    private RestHighLevelClient client;

    @BeforeEach
    void setUp() {
        this.client = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.150.101:9200")
        ));
    }

    @AfterEach
    void tearDown() throws IOException {
        this.client.close();
    }
}

创建索引库

代码解读

创建索引库的API如下：

代码分为三步：

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

完整示例

在hotel-demo的cn.itcast.hotel.constants包下，创建一个类，定义mapping映射的JSON字符串常量：

package cn.itcast.hotel.constants;

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语句非常简单：

1	DELETE /hotel

与创建索引库相比：

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

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

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

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

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

判断索引库是否存在

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

1	GET /hotel

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

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

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

总结

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

索引库操作的基本步骤：

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

RestCline操作文档

新增文档

我们要将数据库的酒店数据查询出来，写入elasticsearch中。

索引库实体类

数据库查询后的结果是一个Hotel类型的对象。结构如下：

@Data
@TableName("tb_hotel")
public class Hotel {
    @TableId(type = IdType.INPUT)
    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 longitude;
    private String latitude;
    private String pic;
}

与我们的索引库结构存在差异：

longitude和latitude需要合并为location

因此，我们需要定义一个新的类型，与索引库结构吻合：

package cn.itcast.hotel.pojo;

import lombok.Data;
import lombok.NoArgsConstructor;

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

语法说明

新增文档的DSL语句如下：

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

对应的java代码如图：

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

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

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

完整代码

我们导入酒店数据，基本流程一致，但是需要考虑几点变化：

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

因此，代码整体步骤如下：

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

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

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

1	GET /hotel/_doc/{id}

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

准备Request对象
发送请求

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

可以看到，结果是一个JSON，其中文档放在一个_source属性中，因此解析就是拿到_source，反序列化为Java对象即可。

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

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

完整代码

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

@Test
void testGetDocumentById() throws IOException {
    // 1.准备Request
    GetRequest request = new GetRequest("hotel", "61082");
    // 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为是这样的：

1	DELETE /hotel/_doc/{id}

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

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

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

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

修改文档

语法说明

修改我们讲过两种方式：

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

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

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

这里不再赘述，我们主要关注增量修改。

代码示例如图：

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

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

完整代码

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

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

DSL查询文档

elasticsearch的查询依然是基于JSON风格的DSL来实现的。

DSL查询分类

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

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

查询的语法基本一致：

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

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

查询类型为match_all
没有查询条件

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

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

全文检索查询

使用场景

全文检索查询的基本流程如下：

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

比较常用的场景包括：

商城的输入框搜索
百度输入框搜索

例如京东：

因为是拿着词条去匹配，因此参与搜索的字段也必须是可分词的text类型的字段。

基本语法

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

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

match查询语法如下：

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

mulit_match语法如下：

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

示例

match查询示例：

multi_match查询示例：

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

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

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

总结

match和multi_match的区别是什么？

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

精准查询

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

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

term查询

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

语法：

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

示例：

当搜索的内容不是词条，而是多个词语形成的短语时，反而搜索不到：

range查询

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

基本语法：

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

示例：

总结

精确查询常见的有哪些？

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

地理坐标查询

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

常见的使用场景包括：

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

附近的酒店：

附近的车：

矩形范围查询

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

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

语法如下：

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

示例：

# geo_bounding_box查询
GET /hotel/_search
{
  "query": {
    "geo_bounding_box": {
      "location": {
        "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的酒店：

复合查询

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

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

算分函数查询

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

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

要想认为控制相关性算分，就需要利用elasticsearch中的function score 查询了。

语法说明

function score 查询中包含四部分内容：

原始查询条件：query部分，基于这个条件搜索文档，并且基于BM25算法给文档打分，原始算分（query score)
过滤条件：filter部分，符合该条件的文档才会重新算分
算分函数：符合filter条件的文档要根据这个函数做运算，得到的函数算分（function score），有四种函数
- weight：函数结果是常量
- field_value_factor：以文档中的某个字段值作为函数结果
- random_score：以随机数作为函数结果
- script_score：自定义算分函数算法
运算模式：算分函数的结果、原始查询的相关性算分，两者之间的运算方式，包括：
- multiply：相乘
- replace：用function score替换query score
- 其它，例如：sum、avg、max、min

function score的运行流程如下：

1）根据原始条件查询搜索文档，并且计算相关性算分，称为原始算分（query score）
2）根据过滤条件，过滤文档
3）符合过滤条件的文档，基于算分函数运算，得到函数算分（function score）
4）将原始算分（query score）和函数算分（function score）基于运算模式做运算，得到最终结果，作为相关性算分。

因此，其中的关键点是：

过滤条件：决定哪些文档的算分被修改
算分函数：决定函数算分的算法
运算模式：决定最终算分结果

示例

需求：给“如家”这个品牌的酒店排名靠前一些

翻译一下这个需求，转换为之前说的四个要点：

原始条件：不确定，可以任意变化
过滤条件：brand = “如家”
算分函数：可以简单粗暴，直接给固定的算分结果，weight
运算模式：比如求和

因此最终的DSL语句如下：

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

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

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

小结

function score query定义的三要素是什么？

过滤条件：哪些文档要加分
算分函数：如何计算function score
加权方式：function score 与 query score如何运算

布尔查询

布尔查询是一个或多个查询子句的组合，每一个子句就是一个子查询。子查询的组合方式有：

must：必须匹配每个子查询，类似“与”
should：选择性匹配子查询，类似“或”
must_not：必须不匹配，不参与算分，类似“非”
filter：必须匹配，不参与算分

比如在搜索酒店时，除了关键字搜索外，我们还可能根据品牌、价格、城市等字段做过滤：

每一个不同的字段，其查询的条件、方式都不一样，必须是多个不同的查询，而要组合这些查询，就必须用bool查询了。

需要注意的是，搜索时，参与打分的字段越多，查询的性能也越差。因此这种多条件查询时，建议这样做：

搜索框的关键字搜索，是全文检索查询，使用must查询，参与算分
其它过滤条件，采用filter查询。不参与算分

语法示例：

GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {"term": {"city": "上海" }}
      ],
      "should": [
        {"term": {"brand": "皇冠假日" }},
        {"term": {"brand": "华美达" }}
      ],
      "must_not": [
        { "range": { "price": { "lte": 500 } }}
      ],
      "filter": [
        { "range": {"score": { "gte": 45 } }}
      ]
    }
  }
}

示例

需求：搜索名字包含“如家”，价格不高于400，在坐标31.21,121.5周围10km范围内的酒店。

分析：

名称搜索，属于全文检索查询，应该参与算分。放到must中
价格不高于400，用range查询，属于过滤条件，不参与算分。放到must_not中
周围10km范围内，用geo_distance查询，属于过滤条件，不参与算分。放到filter中

小结

bool查询有几种逻辑关系？

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

搜索结果处理

搜索的结果可以按照用户指定的方式去处理或展示。

排序

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

普通字段排序

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

语法：

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

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

示例：

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

地理坐标排序

地理坐标排序略有不同。

语法说明

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/

假设我的位置是：31.034661，121.612282，寻找我周围距离最近的酒店。

分页

elasticsearch 默认情况下只返回top10的数据。而如果要查询更多数据就需要修改分页参数了。elasticsearch中通过修改from、size参数来控制要返回的分页结果：

from：从第几个文档开始
size：总共查询几个文档

类似于mysql中的limit ?, ?

基本的分页

分页的基本语法如下：

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 0, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}

深度分页问题

现在，我要查询990~1000的数据，查询逻辑要这么写：

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 990, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}

这里是查询990开始的数据，也就是第990~第1000条数据。

不过，elasticsearch内部分页时，必须先查询 0~1000条，然后截取其中的990 ~ 1000的这10条：

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

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

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

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

那如果我要查询9900~10000的数据呢？是不是要先查询TOP10000呢？那每个节点都要查询10000条？汇总到内存中？

当查询分页深度较大时，汇总数据过多，对内存和CPU会产生非常大的压力，因此elasticsearch会禁止from+ size 超过10000的请求。

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

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

高亮

高亮原理

什么是高亮显示呢？

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

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

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查询文档

文档的查询同样适用昨天学习的 RestHighLevelClient对象，基本步骤包括：

1）准备Request对象
2）准备请求参数
3）发起请求
4）解析响应

快速入门

我们以match_all查询为例

发起查询请求

代码解读：

第一步，创建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 {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    request.source()
        .query(QueryBuilders.matchAllQuery());
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);

    // 4.解析响应
    handleResponse(response);
}

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);
        System.out.println("hotelDoc = " + 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如下：

布尔查询

布尔查询是用must、must_not、filter等方式组合其它查询，代码示例如下：

可以看到，API与其它查询的差别同样是在查询条件的构建，QueryBuilders，结果解析等其他代码完全不变。

完整代码如下：

@Test
void testBool() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    // 2.1.准备BooleanQuery
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    // 2.2.添加term
    boolQuery.must(QueryBuilders.termQuery("city", "杭州"));
    // 2.3.添加range
    boolQuery.filter(QueryBuilders.rangeQuery("price").lte(250));

    request.source().query(boolQuery);
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}

排序、分页

搜索结果的排序和分页是与query同级的参数，因此同样是使用request.source()来设置。

对应的API如下：

完整代码示例：

@Test
void testPageAndSort() throws IOException {
    // 页码，每页大小
    int page = 1, size = 5;

    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    // 2.1.query
    request.source().query(QueryBuilders.matchAllQuery());
    // 2.2.排序 sort
    request.source().sort("price", SortOrder.ASC);
    // 2.3.分页 from、size
    request.source().from((page - 1) * size).size(5);
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);
}

高亮

高亮的代码与之前代码差异较大，有两点：

查询的DSL：其中除了查询条件，还需要添加高亮条件，同样是与query同级。
结果解析：结果除了要解析_source文档数据，还要解析高亮结果

高亮请求构建

高亮请求的构建API如下：

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

完整代码如下：

@Test
void testHighlight() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    // 2.1.query
    request.source().query(QueryBuilders.matchQuery("all", "如家"));
    // 2.2.高亮
    request.source().highlighter(new HighlightBuilder().field("name").requireFieldMatch(false));
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}

高亮结果解析

高亮的结果与查询的文档结果默认是分离的，并不在一起。

因此解析高亮的代码需要额外处理：

代码解读：

第一步：从结果中获取source。hit.getSourceAsString()，这部分是非高亮结果，json字符串。还需要反序列为HotelDoc对象
第二步：获取高亮结果。hit.getHighlightFields()，返回值是一个Map，key是高亮字段名称，值是HighlightField对象，代表高亮值
第三步：从map中根据高亮字段名称，获取高亮字段值对象HighlightField
第四步：从HighlightField中获取Fragments，并且转为字符串。这部分就是真正的高亮字符串了
第五步：用高亮的结果替换HotelDoc中的非高亮结果

完整代码如下：

private void handleResponse(SearchResponse response) {
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    // 4.1.获取总条数
    long total = searchHits.getTotalHits().value;
    System.out.println("共搜索到" + total + "条数据");
    // 4.2.文档数组
    SearchHit[] hits = searchHits.getHits();
    // 4.3.遍历
    for (SearchHit hit : hits) {
        // 获取文档source
        String json = hit.getSourceAsString();
        // 反序列化
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
        // 获取高亮结果
        Map<String, HighlightField> highlightFields = hit.getHighlightFields();
        if (!CollectionUtils.isEmpty(highlightFields)) {
            // 根据字段名获取高亮结果
            HighlightField highlightField = highlightFields.get("name");
            if (highlightField != null) {
                // 获取高亮值
                String name = highlightField.getFragments()[0].string();
                // 覆盖非高亮结果
                hotelDoc.setName(name);
            }
        }
        System.out.println("hotelDoc = " + hotelDoc);
    }
}

黑马旅游案例

下面，我们通过黑马旅游的案例来实战演练下之前学习的知识。

我们实现四部分功能：

酒店搜索和分页
酒店结果过滤
我周边的酒店
酒店竞价排名

启动我们提供的hotel-demo项目，其默认端口是8089，访问http://localhost:8090，就能看到项目页面了：

酒店搜索和分页

案例需求：实现黑马旅游的酒店搜索功能，完成关键字搜索和分页

需求分析

在项目的首页，有一个大大的搜索框，还有分页按钮：

点击搜索按钮，可以看到浏览器控制台发出了请求：

请求参数如下：

由此可以知道，我们这个请求的信息如下：

请求方式：POST
请求路径：/hotel/list
请求参数：JSON对象，包含4个字段：
- key：搜索关键字
- page：页码
- size：每页大小
- sortBy：排序，目前暂不实现
返回值：分页查询，需要返回分页结果PageResult，包含两个属性：
- total：总条数
- List<HotelDoc>：当前页的数据

因此，我们实现业务的流程如下：

步骤一：定义实体类，接收请求参数的JSON对象
步骤二：编写controller，接收页面的请求
步骤三：编写业务实现，利用RestHighLevelClient实现搜索、分页

定义实体类

实体类有两个，一个是前端的请求参数实体，一个是服务端应该返回的响应结果实体。

请求参数

前端请求的json结构如下：

{
    "key": "搜索关键字",
    "page": 1,
    "size": 3,
    "sortBy": "default"
}

因此，我们在cn.itcast.hotel.pojo包下定义一个实体类：

package cn.itcast.hotel.pojo;

import lombok.Data;

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

2）返回值

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

total：总条数
List<HotelDoc>：当前页的数据

因此，我们在cn.itcast.hotel.pojo中定义返回结果：

package cn.itcast.hotel.pojo;

import lombok.Data;

import java.util.List;

@Data
public class PageResult {
    private Long total;
    private List<HotelDoc> hotels;

    public PageResult() {
    }

    public PageResult(Long total, List<HotelDoc> hotels) {
        this.total = total;
        this.hotels = hotels;
    }
}

定义controller

定义一个HotelController，声明查询接口，满足下列要求：

请求方式：Post
请求路径：/hotel/list
请求参数：对象，类型为RequestParam
返回值：PageResult，包含两个属性
- Long total：总条数
- List<HotelDoc> hotels：酒店数据

因此，我们在cn.itcast.hotel.web中定义HotelController：

@RestController
@RequestMapping("/hotel")
public class HotelController {

    @Autowired
    private IHotelService hotelService;
	// 搜索酒店数据
    @PostMapping("/list")
    public PageResult search(@RequestBody RequestParams params){
        return hotelService.search(params);
    }
}

实现搜索业务

我们在controller调用了IHotelService，并没有实现该方法，因此下面我们就在IHotelService中定义方法，并且去实现业务逻辑。

1）在cn.itcast.hotel.service中的IHotelService接口中定义一个方法：

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

2）实现搜索业务，肯定离不开RestHighLevelClient，我们需要把它注册到Spring中作为一个Bean。在cn.itcast.hotel中的HotelDemoApplication中声明这个Bean：

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

3）在cn.itcast.hotel.service.impl中的HotelService中实现search方法：

@Override
public PageResult search(RequestParams params) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        String key = params.getKey();
        if (key == null || "".equals(key)) {
            boolQuery.must(QueryBuilders.matchAllQuery());
        } else {
            boolQuery.must(QueryBuilders.matchQuery("all", key));
        }

        // 2.2.分页
        int page = params.getPage();
        int size = params.getSize();
        request.source().from((page - 1) * size).size(size);

        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        return handleResponse(response);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

// 结果解析
private PageResult handleResponse(SearchResponse response) {
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    // 4.1.获取总条数
    long total = searchHits.getTotalHits().value;
    // 4.2.文档数组
    SearchHit[] hits = searchHits.getHits();
    // 4.3.遍历
    List<HotelDoc> hotels = new ArrayList<>();
    for (SearchHit hit : hits) {
        // 获取文档source
        String json = hit.getSourceAsString();
        // 反序列化
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
		// 放入集合
        hotels.add(hotelDoc);
    }
    // 4.4.封装返回
    return new PageResult(total, hotels);
}

酒店结果过滤

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

需求分析

在页面搜索框下面，会有一些过滤项：

传递的参数如图：

包含的过滤条件有：

brand：品牌值
city：城市
minPrice~maxPrice：价格范围
starName：星级

我们需要做两件事情：

修改请求参数的对象RequestParams，接收上述参数
修改业务逻辑，在搜索条件之外，添加一些过滤条件

修改实体类

修改在cn.itcast.hotel.pojo包下的实体类RequestParams：

@Data
public class RequestParams {
    private String key;
    private Integer page;
    private Integer size;
    private String sortBy;
    // 下面是新增的过滤条件参数
    private String city;
    private String brand;
    private String starName;
    private Integer minPrice;
    private Integer maxPrice;
}

修改搜索业务

在HotelService的search方法中，只有一个地方需要修改：requet.source().query( … )其中的查询条件。

在之前的业务中，只有match查询，根据关键字搜索，现在要添加条件过滤，包括：

品牌过滤：是keyword类型，用term查询
星级过滤：是keyword类型，用term查询
价格过滤：是数值类型，用range查询
城市过滤：是keyword类型，用term查询

多个查询条件组合，肯定是boolean查询来组合：

关键字搜索放到must中，参与算分
其它过滤条件放到filter中，不参与算分

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

buildBasicQuery的代码如下：

private void buildBasicQuery(RequestParams params, SearchRequest request) {
    // 1.构建BooleanQuery
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    // 2.关键字搜索
    String key = params.getKey();
    if (key == null || "".equals(key)) {
        boolQuery.must(QueryBuilders.matchAllQuery());
    } else {
        boolQuery.must(QueryBuilders.matchQuery("all", key));
    }
    // 3.城市条件
    if (params.getCity() != null && !params.getCity().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("city", params.getCity()));
    }
    // 4.品牌条件
    if (params.getBrand() != null && !params.getBrand().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("brand", params.getBrand()));
    }
    // 5.星级条件
    if (params.getStarName() != null && !params.getStarName().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("starName", params.getStarName()));
    }
	// 6.价格
    if (params.getMinPrice() != null && params.getMaxPrice() != null) {
        boolQuery.filter(QueryBuilders
                         .rangeQuery("price")
                         .gte(params.getMinPrice())
                         .lte(params.getMaxPrice())
                        );
    }
	// 7.放入source
    request.source().query(boolQuery);
}

我周边的酒店

需求：我附近的酒店

需求分析

在酒店列表页的右侧，有一个小地图，点击地图的定位按钮，地图会找到你所在的位置：

并且，在前端会发起查询请求，将你的坐标发送到服务端：

我们要做的事情就是基于这个location坐标，然后按照距离对周围酒店排序。实现思路如下：

修改RequestParams参数，接收location字段
修改search方法业务逻辑，如果location有值，添加根据geo_distance排序的功能

修改实体类

修改在cn.itcast.hotel.pojo包下的实体类RequestParams：

package cn.itcast.hotel.pojo;

import lombok.Data;

@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;
    // 我当前的地理坐标
    private String location;
}

距离排序API

我们以前学习过排序功能，包括两种：

普通字段排序
地理坐标排序

我们只讲了普通字段排序对应的java写法。地理坐标排序只学过DSL语法，如下：

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "price": "asc"  
    },
    {
      "_geo_distance" : {
          "FIELD" : "纬度，经度",
          "order" : "asc",
          "unit" : "km"
      }
    }
  ]
}

对应的java代码示例：

添加距离排序

在cn.itcast.hotel.service.impl的HotelService的search方法中，添加一个排序功能：

完整代码：

@Override
public PageResult search(RequestParams params) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        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);
    }
}

排序距离显示

重启服务后，测试我的酒店功能：

酒店竞价排名

需求：让指定的酒店在搜索结果中排名置顶

需求分析

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

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

那怎样才能让指定的酒店排名置顶呢？

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

过滤条件：哪些文档要加分
算分函数：如何计算function score
加权方式：function score 与 query score如何运算

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

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

true：是广告
false：不是广告

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

过滤条件：判断isAD 是否为true
算分函数：我们可以用最简单暴力的weight，固定加权值
加权方式：可以用默认的相乘，大大提高算分

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

给HotelDoc类添加isAD字段，Boolean类型
挑选几个你喜欢的酒店，给它的文档数据添加isAD字段，值为true
修改search方法，添加function score功能，给isAD值为true的酒店增加权重

修改HotelDoc实体

给cn.itcast.hotel.pojo包下的HotelDoc类添加isAD字段：

添加广告标记

接下来，我们挑几个酒店，添加isAD字段，设置为true：

POST /hotel/_update/1902197537
{
    "doc": {
        "isAD": true
    }
}
POST /hotel/_update/2056126831
{
    "doc": {
        "isAD": true
    }
}
POST /hotel/_update/1989806195
{
    "doc": {
        "isAD": true
    }
}
POST /hotel/_update/2056105938
{
    "doc": {
        "isAD": true
    }
}

添加算分函数查询

接下来我们就要修改查询条件了。之前是用的boolean 查询，现在要改成function_socre查询。

function_score查询结构如下：

对应的JavaAPI如下：

我们可以将之前写的boolean查询作为原始查询条件放到query中，接下来就是添加过滤条件、算分函数、加权模式了。所以原来的代码依然可以沿用。

修改cn.itcast.hotel.service.impl包下的HotelService类中的buildBasicQuery方法，添加算分函数查询：

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

数据聚合

**聚合（aggregations ）**可以让我们极其方便的实现对数据的统计、分析、运算。例如：

什么品牌的手机最受欢迎？
这些手机的平均价格、最高价格、最低价格？
这些手机每月的销售情况如何？

实现这些统计功能的比数据库的sql要方便的多，而且查询速度非常快，可以实现近实时搜索效果。

聚合的种类

聚合常见的有三类：

桶（Bucket）聚合：用来对文档做分组
- TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
- Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
度量（Metric）聚合：用以计算一些值，比如：最大值、最小值、平均值等
- Avg：求平均值
- Max：求最大值
- Min：求最小值
- Stats：同时求max、min、avg、sum等
管道（pipeline）聚合：其它聚合的结果为基础做聚合

注意：参加聚合的字段必须是keyword、日期、数值、布尔类型

DSL实现聚合

现在，我们要统计所有数据中的酒店品牌有几种，其实就是按照品牌对数据分组。此时可以根据酒店品牌的名称做聚合，也就是Bucket聚合。

Bucket聚合语法

语法如下：

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

结果如图：

聚合结果排序

默认情况下，Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序。

我们可以指定order属性，自定义聚合的排序方式：

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

限定聚合范围

默认情况下，Bucket聚合是对索引库的所有文档做聚合，但真实场景下，用户会输入搜索条件，因此聚合必须是对搜索结果聚合。那么聚合必须添加限定条件。

我们可以限定要聚合的文档范围，只要添加query条件即可：

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

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

Metric聚合语法

上节课，我们对酒店按照品牌分组，形成了一个个桶。现在我们需要对桶内的酒店做运算，获取每个品牌的用户评分的min、max、avg等值。

这就要用到Metric聚合了，例如stat聚合：就可以获取min、max、avg等结果。

语法如下：

GET /hotel/_search
{
  "size": 0, 
  "aggs": {
    "brandAgg": { 
      "terms": { 
        "field": "brand", 
        "size": 20
      },
      "aggs": { // 是brands聚合的子聚合，也就是分组后对每组分别计算
        "score_stats": { // 聚合名称
          "stats": { // 聚合类型，这里stats可以计算min、max、avg等
            "field": "score" // 聚合字段，这里是score
          }
        }
      }
    }
  }
}

这次的score_stats聚合是在brandAgg的聚合内部嵌套的子聚合。因为我们需要在每个桶分别计算。

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

小结

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

限定聚合的的文档范围

聚合必须的三要素：

聚合名称
聚合类型
聚合字段

聚合可配置属性有：

size：指定聚合结果数量
order：指定聚合结果排序方式
field：指定聚合字段

RestAPI实现聚合

API语法

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

聚合条件的语法：

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

业务需求

需求：搜索页面的品牌、城市等信息不应该是在页面写死，而是通过聚合索引库中的酒店数据得来的：

分析：

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

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

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

如何得知搜索结果中包含哪些品牌？如何得知搜索结果中包含哪些城市？

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

因为是对搜索结果聚合，因此聚合是限定范围的聚合，也就是说聚合的限定条件跟搜索文档的条件一致。

查看浏览器可以发现，前端其实已经发出了这样的一个请求：

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

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

结果是一个Map结构：

key是字符串，城市、星级、品牌、价格
value是集合，例如多个城市的名称

业务实现

在cn.itcast.hotel.web包的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方法，尚未实现。

在cn.itcast.hotel.service.IHotelService中定义新方法：

1	Map<String, List<String>> filters(RequestParams params);

在cn.itcast.hotel.service.impl.HotelService中实现该方法：

@Override
public Map<String, List<String>> filters(RequestParams params) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        buildBasicQuery(params, request);
        // 2.2.设置size
        request.source().size(0);
        // 2.3.聚合
        buildAggregation(request);
        // 3.发出请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析结果
        Map<String, List<String>> result = new HashMap<>();
        Aggregations aggregations = response.getAggregations();
        // 4.1.根据品牌名称，获取品牌结果
        List<String> brandList = getAggByName(aggregations, "brandAgg");
        result.put("品牌", brandList);
        // 4.2.根据品牌名称，获取品牌结果
        List<String> cityList = getAggByName(aggregations, "cityAgg");
        result.put("城市", cityList);
        // 4.3.根据品牌名称，获取品牌结果
        List<String> starList = getAggByName(aggregations, "starAgg");
        result.put("星级", starList);

        return result;
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

private void buildAggregation(SearchRequest request) {
    request.source().aggregation(AggregationBuilders
                                 .terms("brandAgg")
                                 .field("brand")
                                 .size(100)
                                );
    request.source().aggregation(AggregationBuilders
                                 .terms("cityAgg")
                                 .field("city")
                                 .size(100)
                                );
    request.source().aggregation(AggregationBuilders
                                 .terms("starAgg")
                                 .field("starName")
                                 .size(100)
                                );
}

private List<String> getAggByName(Aggregations aggregations, String aggName) {
    // 4.1.根据聚合名称获取聚合结果
    Terms brandTerms = aggregations.get(aggName);
    // 4.2.获取buckets
    List<? extends Terms.Bucket> buckets = brandTerms.getBuckets();
    // 4.3.遍历
    List<String> brandList = new ArrayList<>();
    for (Terms.Bucket bucket : buckets) {
        // 4.4.获取key
        String key = bucket.getKeyAsString();
        brandList.add(key);
    }
    return brandList;
}

自动补全

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

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

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

拼音分词器

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

课前资料中也提供了拼音分词器的安装包：

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

①解压

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

③重启elasticsearch

④测试

详细安装步骤可以参考IK分词器的安装过程。

测试用法如下：

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

结果：

自定义分词器

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

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

character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符
tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik_smart
tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等

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

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

PUT /test
{
  "settings": {
    "analysis": {
      "analyzer": { // 自定义分词器
        "my_analyzer": {  // 分词器名称
          "tokenizer": "ik_max_word",
          "filter": "py"
        }
      },
      "filter": { // 自定义tokenizer filter
        "py": { // 过滤器名称
          "type": "pinyin", // 过滤器类型，这里是pinyin
		  "keep_full_pinyin": false,
          "keep_joined_full_pinyin": true,
          "keep_original": true,
          "limit_first_letter_length": 16,
          "remove_duplicated_term": true,
          "none_chinese_pinyin_tokenize": false
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer": "my_analyzer",
        "search_analyzer": "ik_smart"
      }
    }
  }
}

测试：

总结：

如何使用拼音分词器？

①下载pinyin分词器
②解压并放到elasticsearch的plugin目录
③重启即可

如何自定义分词器？

①创建索引库时，在settings中配置，可以包含三部分
②character filter
③tokenizer
④filter

拼音分词器注意事项？

为了避免搜索到同音字，搜索时不要使用拼音分词器

自动补全查询

elasticsearch提供了Completion Suggester查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。为了提高补全查询的效率，对于文档中字段的类型有一些约束：

参与补全查询的字段必须是completion类型。
字段的内容一般是用来补全的多个词条形成的数组。

比如，一个这样的索引库：

// 创建索引库
PUT test
{
  "mappings": {
    "properties": {
      "title":{
        "type": "completion"
      }
    }
  }
}

然后插入下面的数据：

// 示例数据
POST test/_doc
{
  "title": ["Sony", "WH-1000XM3"]
}
POST test/_doc
{
  "title": ["SK-II", "PITERA"]
}
POST test/_doc
{
  "title": ["Nintendo", "switch"]
}

查询的DSL语句如下：

// 自动补全查询
GET /test/_search
{
  "suggest": {
    "title_suggest": {
      "text": "s", // 关键字
      "completion": {
        "field": "title", // 补全查询的字段
        "skip_duplicates": true, // 跳过重复的
        "size": 10 // 获取前10条结果
      }
    }
  }
}

实现酒店搜索框自动补全

现在，我们的hotel索引库还没有设置拼音分词器，需要修改索引库中的配置。但是我们知道索引库是无法修改的，只能删除然后重新创建。

另外，我们需要添加一个字段，用来做自动补全，将brand、suggestion、city等都放进去，作为自动补全的提示。

因此，总结一下，我们需要做的事情包括：

修改hotel索引库结构，设置自定义拼音分词器
修改索引库的name、all字段，使用自定义分词器
索引库添加一个新字段suggestion，类型为completion类型，使用自定义的分词器
给HotelDoc类添加suggestion字段，内容包含brand、business
重新导入数据到hotel库

修改酒店映射结构

代码如下：

// 酒店数据索引库
PUT /hotel
{
  "settings": {
    "analysis": {
      "analyzer": {
        "text_anlyzer": {
          "tokenizer": "ik_max_word",
          "filter": "py"
        },
        "completion_analyzer": {
          "tokenizer": "keyword",
          "filter": "py"
        }
      },
      "filter": {
        "py": {
          "type": "pinyin",
          "keep_full_pinyin": false,
          "keep_joined_full_pinyin": true,
          "keep_original": true,
          "limit_first_letter_length": 16,
          "remove_duplicated_term": true,
          "none_chinese_pinyin_tokenize": false
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "id":{
        "type": "keyword"
      },
      "name":{
        "type": "text",
        "analyzer": "text_anlyzer",
        "search_analyzer": "ik_smart",
        "copy_to": "all"
      },
      "address":{
        "type": "keyword",
        "index": false
      },
      "price":{
        "type": "integer"
      },
      "score":{
        "type": "integer"
      },
      "brand":{
        "type": "keyword",
        "copy_to": "all"
      },
      "city":{
        "type": "keyword"
      },
      "starName":{
        "type": "keyword"
      },
      "business":{
        "type": "keyword",
        "copy_to": "all"
      },
      "location":{
        "type": "geo_point"
      },
      "pic":{
        "type": "keyword",
        "index": false
      },
      "all":{
        "type": "text",
        "analyzer": "text_anlyzer",
        "search_analyzer": "ik_smart"
      },
      "suggestion":{
          "type": "completion",
          "analyzer": "completion_analyzer"
      }
    }
  }
}

修改HotelDoc实体

HotelDoc中要添加一个字段，用来做自动补全，内容可以是酒店品牌、城市、商圈等信息。按照自动补全字段的要求，最好是这些字段的数组。

因此我们在HotelDoc中添加一个suggestion字段，类型为List<String>，然后将brand、city、business等信息放到里面。

代码如下：

package cn.itcast.hotel.pojo;

import lombok.Data;
import lombok.NoArgsConstructor;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;

@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;
    private Object distance;
    private Boolean isAD;
    private List<String> suggestion;

    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();
        // 组装suggestion
        if(this.business.contains("/")){
            // business有多个值，需要切割
            String[] arr = this.business.split("/");
            // 添加元素
            this.suggestion = new ArrayList<>();
            this.suggestion.add(this.brand);
            Collections.addAll(this.suggestion, arr);
        }else {
            this.suggestion = Arrays.asList(this.brand, this.business);
        }
    }
}

重新导入

重新执行之前编写的导入数据功能，可以看到新的酒店数据中包含了suggestion：

数据同步

elasticsearch中的酒店数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步。

思路分析

常见的数据同步方案有三种：

同步调用
异步通知
监听binlog

同步调用

方案一：同步调用

基本步骤如下：

hotel-demo对外提供接口，用来修改elasticsearch中的数据
酒店管理服务在完成数据库操作后，直接调用hotel-demo提供的接口，

异步通知

方案二：异步通知

流程如下：

hotel-admin对mysql数据库数据完成增、删、改后，发送MQ消息
hotel-demo监听MQ，接收到消息后完成elasticsearch数据修改

监听binlog

方案三：监听binlog

流程如下：

给mysql开启binlog功能
mysql完成增、删、改操作都会记录在binlog中
hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容

选择

方式一：同步调用

优点：实现简单，粗暴
缺点：业务耦合度高

方式二：异步通知

优点：低耦合，实现难度一般
缺点：依赖mq的可靠性

方式三：监听binlog

优点：完全解除服务间耦合
缺点：开启binlog增加数据库负担、实现复杂度高

实现数据同步

思路

利用课前资料提供的hotel-admin项目作为酒店管理的微服务。当酒店数据发生增、删、改时，要求对elasticsearch中数据也要完成相同操作。

步骤：

导入课前资料提供的hotel-admin项目，启动并测试酒店数据的CRUD
声明exchange、queue、RoutingKey
在hotel-admin中的增、删、改业务中完成消息发送
在hotel-demo中完成消息监听，并更新elasticsearch中数据
启动并测试数据同步功能

导入demo

此demo为黑马程序员Spring Cloud课件中提供

运行后，访问 http://localhost:8099

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

声明交换机、队列

MQ结构如图：

引入依赖

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

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

声明队列交换机名称

在hotel-admin和hotel-demo中的cn.itcast.hotel.constatnts包下新建一个类MqConstants：

package cn.itcast.hotel.constatnts;

    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中，定义配置类，声明队列、交换机：

package cn.itcast.hotel.config;

import cn.itcast.hotel.constants.MqConstants;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.Queue;
import org.springframework.amqp.core.TopicExchange;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class MqConfig {
    @Bean
    public TopicExchange topicExchange(){
        return new TopicExchange(MqConstants.HOTEL_EXCHANGE, true, false);
    }

    @Bean
    public Queue insertQueue(){
        return new Queue(MqConstants.HOTEL_INSERT_QUEUE, true);
    }

    @Bean
    public Queue deleteQueue(){
        return new Queue(MqConstants.HOTEL_DELETE_QUEUE, true);
    }

    @Bean
    public Binding insertQueueBinding(){
        return BindingBuilder.bind(insertQueue()).to(topicExchange()).with(MqConstants.HOTEL_INSERT_KEY);
    }

    @Bean
    public Binding deleteQueueBinding(){
        return BindingBuilder.bind(deleteQueue()).to(topicExchange()).with(MqConstants.HOTEL_DELETE_KEY);
    }
}

发送MQ消息

在hotel-admin中的增、删、改业务中分别发送MQ消息：

接收MQ消息

hotel-demo接收到MQ消息要做的事情包括：

新增消息：根据传递的hotel的id查询hotel信息，然后新增一条数据到索引库
删除消息：根据传递的hotel的id删除索引库中的一条数据

首先在hotel-demo的cn.itcast.hotel.service包下的IHotelService中新增新增、删除业务

1
2
3

void deleteById(Long id);

void insertById(Long id);

给hotel-demo中的cn.itcast.hotel.service.impl包下的HotelService中实现业务：

@Override
public void deleteById(Long id) {
    try {
        // 1.准备Request
        DeleteRequest request = new DeleteRequest("hotel", id.toString());
        // 2.发送请求
        client.delete(request, RequestOptions.DEFAULT);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

@Override
public void insertById(Long id) {
    try {
        // 0.根据id查询酒店数据
        Hotel hotel = getById(id);
        // 转换为文档类型
        HotelDoc hotelDoc = new HotelDoc(hotel);

        // 1.准备Request对象
        IndexRequest request = new IndexRequest("hotel").id(hotel.getId().toString());
        // 2.准备Json文档
        request.source(JSON.toJSONString(hotelDoc), XContentType.JSON);
        // 3.发送请求
        client.index(request, RequestOptions.DEFAULT);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

编写监听器

在hotel-demo中的cn.itcast.hotel.mq包新增一个类：

package cn.itcast.hotel.mq;

import cn.itcast.hotel.constants.MqConstants;
import cn.itcast.hotel.service.IHotelService;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@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== 有搭建集群的详细步骤

集群脑裂问题

集群职责划分

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

例如一个集群结构如图：

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

突然，node1发生了故障：

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

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

微服务的保护

初识Sentinel

雪崩问题及解决方案

雪崩问题

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。

如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。

但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。

那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

超时处理

解决雪崩问题的常见方式有四种：

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

仓壁模式（隔离）

方案2：仓壁模式

仓壁模式来源于船舱的设计：

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

断路器（熔断）

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量，异常比例：

当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

限流（流控）

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。

总结

什么是雪崩问题？

微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

可以认为：

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

服务保护技术对比

在SpringCloud当中支持多种服务保护技术：

早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：

	Sentinel	Hystrix
隔离策略	信号量隔离	线程池隔离/信号量隔离
熔断降级策略	基于慢调用比例或异常比例	基于失败比率
实时指标实现	滑动窗口	滑动窗口（基于 RxJava）
规则配置	支持多种数据源	支持多种数据源
扩展性	多个扩展点	插件的形式
基于注解的支持	支持	支持
限流	基于 QPS，支持基于调用关系的限流	有限的支持
流量整形	支持慢启动、匀速排队模式	不支持
系统自适应保护	支持	不支持
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等	不完善
常见框架的适配	Servlet、Spring Cloud、Dubbo、gRPC 等	Servlet、Spring Cloud Netflix

Sentinel介绍和安装

初识Sentinel

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：https://sentinelguard.io/zh-cn/index.html

Sentinel 具有以下特征:

•丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

•完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

•广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。

•完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

安装Sentinel

下载

sentinel官方提供了UI控制台，方便我们对系统做限流设置。大家可以在GitHub下载。

运行

将jar包放到任意非中文目录，执行命令：

1	java -jar sentinel-dashboard-1.8.1.jar

如果要修改Sentinel的默认端口、账户、密码，可以通过下列配置：

配置项	默认值	说明
server.port	8080	服务端口
sentinel.dashboard.auth.username	sentinel	默认用户名
sentinel.dashboard.auth.password	sentinel	默认密码

例如，修改端口：

1	java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar

如果jdk版本较高启动报错可以使用

1	java '-Dserver.port=8090' --add-opens java.base/java.lang=ALL-UNNAMED -jar sentinel-dashboard-1.8.1.jar

访问

访问http://localhost:8080页面，就可以看到sentinel的控制台了：

需要输入账号和密码，默认都是：sentinel

登录后，发现一片空白，什么都没有：

这是因为我们还没有与微服务整合。

微服务整合Sentinel

我们在order-service中整合sentinel，并连接sentinel的控制台，步骤如下：

引入sentinel依赖

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

配置控制台

修改application.yaml文件，添加下面内容

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090 # 为sentinel的端口地址

访问order-service的任意端点

打开浏览器，访问http://localhost:8088/order/101，这样才能触发sentinel的监控。

然后再访问sentinel的控制台，查看效果：

流量控制

雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。我们先学习这种模式。

簇点链路

当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。

默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。

例如，我们刚才访问的order-service中的OrderController中的端点：/order/{orderId}

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

流控：流量控制
降级：降级熔断
热点：热点参数限流，是限流的一种
授权：请求的权限控制

快速入门

示例

点击资源/order/{orderId}后面的流控按钮，就可以弹出表单。

表单中可以填写限流规则，如下：

其含义是限制 /order/{orderId}这个资源的单机QPS为1，即每秒只允许1次请求，超出的请求会被拦截并报错。

练习

需求：给 /order/{orderId}这个资源设置流控规则，QPS不能超过 5，然后测试。

首先在sentinel控制台添加限流规则

利用jmeter测试

选择：

20个用户，2秒内运行完，QPS是10，超过了5.

选中流控入门，QPS<5右键运行：

注意，不要点击菜单中的执行按钮来运行。

结果：

可以看到，成功的请求每次只有5个

流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

快速入门测试的就是直接模式。

关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

配置规则：

语法说明：当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

需求说明：

在OrderController新建两个端点：/order/query和/order/update，无需实现业务
配置流控规则，当/order/ update资源被访问的QPS超过5时，对/order/query请求限流

定义/order/query请求，模拟订单查询

@GetMapping("/query")
public String queryOrder() {
    return "查询订单成功";
}

定义/order/update请求，模拟订单更新

@GetMapping("/update")
public String updateOrder() {
    return "更新订单成功";
}

重启服务，查看sentinel控制台的簇点链路：

配置流控规则

对哪个端点限流，就点击哪个端点后面的按钮。我们是对订单查询/order/query限流，因此点击它后面的按钮：

在表单中填写流控规则：

阈值相当于每秒请求的次数

在Jemeter测试

选择《流控模式-关联》：

可以看到1000个用户，100秒，因此QPS为10，超过了我们设定的阈值：5

查看http请求：

请求的目标是/order/update，这样这个断点就会触发阈值。

但限流的目标是/order/query，我们在浏览器访问，可以发现：

确实被限流了。

总结

链路模式

链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。

配置示例：

例如有两条请求链路：

/test1 –> /common
/test2 –> /common

如果只希望统计从/test2进入到/common的请求，则可以这样配置：

实战案例

需求：有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。

步骤：

在OrderService中添加一个queryGoods方法，不用实现业务
在OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法
在OrderController中添加一个/order/save的端点，调用OrderService的queryGoods方法
给queryGoods设置限流规则，从/order/query进入queryGoods的方法限制QPS必须小于2

实现：

1、添加查询商品方法

在order-service服务中，给OrderService类添加一个queryGoods方法

1
2
3

public void queryGoods(){
    System.err.println("查询商品");
}

2、查询订单时，查询商品

在order-service的OrderController中，修改/order/query端点的业务逻辑：

@GetMapping("/query")
public String queryOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.out.println("查询订单");
    return "查询订单成功";
}

3、新增订单，查询商品

在order-service的OrderController中，修改/order/save端点，模拟新增订单：

@GetMapping("/save")
public String saveOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.err.println("新增订单");
    return "新增订单成功";
}

4、给查询商品添加资源标记

默认情况下，OrderService中的方法是不被Sentinel监控的，需要我们自己通过注解来标记要监控的方法。

给OrderService的queryGoods方法添加@SentinelResource注解：

@SentinelResource("goods")
public void queryGoods(){
    System.err.println("查询商品");
}

链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源，会导致链路模式失效。

我们需要关闭这种对SpringMVC的资源聚合，修改order-service服务的application.yml文件：

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

重启服务，访问/order/query和/order/save，可以查看到sentinel的簇点链路规则中，出现了新的资源：

5、添加流量控制

点击goods资源后面的流控按钮，在弹出的表单中填写下面信息：

只统计从/order/query进入/goods的资源，QPS阈值为2，超出则被限流。

6、Jemeter测试

选择《流控模式-链路》：

可以看到这里200个用户，50秒内发完，QPS为4，超过了我们设定的阈值2

一个http请求是访问/order/save：

运行的结果：

完全不受影响。

另一个是访问/order/query：

运行结果：

每次只有2个通过。

总结

流控模式有哪些？

直接：对当前资源限流
关联：高优先级资源触发阈值，对低优先级资源限流。
链路：阈值统计时，只统计从指定资源进入当前资源的请求，是对请求来源的限流

流控效果

在流控的高级选项中，还有一个流控效果选项：

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

warm up

阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将QPS跑到最大值，可能导致服务瞬间宕机。

warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3.

例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.

案例

需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒

1、配置流控规则

2、Jemeter测试

选择《流控效果，warm up》：

QPS为10.

刚刚启动时，大部分请求失败，成功的只有3个，说明QPS被限定在3：

随着时间推移，成功比例越来越高：

到Sentinel控制台查看实时监控：

一段时间后：

排队等待

当请求超过QPS阈值时，快速失败和warm up会拒绝新的请求并抛出异常

而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

工作原理

例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。

那什么叫做预期等待时长呢？

比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：

第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms
第12个请求的预期等待时长 = 200 * （12-1） = 2200ms

现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：

如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：

平滑的QPS曲线，对于服务器来说是更友好的。

案例

需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s

1、添加流控规则

2、Jmeter测试

选择《流控效果，队列》：

QPS为15，已经超过了我们设定的10。

如果是之前的快速失败、warmup模式，超出的请求应该会直接报错。

但是我们看看队列模式的运行结果：

全部都通过了。

再去sentinel查看实时监控的QPS曲线：

QPS非常平滑，一致保持在10，但是超出的请求没有被拒绝，而是放入队列。因此响应时间（等待时间）会越来越长。

当队列满了以后，才会有部分请求失败：

总结

流控效果有哪些？

快速失败：QPS超过阈值时，拒绝新的请求
warm up： QPS超过阈值时，拒绝新的请求；QPS阈值是逐渐提升的，可以避免冷启动时高并发导致服务宕机。
排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；如果请求预期等待时长大于超时时间，直接拒绝

热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

全局参数限流

例如，一个根据id查询商品的接口：

访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，统计结果：

当id=1的请求触发阈值被限流时，id值不为1的请求不受影响。

配置示例：

代表的含义是：对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5

热点参数限流

刚才的配置中，对查询商品这个接口的所有商品一视同仁，QPS都限定为5.

而在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的QPS限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项了：

结合上一个配置，这里的含义是对0号的long类型参数限流，每1秒相同参数的QPS不能超过5，有两个例外：

•如果参数值是100，则每1秒允许的QPS为10

•如果参数值是101，则每1秒允许的QPS为15

案例

案例需求：给/order/{orderId}这个资源添加热点参数限流，规则如下：

默认的热点参数规则是每1秒请求量不超过2
给102这个参数设置例外：每1秒请求量不超过4
给103这个参数设置例外：每1秒请求量不超过10

注意事项：热点参数限流对默认的SpringMVC资源无效，需要利用@SentinelResource注解标记资源

1、标记资源

给order-service中的OrderController中的/order/{orderId}资源添加注解：

2、热点参数限流规则

访问该接口，可以看到我们标记的hot资源出现了：

这里不要点击hot后面的按钮，页面有BUG

点击左侧菜单中热点规则菜单：

点击新增，填写表单：

3、Jmeter测试

选择《热点参数限流 QPS1》：

这里发起请求的QPS为5.

包含3个http请求：

普通参数，QPS阈值为2

运行结果：

例外项，QPS阈值为4

运行结果：

例外项，QPS阈值为10

运行结果：

隔离和降级

限流是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。

而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。

线程隔离之前讲到过：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽。

熔断降级：是在调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问该服务的提供者了。

可以看到，不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。需要在调用方 发起远程调用时做线程隔离、或者服务熔断。

而我们的微服务远程调用都是基于Feign来完成的，因此我们需要将Feign与Sentinel整合，在Feign里面实现线程隔离和服务熔断。

FeignClient整合sentinel

SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。

修改配置，开启sentinel功能

修改OrderService的application.yml文件，开启Feign的Sentinel功能：

1
2
3

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

编写失败降级逻辑

业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。

给FeignClient编写失败后的降级逻辑

①方式一：FallbackClass，无法对远程调用的异常做处理

②方式二：FallbackFactory，可以对远程调用的异常做处理，我们选择这种

这里我们演示方式二的失败降级处理。

步骤一：在feing-api项目中定义类，实现FallbackFactory：

代码：

package cn.itcast.feign.clients.fallback;

import cn.itcast.feign.clients.UserClient;
import cn.itcast.feign.pojo.User;
import feign.hystrix.FallbackFactory;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    @Override
    public UserClient create(Throwable throwable) {
        return new UserClient() {
            @Override
            public User findById(Long id) {
                log.error("查询用户异常", throwable);
                return new User();
            }
        };
    }
}

步骤二：在feing-api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean：

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}

步骤三：在feing-api项目中的UserClient接口中使用UserClientFallbackFactory：

import cn.itcast.feign.clients.fallback.UserClientFallbackFactory;
import cn.itcast.feign.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {

    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

重启后，访问一次订单查询业务，然后查看sentinel控制台，可以看到新的簇点链路：

总结

Sentinel支持的雪崩解决方案：

线程隔离（仓壁模式）
降级熔断

Feign整合Sentinel的步骤：

在application.yml中配置：feign.sentienl.enable=true
给FeignClient编写FallbackFactory并注册为Bean
将FallbackFactory配置到FeignClient

线程隔离（舱壁模式）

线程隔离的实现方式

线程隔离有两种方式实现：

线程池隔离
信号量隔离（Sentinel默认采用）

如图：

线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果

信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。

两者的优缺点：

sentinel的线程隔离

用法说明：

在添加限流规则时，可以选择两种阈值类型：

QPS：就是每秒的请求数，在快速入门中已经演示过
线程数：是该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量，实现线程隔离（舱壁模式）。

案例需求：给 order-service服务中的UserClient的查询用户接口设置流控规则，线程数不能超过 2。然后利用jemeter测试。

1、隔离配置规则

选择feign接口后面的流控按钮：

填写表单：

2、Jemeter测试

选择《阈值类型-线程数<2》：

一次发生10个请求，有较大概率并发线程数超过2，而超出的请求会走之前定义的失败降级逻辑。

发现虽然结果都是通过了，不过部分请求得到的响应是降级返回的null信息。

总结

线程隔离的两种手段是？

信号量隔离
线程池隔离

信号量隔离的特点是？

基于计数器模式，简单，开销小

线程池隔离的特点是？

基于线程池模式，有额外开销，但隔离控制更强

熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器控制熔断和放行是通过状态机来完成的：

状态机包括三个状态：

closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态
half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态

断路器熔断策略有三种：慢调用、异常比例、异常数

慢调用

慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。

例如：

解读：RT超过500ms的调用是慢调用，统计最近10000ms内的请求，如果请求量超过10次，并且慢调用比例不低于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。

案例

需求：给 UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5

1、设置慢调用

修改user-service中的/user/{id}这个接口的业务。通过休眠模拟一个延迟时间

此时，orderId=101的订单，关联的是id为1的用户，调用时长为60ms：

orderId=102的订单，关联的是id为2的用户，调用时长为非常短；

2、设置熔断规则

下面，给feign接口设置降级规则：

规则：

超过50ms的请求都会被认为是慢请求

3、测试

在浏览器访问：http://localhost:8080/order/101，快速刷新5次，可以发现：

在浏览器访问：http://localhost:8080/order/102，竟然也被熔断了：

异常比例、异常数

异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。

例如，一个异常比例设置：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.4，则触发熔断。

一个异常数设置：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于2次，则触发熔断。

案例

需求：给 UserClient的查询用户接口设置降级规则，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5s

1、设置异常请求

首先，修改user-service中的/user/{id}这个接口的业务。手动抛出异常，以触发异常比例的熔断：

也就是说，id 为 2时，就会触发异常

2、设置熔断规则

下面，给feign接口设置降级规则：

规则：

在5次请求中，只要异常比例超过0.4，也就是有2次以上的异常，就会触发熔断。

测试

在浏览器快速访问：http://localhost:8080/order/102，快速刷新5次，触发熔断：

此时，我们去访问本来应该正常的103：

授权规则

授权规则可以对请求方来源做判断和控制。

授权规则

基本规则

授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。

白名单：来源（origin）在白名单内的调用者允许访问
黑名单：来源（origin）在黑名单内的调用者不允许访问

点击左侧菜单的授权，可以看到授权规则：

资源名：就是受保护的资源，例如/order/{orderId}
流控应用：是来源者的名单，
- 如果是勾选白名单，则名单中的来源被许可访问。
- 如果是勾选黑名单，则名单中的来源被禁止访问。

比如：

我们允许请求从gateway到order-service，不允许浏览器访问order-service，那么白名单中就要填写网关的来源名称（origin）。

如何获取origin

Sentinel是通过RequestOriginParser这个接口的parseOrigin来获取请求的来源的。

public interface RequestOriginParser {
    /**
     * 从请求request对象中获取origin，获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}

这个方法的作用就是从request对象中，获取请求者的origin值并返回。

默认情况下，sentinel不管请求者从哪里来，返回值永远是default，也就是说一切请求的来源都被认为是一样的值default。

因此，我们需要自定义这个接口的实现，让不同的请求，返回不同的origin。

例如order-service服务中，我们定义一个RequestOriginParser的实现类：

package cn.itcast.order.sentinel;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;

import javax.servlet.http.HttpServletRequest;

@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        // 1.获取请求头
        String origin = request.getHeader("origin");
        // 2.非空判断
        if (StringUtils.isEmpty(origin)) {
            origin = "blank";
        }
        return origin;
    }
}

我们会尝试从request-header中获取origin值。

给网关添加请求头

既然获取请求origin的方式是从reques-header中获取origin值，我们必须让所有从gateway路由到微服务的请求都带上origin头。

这个需要利用之前学习的一个GatewayFilter来实现，AddRequestHeaderGatewayFilter。

修改gateway服务中的application.yml，添加一个defaultFilter：

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway
      routes:
       # ...略

这样，从gateway路由的所有请求都会带上origin头，值为gateway。而从其它地方到达微服务的请求则没有这个头。

配置授权规则

接下来，我们添加一个授权规则，放行origin值为gateway的请求。

配置如下：

现在，我们直接跳过网关，访问order-service服务：

通过网关访问：

自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。

异常类型

而如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：

public interface BlockExceptionHandler {
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

这个方法有三个参数：

HttpServletRequest request：request对象
HttpServletResponse response：response对象
BlockException e：被sentinel拦截时抛出的异常

这里的BlockException包含多个不同的子类：

异常	说明
FlowException	限流异常
ParamFlowException	热点参数限流的异常
DegradeException	降级异常
AuthorityException	授权规则异常
SystemBlockException	系统规则异常

自定义异常处理

下面，我们就在order-service定义一个自定义异常处理类：

package cn.itcast.order.sentinel;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.BlockExceptionHandler;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityException;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeException;
import com.alibaba.csp.sentinel.slots.block.flow.FlowException;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;

        if (e instanceof FlowException) {
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
            msg = "没有权限访问";
            status = 401;
        }

        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}

重启测试，在不同场景下，会返回不同的异常消息.

限流：

授权拦截时：

规则持久化

现在，sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。

规则管理模式

规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：

原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。
pull模式
push模式

pull模式

pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

push模式

push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

实现push模式

略

分布式事务

分布式事务问题

本地事务

本地事务，也就是传统的单机事务，在传统数据库事务中，必须要满足三个原则：

分布式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

跨数据源的分布式事务
跨服务的分布式事务
综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

创建新订单
扣减商品库存
从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个”业务”，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

演示分布式事务问题

我们通过一个案例来演示分布式事务的问题：

这里的案例采用黑马程序员微服务课程中的案例

创建数据库，名为seata_demo，然后导入课前资料提供的SQL文件：

导入课前资料提供的微服务：

微服务结构如下：

其中：

seata-demo：父工程，负责管理项目依赖

account-service：账户服务，负责管理用户的资金账户。提供扣减余额的接口
storage-service：库存服务，负责管理商品库存。提供扣减库存的接口
order-service：订单服务，负责管理订单。创建订单时，需要调用account-service和storage-service

启动nacos、所有微服务
测试下单功能，发出Post请求：

请求如下：

1	curl --location --request POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200'

如图：

测试发现，当库存不足时，如果余额已经扣减，并不会回滚，出现了分布式事务问题。

理论基础

解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导。

CAP定理

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

Consistency（一致性）

Availability（可用性）

Partition tolerance （分区容错性）

它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

一致性

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

比如现在包含两个节点，其中的初始数据是一致的：

当我们修改其中一个节点的数据时，两者的数据产生了差异：

要想保住一致性，就必须实现node01 到 node02的数据同步：

可用性

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

如图，有三个节点的集群，访问任何一个都可以及时得到响应：

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：

分区容错

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。

当节点接收到新的数据变更时，就会出现问题了：

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。

也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个**事务协调者(TC)**：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

初识Seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。

Seata的架构

Seata事务管理中有三个重要的角色：

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构如图：

Seata基于上述架构提供了四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式：最终一致的分阶段事务模式，有业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式：长事务模式，有业务侵入

无论哪种方案，都离不开TC，也就是事务的协调者。

部署TC服务

部署Seata的tc-server

下载

首先我们要下载seata-server包，地址在http ://seata.io/zh-cn/blog/download .html

解压

在非中文目录解压缩这个zip包，其目录结构如下：

修改配置

修改conf目录下的registry.conf文件：

内容如下：

registry {
  # tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
  type = "nacos"

  nacos {
    # seata tc 服务注册到 nacos的服务名称，可以自定义
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SH"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
  type = "nacos"
  # 配置nacos地址等信息
  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

在nacos添加配置

特别注意，为了让tc服务的集群可以共享配置，我们选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。

格式如下：

配置内容如下：

# 数据存储方式，db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://localhost:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=root
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事务、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000

# 客户端与服务端传输方式
transport.serialization=seata
transport.compressor=none
# 关闭metrics功能，提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898

==其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。==

创建数据库表

特别注意：tc服务在管理分布式事务时，需要记录事务相关数据到数据库中，你需要提前创建好这些表。

新建一个名为seata的数据库

这些表主要记录全局事务、分支事务、全局锁信息：

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- 分支事务表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table`  (
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `status` tinyint(4) NULL DEFAULT NULL,
  `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime(6) NULL DEFAULT NULL,
  `gmt_modified` datetime(6) NULL DEFAULT NULL,
  PRIMARY KEY (`branch_id`) USING BTREE,
  INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

-- ----------------------------
-- 全局事务表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table`  (
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `status` tinyint(4) NOT NULL,
  `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `timeout` int(11) NULL DEFAULT NULL,
  `begin_time` bigint(20) NULL DEFAULT NULL,
  `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`xid`) USING BTREE,
  INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
  INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

SET FOREIGN_KEY_CHECKS = 1;

启动TC服务

进入bin目录，运行其中的seata-server.bat即可：

启动成功后，seata-server应该已经注册到nacos注册中心了。

如果启动失败可能是因为jdk版本过高导致，我们需要用编辑器打开seata-server.bat 添加以下内容

1 2	// 修改为本地电脑的路径 if "%JAVACMD%"=="" set JAVACMD="D:\jdk1.8\bin\java.exe"

打开浏览器，访问nacos地址：http://localhost:8848，然后进入服务列表页面，可以看到seata-tc-server的信息：

微服务集成seata

引入依赖

首先，我们需要在微服务中引入seata依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本较低，1.3.0，因此排除-->
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>${seata.version}</version>
</dependency>

修改配置文件

需要修改application.yml文件，添加一些配置：

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    # 参考tc服务自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服务在nacos中的服务名称
  tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
  service:
    vgroup-mapping: # 事务组与TC服务cluster的映射关系
      seata-demo: SH

动手实践

XA模式

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

两阶段提交

XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况：

异常情况：

一阶段：

事务协调者通知每个事物参与者执行本地事务
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

事务协调者基于一阶段的报告来判断下一步操作
- 如果一阶段都成功，则通知所有事务参与者，提交事务
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM一阶段的工作：

① 注册分支事务到TC

② 执行分支业务sql但不提交

③ 报告执行状态到TC

TC二阶段的工作：

TC检测各分支事务执行状态

a.如果都成功，通知所有RM提交事务

b.如果有失败，通知所有RM回滚事务

RM二阶段的工作：

接收TC指令，提交或回滚事务

优缺点

XA模式的优点是什么？

事务的强一致性，满足ACID原则。
常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务

实现XA模式

Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：

修改application.yml文件（每个参与事务的微服务），开启XA模式：

1 2	seata: data-source-proxy-mode: XA

给发起全局事务的入口方法添加@GlobalTransactional注解:

本例中是OrderServiceImpl中的create方法.

重启服务并测试

重启order-service，再次测试，发现无论怎样，三个微服务都能成功回滚。

AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

Seata的AT模型

基本流程图：

阶段一RM的工作：

注册分支事务
记录undo-log（数据快照）
执行业务sql并提交
报告事务状态

阶段二提交时RM的工作：

删除undo-log即可

阶段二回滚时RM的工作：

根据undo-log恢复数据到更新前

流程梳理

我们用一个真实的业务来梳理下AT模式的原理。

比如，现在又一个数据库表，记录用户余额：

id	money
1	100

其中一个分支业务要执行的SQL为：

1	update tb_account set money = money - 10 where id = 1

AT模式下，当前分支事务执行流程如下：

一阶段：

TM发起并注册全局事务到TC
TM调用分支事务
分支事务准备执行业务SQL
RM拦截业务SQL，根据where条件查询原始数据，形成快照。

1
2
3

{
    "id": 1, "money": 100
}

RM执行业务SQL，提交本地事务，释放数据库锁。此时 money = 90
RM报告本地事务状态给TC

二阶段：

TM通知TC事务结束
TC检查分支事务状态
- 如果都成功，则立即删除快照
- 如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为100

流程图：

AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致

脏写问题

在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

优缺点

AT模式的优点：

一阶段完成直接提交事务，释放数据库资源，性能比较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多

实现AT模式

AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。

只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。

导入数据库表，记录全局锁

导入课前资料提供的Sql文件：seata-at.sql，其中lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库：

/*
 Navicat Premium Data Transfer

 Source Server         : local
 Source Server Type    : MySQL
 Source Server Version : 50622
 Source Host           : localhost:3306
 Source Schema         : seata_demo

 Target Server Type    : MySQL
 Target Server Version : 50622
 File Encoding         : 65001

 Date: 20/06/2021 12:39:03
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for undo_log
-- ----------------------------
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization',
  `rollback_info` longblob NOT NULL COMMENT 'rollback info',
  `log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status',
  `log_created` datetime(6) NOT NULL COMMENT 'create datetime',
  `log_modified` datetime(6) NOT NULL COMMENT 'modify datetime',
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;

-- ----------------------------
-- Records of undo_log
-- ----------------------------



-- ----------------------------
-- Table structure for lock_table
-- ----------------------------
DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table`  (
  `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `branch_id` bigint(20) NOT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`row_key`) USING BTREE,
  INDEX `idx_branch_id`(`branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;


SET FOREIGN_KEY_CHECKS = 1;

修改application.yml文件，将事务模式修改为AT模式即可：

1 2	seata: data-source-proxy-mode: AT # 默认就是AT

重启服务并测试

TCC模式

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

流程分析

举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。

阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

初识余额：

余额充足，可以冻结：

此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。

**阶段二（Confirm)**：假如要提交（Confirm），则冻结金额扣减30

确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：

此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

**阶段二(Canncel)**：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30

需要回滚，那么就要释放冻结金额，恢复可用金额：

Seata的TCC模型

Seata中的TCC模型依然延续之前的事务架构，如图：

优缺点

TCC模式的每个阶段是做什么的？

Try：资源检查和预留
Confirm：业务执行和提交
Cancel：预留资源的释放

TCC的优点是什么？

一阶段完成直接提交事务，释放数据库资源，性能好
相比AT模型，无需生成快照，无需使用全局锁，性能最强
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点是什么？

有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理

事务悬挂和空回滚

1）空回滚

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

如图：

执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。

2）业务悬挂

对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂

实现TCC模式

解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在try、还是cancel？

1）思路分析

这里我们定义一张表：

CREATE TABLE `account_freeze_tbl` (
  `xid` varchar(128) NOT NULL,
  `user_id` varchar(255) DEFAULT NULL COMMENT '用户id',
  `freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额',
  `state` int(1) DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
  PRIMARY KEY (`xid`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

其中：

xid：是全局事务id
freeze_money：用来记录用户冻结金额
state：用来记录事务状态

那此时，我们的业务开怎么做呢？

Try业务：
- 记录冻结金额和事务状态到account_freeze表
- 扣减account表可用金额
Confirm业务
- 根据xid删除account_freeze表的冻结记录
Cancel业务
- 修改account_freeze表，冻结金额为0，state为2
- 修改account表，恢复可用金额
如何判断是否空回滚？
- cancel业务中，根据xid查询account_freeze，如果为null则说明try还没做，需要空回滚
如何避免业务悬挂？
- try业务中，根据xid查询account_freeze ，如果已经存在则证明Cancel已经执行，拒绝执行try业务

接下来，我们改造account-service，利用TCC实现余额扣减功能。

2）声明TCC接口

TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明，

我们在account-service项目中的cn.itcast.account.service包中新建一个接口，声明TCC三个接口：

package cn.itcast.account.service;

import io.seata.rm.tcc.api.BusinessActionContext;
import io.seata.rm.tcc.api.BusinessActionContextParameter;
import io.seata.rm.tcc.api.LocalTCC;
import io.seata.rm.tcc.api.TwoPhaseBusinessAction;

@LocalTCC
public interface AccountTCCService {

    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money")int money);

    boolean confirm(BusinessActionContext ctx);

    boolean cancel(BusinessActionContext ctx);
}

3）编写实现类

在account-service服务中的cn.itcast.account.service.impl包下新建一个类，实现TCC业务：

package cn.itcast.account.service.impl;

import cn.itcast.account.entity.AccountFreeze;
import cn.itcast.account.mapper.AccountFreezeMapper;
import cn.itcast.account.mapper.AccountMapper;
import cn.itcast.account.service.AccountTCCService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountMapper accountMapper;
    @Autowired
    private AccountFreezeMapper freezeMapper;

    @Override
    @Transactional
    public void deduct(String userId, int money) {
        // 0.获取事务id
        String xid = RootContext.getXID();
        // 1.扣减可用余额
        accountMapper.deduct(userId, money);
        // 2.记录冻结金额，事务状态
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);
        freeze.setState(AccountFreeze.State.TRY);
        freeze.setXid(xid);
        freezeMapper.insert(freeze);
    }

    @Override
    public boolean confirm(BusinessActionContext ctx) {
        // 1.获取事务id
        String xid = ctx.getXid();
        // 2.根据id删除冻结记录
        int count = freezeMapper.deleteById(xid);
        return count == 1;
    }

    @Override
    public boolean cancel(BusinessActionContext ctx) {
        // 0.查询冻结记录
        String xid = ctx.getXid();
        AccountFreeze freeze = freezeMapper.selectById(xid);

        // 1.恢复可用余额
        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
        // 2.将冻结金额清零，状态改为CANCEL
        freeze.setFreezeMoney(0);
        freeze.setState(AccountFreeze.State.CANCEL);
        int count = freezeMapper.updateById(freeze);
        return count == 1;
    }
}

SAGA模式

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。

其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。

Seata官网对于Saga的指南：https://seata.io/zh-cn/docs/user/saga.html

原理

在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga也分为两个阶段：

一阶段：直接提交本地事务
二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

优缺点

优点：

事务参与者可以基于事件驱动实现异步调用，吞吐高
一阶段直接提交事务，无锁，性能好
不用编写TCC中的三个阶段，实现简单

缺点：

软状态持续时间不确定，时效性差
没有锁，没有事务隔离，会有脏写

四种模式对比

我们从以下几个方面来对比四种实现：

一致性：能否保证事务的一致性？强一致还是最终一致？
隔离性：事务之间的隔离性如何？
代码侵入：是否需要对业务代码改造？
性能：有无性能损耗？
场景：常见的业务场景

如图：

高可用

Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性。

高可用架构模型

搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。

但集群并不能确保100%安全，万一集群所在机房故障怎么办？所以如果要求较高，一般都会做异地多机房容灾。

比如一个TC集群在上海，另一个TC集群在杭州：

微服务基于事务组（tx-service-group)与TC集群的映射关系，来查找当前应该使用哪个TC集群。当SH集群故障时，只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。

实现高可用

1.模拟异地容灾的TC集群

计划启动两台seata的tc服务节点：

节点名称	ip地址	端口号	集群名称
seata	127.0.0.1	8091	SH
seata2	127.0.0.1	8092	HZ

之前我们已经启动了一台seata服务，端口是8091，集群名为SH。

现在，将seata目录复制一份，起名为seata2

修改seata2/conf/registry.conf内容如下：

registry {
  # tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
  type = "nacos"

  nacos {
    # seata tc 服务注册到 nacos的服务名称，可以自定义
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "HZ"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
  type = "nacos"
  # 配置nacos地址等信息
  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

进入seata2/bin目录，然后运行命令：

1	seata-server.bat -p 8092

打开nacos控制台，查看服务列表：

点进详情查看：

2.将事务组映射配置到nacos

接下来，我们需要将tx-service-group与cluster的映射关系都配置到nacos配置中心。

新建一个配置：

配置的内容如下：

# 事务组映射关系
service.vgroupMapping.seata-demo=SH

service.enableDegrade=false
service.disableGlobalTransaction=false
# 与TC服务的通信配置
transport.type=TCP
transport.server=NIO
transport.heartbeat=true
transport.enableClientBatchSendRequest=false
transport.threadFactory.bossThreadPrefix=NettyBoss
transport.threadFactory.workerThreadPrefix=NettyServerNIOWorker
transport.threadFactory.serverExecutorThreadPrefix=NettyServerBizHandler
transport.threadFactory.shareBossWorker=false
transport.threadFactory.clientSelectorThreadPrefix=NettyClientSelector
transport.threadFactory.clientSelectorThreadSize=1
transport.threadFactory.clientWorkerThreadPrefix=NettyClientWorkerThread
transport.threadFactory.bossThreadSize=1
transport.threadFactory.workerThreadSize=default
transport.shutdown.wait=3
# RM配置
client.rm.asyncCommitBufferLimit=10000
client.rm.lock.retryInterval=10
client.rm.lock.retryTimes=30
client.rm.lock.retryPolicyBranchRollbackOnConflict=true
client.rm.reportRetryCount=5
client.rm.tableMetaCheckEnable=false
client.rm.tableMetaCheckerInterval=60000
client.rm.sqlParserType=druid
client.rm.reportSuccessEnable=false
client.rm.sagaBranchRegisterEnable=false
# TM配置
client.tm.commitRetryCount=5
client.tm.rollbackRetryCount=5
client.tm.defaultGlobalTransactionTimeout=60000
client.tm.degradeCheck=false
client.tm.degradeCheckAllowTimes=10
client.tm.degradeCheckPeriod=2000

# undo日志配置
client.undo.dataValidation=true
client.undo.logSerialization=jackson
client.undo.onlyCareUpdateColumns=true
client.undo.logTable=undo_log
client.undo.compress.enable=true
client.undo.compress.type=zip
client.undo.compress.threshold=64k
client.log.exceptionRate=100

3.微服务读取nacos配置

接下来，需要修改每一个微服务的application.yml文件，让微服务读取nacos中的client.properties文件：

seata:
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      username: nacos
      password: nacos
      group: SEATA_GROUP
      data-id: client.properties

重启微服务，现在微服务到底是连接tc的SH集群，还是tc的HZ集群，都统一由nacos的client.properties来决定了。

分布式缓存

– 基于Redis集群解决单机Redis存在的问题

单机的Redis存在四大问题：

Redis持久化

Redis有两种持久化方案：

RDB持久化
AOF持久化

RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

执行时机

RDB持久化在四种情况下会执行：

执行save命令
执行bgsave命令
Redis停机时
触发RDB条件时

1.save命令

执行下面的命令，可以立即执行一次RDB：

save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。

2.bgsave命令

下面的命令可以异步执行RDB：

这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。

3）停机时

Redis停机时会执行一次save命令，实现RDB持久化。

4）触发RDB条件

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000

RDB的其它配置也可以在redis.conf文件中设置：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./

RDB原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

小结

RDB方式bgsave的基本流程？

fork主进程得到一个子进程，共享内存空间
子进程读取内存数据并写入新的RDB文件
用新RDB文件替换旧的RDB文件

RDB会在什么时候执行？save 60 1000代表什么含义？

默认是服务停止时
代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
fork子进程、压缩、写出RDB文件都比较耗时

AOF持久化

AOF原理

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

三种策略对比：

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：mset name jack num 666

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

Redis主从

搭建主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

集群结构

我们搭建的主从集群结构如图：

共包含三个节点，一个主节点，两个从节点。

这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IP	PORT	角色
192.168.150.101	7001	master
192.168.150.101	7002	slave
192.168.150.101	7003	slave

准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我们创建三个文件夹，名字分别叫7001、7002、7003：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir 7001 7002 7003

如图：

恢复原始配置

修改redis-6.2.4/redis.conf文件，将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态。

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000

# 关闭AOF
appendonly no

然后将redis-6.2.4/redis.conf文件拷贝到三个目录中（在/tmp目录执行下列命令）：

# 方式一：逐个拷贝
cp redis-6.2.4/redis.conf 7001
cp redis-6.2.4/redis.conf 7002
cp redis-6.2.4/redis.conf 7003
# 方式二：管道组合命令，一键拷贝
echo 7001 7002 7003 | xargs -t -n 1 cp redis-6.2.4/redis.conf

修改每个文件夹内的配置文件，将端口分别修改为7001、7002、7003，将rdb文件保存位置都修改为自己所在目录（在/tmp目录执行下列命令）：

1
2
3

sed -i -e 's/6379/7001/g' -e 's/dir .\//dir \/tmp\/7001\//g' 7001/redis.conf
sed -i -e 's/6379/7002/g' -e 's/dir .\//dir \/tmp\/7002\//g' 7002/redis.conf
sed -i -e 's/6379/7003/g' -e 's/dir .\//dir \/tmp\/7003\//g' 7003/redis.conf

修改每个实例的声明IP

虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息，格式如下：

1 2	# redis实例的声明 IP replica-announce-ip 192.168.150.101

每个目录都要改，我们一键完成修改（在/tmp目录执行下列命令）：

# 逐一执行
sed -i '1a replica-announce-ip 192.168.150.101' 7001/redis.conf
sed -i '1a replica-announce-ip 192.168.150.101' 7002/redis.conf
sed -i '1a replica-announce-ip 192.168.150.101' 7003/redis.conf

# 或者一键修改
printf '%s\n' 7001 7002 7003 | xargs -I{} -t sed -i '1a replica-announce-ip 192.168.150.101' {}/redis.conf

启动

为了方便查看日志，我们打开3个ssh窗口，分别启动3个redis实例，启动命令：

# 第1个
redis-server 7001/redis.conf
# 第2个
redis-server 7002/redis.conf
# 第3个
redis-server 7003/redis.conf

启动后：

如果要一键停止，可以运行下面命令：

1	printf '%s\n' 7001 7002 7003 \| xargs -I{} -t redis-cli -p {} shutdown

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

修改配置文件（永久生效）
- 在redis.conf中添加一行配置：slaveof <masterip> <masterport>
使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：
1
slaveof <masterip> <masterport>

注意：在5.0以后新增命令replicaof，与salveof效果一致。

这里我们为了演示方便，使用方式二。

通过redis-cli命令连接7002，执行下面命令：

# 连接 7002
redis-cli -p 7002
# 执行slaveof
slaveof 192.168.150.101 7001

通过redis-cli命令连接7003，执行下面命令：

# 连接 7003
redis-cli -p 7003
# 执行slaveof
slaveof 192.168.150.101 7001

然后连接 7001节点，查看集群状态：

# 连接 7001
redis-cli -p 7001
# 查看状态
info replication

结果：

测试

执行下列操作以测试：

利用redis-cli连接7001，执行set num 123
利用redis-cli连接7002，执行get num，再执行set num 666
利用redis-cli连接7003，执行get num，再执行set num 888

可以发现，只有在7001这个master节点上可以执行写操作，7002和7003这两个slave节点只能执行读操作。

主从数据同步原理

全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

这里有一个问题，master如何得知salve是第一次来连接呢？？

有几个概念，可以作为判断依据：

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。

因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。

master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

如图：

完整流程描述：

slave节点请求增量同步
master节点判断replid，发现不一致，拒绝增量同步
master将完整内存数据生成RDB，发送RDB到slave
slave清空本地数据，加载master的RDB
master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
slave执行接收到的命令，保持与master之间的同步

增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

那么master怎么知道slave与自己的数据差异在哪里呢?

repl_backlog原理

master怎么知道slave与自己的数据差异在哪里呢?

这就要说到全量同步时的repl_baklog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

直到数组被填满

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

小结

简述全量同步和增量同步区别？

全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

slave节点第一次连接master节点时
slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

slave节点断开又恢复，并且在repl_baklog中能找到offset时

Redis哨兵

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。

哨兵原理

集群结构和作用

哨兵的结构如图：

哨兵的作用如下：

监控：Sentinel 会不断检查您的master和slave是否按预期工作
自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

•主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

•客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

集群故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
最后是判断slave节点的运行id大小，越小优先级越高。

当选出一个新的master后，该如何实现切换呢？

流程如下：

sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

小结

Sentinel的三个作用是什么？

监控
故障转移
通知

Sentinel如何判断一个redis实例是否健康？

每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

首先选定一个slave作为新的master，执行slaveof no one
然后让所有节点都执行slaveof 新master
修改故障节点配置，添加slaveof 新master

搭建哨兵集群

集群结构

这里我们搭建一个三节点形成的Sentinel集群，来监管之前的Redis主从集群。如图：

三个sentinel实例信息如下：

节点	IP	PORT
s1	192.168.150.101	27001
s2	192.168.150.101	27002
s3	192.168.150.101	27003

准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我们创建三个文件夹，名字分别叫s1、s2、s3：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir s1 s2 s3

如图：

然后我们在s1目录创建一个sentinel.conf文件，添加下面的内容：

port 27001
sentinel announce-ip 192.168.150.101
sentinel monitor mymaster 192.168.150.101 7001 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/tmp/s1"

解读：

port 27001：是当前sentinel实例的端口
sentinel monitor mymaster 192.168.150.101 7001 2：指定主节点信息
- mymaster：主节点名称，自定义，任意写
- 192.168.150.101 7001：主节点的ip和端口
- 2：选举master时的quorum值

然后将s1/sentinel.conf文件拷贝到s2、s3两个目录中（在/tmp目录执行下列命令）：

# 方式一：逐个拷贝
cp s1/sentinel.conf s2
cp s1/sentinel.conf s3
# 方式二：管道组合命令，一键拷贝
echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf

修改s2、s3两个文件夹内的配置文件，将端口分别修改为27002、27003：

1 2	sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf

启动

为了方便查看日志，我们打开3个ssh窗口，分别启动3个redis实例，启动命令：

# 第1个
redis-sentinel s1/sentinel.conf
# 第2个
redis-sentinel s2/sentinel.conf
# 第3个
redis-sentinel s3/sentinel.conf

启动后：

测试

尝试让master节点7001宕机，查看sentinel日志：

查看7003的日志：

查看7002的日志：

RedisTemplate

在Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。

下面，我们通过一个测试来实现RedisTemplate集成哨兵机制。

导入Demo工程

首先，我们引入课前资料提供的Demo工程：

这里使用黑马程序员的微服务课程中的项目

引入依赖

在项目的pom文件中引入依赖：

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

配置Redis地址

然后在配置文件application.yml中指定redis的sentinel相关信息：

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

配置读写分离

在项目的启动类中，添加一个新的bean：

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
    return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

这个bean中配置的就是读写策略，包括四种：

MASTER：从主节点读取
MASTER_PREFERRED：优先从master节点读取，master不可用才读取replica
REPLICA：从slave（replica）节点读取
REPLICA _PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

Redis分片集群

搭建分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

海量数据存储问题
高并发写的问题

使用分片集群可以解决上述问题，如图:

分片集群特征：

集群中有多个master，每个master保存不同数据
每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确节点

集群结构

分片集群需要的节点数量较多，这里我们搭建一个最小的分片集群，包含3个master节点，每个master包含一个slave节点，结构如下：

这里我们会在同一台虚拟机中开启6个redis实例，模拟分片集群，信息如下：

IP	PORT	角色
192.168.150.101	7001	master
192.168.150.101	7002	master
192.168.150.101	7003	master
192.168.150.101	8001	slave
192.168.150.101	8002	slave
192.168.150.101	8003	slave

准备实例和配置

删除之前的7001、7002、7003这几个目录，重新创建出7001、7002、7003、8001、8002、8003目录：

# 进入/tmp目录
cd /tmp
# 删除旧的，避免配置干扰
rm -rf 7001 7002 7003
# 创建目录
mkdir 7001 7002 7003 8001 8002 8003

在/tmp下准备一个新的redis.conf文件，内容如下：

port 6379
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称，不需要我们创建，由redis自己维护
cluster-config-file /tmp/6379/nodes.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir /tmp/6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
replica-announce-ip 192.168.150.101
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log

将这个文件拷贝到每个目录下：

# 进入/tmp目录
cd /tmp
# 执行拷贝
echo 7001 7002 7003 8001 8002 8003 | xargs -t -n 1 cp redis.conf

修改每个目录下的redis.conf，将其中的6379修改为与所在目录一致：

# 进入/tmp目录
cd /tmp
# 修改配置文件
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t sed -i 's/6379/{}/g' {}/redis.conf

启动

因为已经配置了后台启动模式，所以可以直接启动服务：

# 进入/tmp目录
cd /tmp
# 一键启动所有服务
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-server {}/redis.conf

通过ps查看状态：

1	ps -ef \| grep redis

发现服务都已经正常启动：

如果要关闭所有进程，可以执行命令：

1	ps -ef \| grep redis \| awk '{print $2}' \| xargs kill

或者（推荐这种方式）：

1	printf '%s\n' 7001 7002 7003 8001 8002 8003 \| xargs -I{} -t redis-cli -p {} shutdown

创建集群

虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。

我们需要执行命令来创建集群，在Redis5.0之前创建集群比较麻烦，5.0之后集群管理命令都集成到了redis-cli中。

Redis5.0之前

Redis5.0之前集群命令都是用redis安装包下的src/redis-trib.rb来实现的。因为redis-trib.rb是有ruby语言编写的所以需要安装ruby环境。

1
2
3

# 安装依赖
yum -y install zlib ruby rubygems
gem install redis

然后通过命令来管理集群：

# 进入redis的src目录
cd /tmp/redis-6.2.4/src
# 创建集群
./redis-trib.rb create --replicas 1 192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 192.168.150.101:8001 192.168.150.101:8002 192.168.150.101:8003

Redis5.0以后

我们使用的是Redis6.2.4版本，集群管理以及集成到了redis-cli中，格式如下：

1	redis-cli --cluster create --cluster-replicas 1 192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 192.168.150.101:8001 192.168.150.101:8002 192.168.150.101:8003

命令说明：

redis-cli --cluster或者./redis-trib.rb：代表集群操作命令
create：代表是创建集群
--replicas 1或者--cluster-replicas 1 ：指定集群中每个master的副本个数为1，此时节点总数 ÷ (replicas + 1) 得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master

运行后的样子：

这里输入yes，则集群开始创建：

通过命令可以查看集群状态：

1	redis-cli -p 7001 cluster nodes

测试

尝试连接7001节点，存储一个数据：

# 连接
redis-cli -p 7001
# 存储数据
set num 123
# 读取数据
get num
# 再次存储
set a 1

结果悲剧了：

集群操作时，需要给redis-cli加上-c参数才可以：

1	redis-cli -c -p 7001

这次可以了：

散列插槽

插槽原理

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

key中包含”{}”，且“{}”中至少包含1个字符，“{}”中的部分是有效部分
key中不包含“{}”，整个key都是有效部分

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

如图，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。

到了7003后，执行get num时，对num做hash运算，对16384取余，得到的结果是2765，因此需要切换到7001节点

小结

Redis如何判断某个key应该在哪个实例？

将16384个插槽分配到不同的实例
根据key的有效部分计算哈希值，对16384取余
余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

集群伸缩

redis-cli –cluster提供了很多操作集群的命令，可以通过下面方式查看：

比如，添加节点的命令：

需求分析

需求：向集群中添加一个新的master节点，并向其中存储 num = 10

启动一个新的redis实例，端口为7004
添加7004到之前的集群，并作为一个master节点
给7004节点分配插槽，使得num这个key可以存储到7004实例

这里需要两个新的功能：

添加一个节点到集群中
将部分插槽分配到新插槽

创建新的redis实例

创建一个文件夹：

1	mkdir 7004

拷贝配置文件：

1	cp redis.conf /7004

修改配置文件：

1	sed /s/6379/7004/g 7004/redis.conf

启动

1	redis-server 7004/redis.conf

添加新节点到redis

添加节点的语法如下：

执行命令：

1	redis-cli --cluster add-node 192.168.150.101:7004 192.168.150.101:7001

通过命令查看集群状态：

1	redis-cli -p 7001 cluster nodes

如图，7004加入了集群，并且默认是一个master节点：

但是，可以看到7004节点的插槽数量为0，因此没有任何数据可以存储到7004上

转移插槽

我们要将num存储到7004节点，因此需要先看看num的插槽是多少：

如上图所示，num的插槽为2765.

我们可以将0~3000的插槽从7001转移到7004，命令格式如下：

具体命令如下：

建立连接：

得到下面的反馈：

询问要移动多少个插槽，我们计划是3000个：

新的问题来了：

那个node来接收这些插槽？？

显然是7004，那么7004节点的id是多少呢？

复制这个id，然后拷贝到刚才的控制台后：

这里询问，你的插槽是从哪里移动过来的？

all：代表全部，也就是三个节点各转移一部分
具体的id：目标节点的id
done：没有了

这里我们要从7001获取，因此填写7001的id：

填完后，点击done，这样插槽转移就准备好了：

确认要转移吗？输入yes：

然后，通过命令查看结果：

可以看到：

目的达成。

故障转移

集群初识状态是这样的：

其中7001、7002、7003都是master，我们计划让7002宕机。

自动故障转移

当集群中有一个master宕机会发生什么呢？

直接停止一个redis实例，例如7002：

1	redis-cli -p 7002 shutdown

首先是该实例与其它实例失去连接
然后是疑似宕机：

最后是确定下线，自动提升一个slave为新的master：

当7002再次启动，就会变为一个slave节点了：

手动故障转移

利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

这种failover命令可以指定三种模式：

缺省：默认的流程，如图1~6歩
force：省略了对offset的一致性校验
takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见

案例需求：在7002这个slave节点执行手动故障转移，重新夺回master地位

步骤如下：

1）利用redis-cli连接7002这个节点

2）执行cluster failover命令

如图：

效果：

RedisTemplate访问分片集群

RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：

1）引入redis的starter依赖

2）配置分片集群地址

3）配置读写分离

与哨兵模式相比，其中只有分片集群的配置方式略有差异，如下：

spring:
  redis:
    cluster:
      nodes:
        - 192.168.150.101:7001
        - 192.168.150.101:7002
        - 192.168.150.101:7003
        - 192.168.150.101:8001
        - 192.168.150.101:8002
        - 192.168.150.101:8003

多级缓存

什么是多级缓存

传统的缓存策略一般是请求到达Tomcat后，先查询Redis，如果未命中则查询数据库，如图：

存在下面的问题：

•请求要经过Tomcat处理，Tomcat的性能成为整个系统的瓶颈

•Redis缓存失效时，会对数据库产生冲击

多级缓存就是充分利用请求处理的每个环节，分别添加缓存，减轻Tomcat压力，提升服务性能：

浏览器访问静态资源时，优先读取浏览器本地缓存
访问非静态资源（ajax查询数据）时，访问服务端
请求到达Nginx后，优先读取Nginx本地缓存
如果Nginx本地缓存未命中，则去直接查询Redis（不经过Tomcat）
如果Redis查询未命中，则查询Tomcat
请求进入Tomcat后，优先查询JVM进程缓存
如果JVM进程缓存未命中，则查询数据库

在多级缓存架构中，Nginx内部需要编写本地缓存查询、Redis查询、Tomcat查询的业务逻辑，因此这样的nginx服务不再是一个反向代理服务器，而是一个编写业务的Web服务器了。

因此这样的业务Nginx服务也需要搭建集群来提高并发，再有专门的nginx服务来做反向代理，如图：

另外，我们的Tomcat服务将来也会部署为集群模式：

可见，多级缓存的关键有两个：

一个是在nginx中编写业务，实现nginx本地缓存、Redis、Tomcat的查询
另一个就是在Tomcat中实现JVM进程缓存

其中Nginx编程则会用到OpenResty框架结合Lua这样的语言。

这也是今天课程的难点和重点。

JVM进程缓存

为了演示多级缓存的案例，我们先准备一个商品查询的业务。

导入案例

为了演示多级缓存，我们先导入一个商品管理的案例，其中包含商品的CRUD功能。我们将来会给查询商品添加多级缓存。

这里的案例我们使用黑马程序员微服务项目中的案例

安装MySQL

后期做数据同步需要用到MySQL的主从功能，所以需要大家在虚拟机中，利用Docker来运行一个MySQL容器。

准备目录

为了方便后期配置MySQL，我们先准备两个目录，用于挂载容器的数据和配置文件目录：

# 进入/tmp目录
cd /tmp
# 创建文件夹
mkdir mysql
# 进入mysql目录
cd mysql

运行命令

进入mysql目录后，执行下面的Docker命令：

docker run \
 -p 3306:3306 \
 --name mysql \
 -v $PWD/conf:/etc/mysql/conf.d \
 -v $PWD/logs:/logs \
 -v $PWD/data:/var/lib/mysql \
 -e MYSQL_ROOT_PASSWORD=root \
 --privileged \
 -d \
 mysql:5.7

修改配置

在/tmp/mysql/conf目录添加一个my.cnf文件，作为mysql的配置文件：

1 2	# 创建文件 touch /tmp/mysql/conf/my.cnf

文件的内容如下：

[mysqld]
skip-name-resolve
character_set_server=utf8
datadir=/var/lib/mysql
server-id=1000

重启

配置修改后，必须重启容器：

1	docker restart mysql

导入SQL

接下来，利用Navicat客户端连接MySQL，

/*
 Navicat Premium Data Transfer

 Source Server         : 192.168.150.101
 Source Server Type    : MySQL
 Source Server Version : 50725
 Source Host           : 192.168.150.101:3306
 Source Schema         : heima

 Target Server Type    : MySQL
 Target Server Version : 50725
 File Encoding         : 65001

 Date: 16/08/2021 14:45:07
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for tb_item
-- ----------------------------
DROP TABLE IF EXISTS `tb_item`;
CREATE TABLE `tb_item`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '商品id',
  `title` varchar(264) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '商品标题',
  `name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '商品名称',
  `price` bigint(20) NOT NULL COMMENT '价格（分）',
  `image` varchar(200) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '商品图片',
  `category` varchar(200) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '类目名称',
  `brand` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '品牌名称',
  `spec` varchar(200) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '规格',
  `status` int(1) NULL DEFAULT 1 COMMENT '商品状态 1-正常，2-下架，3-删除',
  `create_time` datetime NULL DEFAULT NULL COMMENT '创建时间',
  `update_time` datetime NULL DEFAULT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `status`(`status`) USING BTREE,
  INDEX `updated`(`update_time`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 50002 CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = '商品表' ROW_FORMAT = COMPACT;

-- ----------------------------
-- Records of tb_item
-- ----------------------------
INSERT INTO `tb_item` VALUES (10001, 'RIMOWA 21寸托运箱拉杆箱 SALSA AIR系列果绿色 820.70.36.4', 'SALSA AIR', 16900, 'https://m.360buyimg.com/mobilecms/s720x720_jfs/t6934/364/1195375010/84676/e9f2c55f/597ece38N0ddcbc77.jpg!q70.jpg.webp', '拉杆箱', 'RIMOWA', '{\"颜色\": \"红色\", \"尺码\": \"26寸\"}', 1, '2019-05-01 00:00:00', '2019-05-01 00:00:00');
INSERT INTO `tb_item` VALUES (10002, '安佳脱脂牛奶 新西兰进口轻欣脱脂250ml*24整箱装*2', '脱脂牛奶', 68600, 'https://m.360buyimg.com/mobilecms/s720x720_jfs/t25552/261/1180671662/383855/33da8faa/5b8cf792Neda8550c.jpg!q70.jpg.webp', '牛奶', '安佳', '{\"数量\": 24}', 1, '2019-05-01 00:00:00', '2019-05-01 00:00:00');
INSERT INTO `tb_item` VALUES (10003, '唐狮新品牛仔裤女学生韩版宽松裤子 A款/中牛仔蓝（无绒款） 26', '韩版牛仔裤', 84600, 'https://m.360buyimg.com/mobilecms/s720x720_jfs/t26989/116/124520860/644643/173643ea/5b860864N6bfd95db.jpg!q70.jpg.webp', '牛仔裤', '唐狮', '{\"颜色\": \"蓝色\", \"尺码\": \"26\"}', 1, '2019-05-01 00:00:00', '2019-05-01 00:00:00');
INSERT INTO `tb_item` VALUES (10004, '森马(senma)休闲鞋女2019春季新款韩版系带板鞋学生百搭平底女鞋 黄色 36', '休闲板鞋', 10400, 'https://m.360buyimg.com/mobilecms/s720x720_jfs/t1/29976/8/2947/65074/5c22dad6Ef54f0505/0b5fe8c5d9bf6c47.jpg!q70.jpg.webp', '休闲鞋', '森马', '{\"颜色\": \"白色\", \"尺码\": \"36\"}', 1, '2019-05-01 00:00:00', '2019-05-01 00:00:00');
INSERT INTO `tb_item` VALUES (10005, '花王（Merries）拉拉裤 M58片 中号尿不湿（6-11kg）（日本原装进口）', '拉拉裤', 38900, 'https://m.360buyimg.com/mobilecms/s720x720_jfs/t24370/119/1282321183/267273/b4be9a80/5b595759N7d92f931.jpg!q70.jpg.webp', '拉拉裤', '花王', '{\"型号\": \"XL\"}', 1, '2019-05-01 00:00:00', '2019-05-01 00:00:00');

-- ----------------------------
-- Table structure for tb_item_stock
-- ----------------------------
DROP TABLE IF EXISTS `tb_item_stock`;
CREATE TABLE `tb_item_stock`  (
  `item_id` bigint(20) NOT NULL COMMENT '商品id，关联tb_item表',
  `stock` int(10) NOT NULL DEFAULT 9999 COMMENT '商品库存',
  `sold` int(10) NOT NULL DEFAULT 0 COMMENT '商品销量',
  PRIMARY KEY (`item_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = COMPACT;

-- ----------------------------
-- Records of tb_item_stock
-- ----------------------------
INSERT INTO `tb_item_stock` VALUES (10001, 99996, 3219);
INSERT INTO `tb_item_stock` VALUES (10002, 99999, 54981);
INSERT INTO `tb_item_stock` VALUES (10003, 99999, 189);
INSERT INTO `tb_item_stock` VALUES (10004, 99999, 974);
INSERT INTO `tb_item_stock` VALUES (10005, 99999, 18649);

SET FOREIGN_KEY_CHECKS = 1;

其中包含两张表：

tb_item：商品表，包含商品的基本信息
tb_item_stock：商品库存表，包含商品的库存信息

之所以将库存分离出来，是因为库存是更新比较频繁的信息，写操作较多。而其他信息修改的频率非常低。

导入Demo工程

下面导入课前资料提供的工程：

项目结构如图所示：

其中的业务包括：

分页查询商品
新增商品
修改商品
修改库存
删除商品
根据id查询商品
根据id查询库存

业务全部使用mybatis-plus来实现，如有需要请自行修改业务逻辑。