3月
12

public class Parent {
    private static final String PARENT = "parent";
    private static final String CHILD = "child";
    public Parent() {
    	System.out.print(PARENT + "A ");
    }
    static {
   		System.out.print(PARENT + "B ");
    }
    {
    	System.out.print(PARENT + "C ");
    }
    
    static class Child extends Parent {
    	public Child() {
    	System.out.print(CHILD + "A ");
    	}
    	static {
    		System.out.print(CHILD + "B ");
    	}
        {
        	System.out.print(CHILD + "C ");
        }
    }
    
    public static void main(String[] args) {
    	Child child = new Child();
    }
}

输出结果：parentB childB parentC parentA childC childA

官方解析：考察父类、子类的加载顺序：

父类的静态代码块 > 子类的静态代码块 > 父类的动态代码块 > 父类的构造方法 > 子类的动态代码块 > 子类的构造方法。

2、

3、

3月
05

3-Elasticsearch

微服务,Elasticsearch

分布式搜索引擎03

0.学习目标

1.数据聚合

**聚合（aggregations ）**可以让我们极其方便的实现对数据的统计、分析、运算。例如：

什么品牌的手机最受欢迎？
这些手机的平均价格、最高价格、最低价格？
这些手机每月的销售情况如何？

实现这些统计功能的比数据库的sql要方便的多，而且查询速度非常快，可以实现近实时搜索效果。

1.1.聚合的种类

聚合常见的有三类：

**桶（Bucket）**聚合：用来对文档做分组
- TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
- Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
**度量（Metric）**聚合：用以计算一些值，比如：最大值、最小值、平均值等
- Avg：求平均值
- Max：求最大值
- Min：求最小值
- Stats：同时求max、min、avg、sum等
**管道（pipeline）**聚合：其它聚合的结果为基础做聚合

**注意：**参加聚合的字段必须是keyword、日期、数值、布尔类型

1.2.DSL实现聚合

现在，我们要统计所有数据中的酒店品牌有几种，其实就是按照品牌对数据分组。此时可以根据酒店品牌的名称做聚合，也就是Bucket聚合。

1.2.1.Bucket聚合语法

语法如下：

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

结果如图：

1.2.2.聚合结果排序

默认情况下，Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序。

我们可以指定order属性，自定义聚合的排序方式：

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

1.2.3.限定聚合范围

默认情况下，Bucket聚合是对索引库的所有文档做聚合，但真实场景下，用户会输入搜索条件，因此聚合必须是对搜索结果聚合。那么聚合必须添加限定条件。

我们可以限定要聚合的文档范围，只要添加query条件即可：

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

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

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

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

1.2.5.小结

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

限定聚合的的文档范围

聚合必须的三要素：

聚合名称
聚合类型
聚合字段

聚合可配置属性有：

size：指定聚合结果数量
order：指定聚合结果排序方式
field：指定聚合字段

1.3.RestAPI实现聚合

1.3.1.API语法

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

聚合条件的语法：

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

1.3.2.业务需求

需求：搜索页面的品牌、城市等信息不应该是在页面写死，而是通过聚合索引库中的酒店数据得来的：

分析：

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

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

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

如何得知搜索结果中包含哪些品牌？如何得知搜索结果中包含哪些城市？

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

因为是对搜索结果聚合，因此聚合是限定范围的聚合，也就是说聚合的限定条件跟搜索文档的条件一致。

查看浏览器可以发现，前端其实已经发出了这样的一个请求：

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

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

结果是一个Map结构：

key是字符串，城市、星级、品牌、价格
value是集合，例如多个城市的名称

1.3.3.业务实现

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

2.自动补全

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

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

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

2.1.拼音分词器

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

课前资料中也提供了拼音分词器的安装包：

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

①解压

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

③重启elasticsearch

④测试

详细安装步骤可以参考IK分词器的安装过程。

测试用法如下：

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

结果：

2.2.自定义分词器

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

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

拼音分词器注意事项？

为了避免搜索到同音字，搜索时不要使用拼音分词器

2.3.自动补全查询

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条结果
      }
    }
  }
}

2.4.实现酒店搜索框自动补全

现在，我们的hotel索引库还没有设置拼音分词器，需要修改索引库中的配置。但是我们知道索引库是无法修改的，只能删除然后重新创建。

另外，我们需要添加一个字段，用来做自动补全，将brand、suggestion、city等都放进去，作为自动补全的提示。

因此，总结一下，我们需要做的事情包括：

修改hotel索引库结构，设置自定义拼音分词器
修改索引库的name、all字段，使用自定义分词器
索引库添加一个新字段suggestion，类型为completion类型，使用自定义的分词器
给HotelDoc类添加suggestion字段，内容包含brand、business
重新导入数据到hotel库

2.4.1.修改酒店映射结构

代码如下：

// 酒店数据索引库
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"
      }
    }
  }
}

2.4.2.修改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);
        }
    }
}

2.4.3.重新导入

重新执行之前编写的导入数据功能，可以看到新的酒店数据中包含了suggestion：

2.4.4.自动补全查询的JavaAPI

之前我们学习了自动补全查询的DSL，而没有学习对应的JavaAPI，这里给出一个示例：

而自动补全的结果也比较特殊，解析的代码如下：

2.4.5.实现搜索框自动补全

查看前端页面，可以发现当我们在输入框键入时，前端会发起ajax请求：

返回值是补全词条的集合，类型为List<String>

1）在cn.itcast.hotel.web包下的HotelController中添加新接口，接收新的请求：

@GetMapping("suggestion")
public List<String> getSuggestions(@RequestParam("key") String prefix) {
    return hotelService.getSuggestions(prefix);
}

2）在cn.itcast.hotel.service包下的IhotelService中添加方法：

1	List<String> getSuggestions(String prefix);

3）在cn.itcast.hotel.service.impl.HotelService中实现该方法：

@Override
public List<String> getSuggestions(String prefix) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        request.source().suggest(new SuggestBuilder().addSuggestion(
            "suggestions",
            SuggestBuilders.completionSuggestion("suggestion")
            .prefix(prefix)
            .skipDuplicates(true)
            .size(10)
        ));
        // 3.发起请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析结果
        Suggest suggest = response.getSuggest();
        // 4.1.根据补全查询名称，获取补全结果
        CompletionSuggestion suggestions = suggest.getSuggestion("suggestions");
        // 4.2.获取options
        List<CompletionSuggestion.Entry.Option> options = suggestions.getOptions();
        // 4.3.遍历
        List<String> list = new ArrayList<>(options.size());
        for (CompletionSuggestion.Entry.Option option : options) {
            String text = option.getText().toString();
            list.add(text);
        }
        return list;
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

3.数据同步

elasticsearch中的酒店数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步。

3.1.思路分析

常见的数据同步方案有三种：

同步调用
异步通知
监听binlog

3.1.1.同步调用

方案一：同步调用

基本步骤如下：

hotel-demo对外提供接口，用来修改elasticsearch中的数据
酒店管理服务在完成数据库操作后，直接调用hotel-demo提供的接口，

3.1.2.异步通知

方案二：异步通知

流程如下：

hotel-admin对mysql数据库数据完成增、删、改后，发送MQ消息
hotel-demo监听MQ，接收到消息后完成elasticsearch数据修改

3.1.3.监听binlog

方案三：监听binlog

流程如下：

给mysql开启binlog功能
mysql完成增、删、改操作都会记录在binlog中
hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容

3.1.4.选择

方式一：同步调用

优点：实现简单，粗暴
缺点：业务耦合度高

方式二：异步通知

优点：低耦合，实现难度一般
缺点：依赖mq的可靠性

方式三：监听binlog

优点：完全解除服务间耦合
缺点：开启binlog增加数据库负担、实现复杂度高

3.2.实现数据同步

3.2.1.思路

利用课前资料提供的hotel-admin项目作为酒店管理的微服务。当酒店数据发生增、删、改时，要求对elasticsearch中数据也要完成相同操作。

步骤：

导入课前资料提供的hotel-admin项目，启动并测试酒店数据的CRUD
声明exchange、queue、RoutingKey
在hotel-admin中的增、删、改业务中完成消息发送
在hotel-demo中完成消息监听，并更新elasticsearch中数据
启动并测试数据同步功能

3.2.2.导入demo

导入课前资料提供的hotel-admin项目：

运行后，访问 http://localhost:8099

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

3.2.3.声明交换机、队列

MQ结构如图：

1）引入依赖

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

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

2）声明队列交换机名称

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

3）声明队列交换机

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

3.2.4.发送MQ消息

在hotel-admin中的增、删、改业务中分别发送MQ消息：

3.2.5.接收MQ消息

hotel-demo接收到MQ消息要做的事情包括：

新增消息：根据传递的hotel的id查询hotel信息，然后新增一条数据到索引库
删除消息：根据传递的hotel的id删除索引库中的一条数据

1）首先在hotel-demo的cn.itcast.hotel.service包下的IHotelService中新增新增、删除业务

1
2
3

void deleteById(Long id);

void insertById(Long id);

2）给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);
    }
}

3）编写监听器

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

4.集群

单机的elasticsearch做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。

海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点
单点故障问题：将分片数据在不同节点备份（replica ）

ES集群相关概念:

集群（cluster）：一组拥有共同的 cluster name 的节点。
节点（node) ：集群中的一个 Elasticearch 实例
分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中

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

此处，我们把数据分成3片：shard0、shard1、shard2
主分片（Primary shard）：相对于副本分片的定义。
副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

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

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

首先对数据分片，存储到不同节点
然后对每个分片进行备份，放到对方节点，完成互相备份

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

现在，每个分片都有1个备份，存储在3个节点：

node0：保存了分片0和1
node1：保存了分片0和2
node2：保存了分片1和2

4.1.搭建ES集群

参考课前资料的文档：

其中的第四章节：

4.2.集群脑裂问题

4.2.1.集群职责划分

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

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

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

master节点：对CPU要求高，但是内存要求第
data节点：对CPU和内存要求都高
coordinating节点：对网络带宽、CPU要求高

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

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

4.2.2.脑裂问题

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

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

此时，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个主节点，没有出现脑裂。

4.2.3.小结

master eligible节点的作用是什么？

参与集群选主
主节点可以管理集群状态、管理分片信息、处理创建和删除索引库的请求

data节点的作用是什么？

数据的CRUD

coordinator节点的作用是什么？

路由请求到其它节点
合并查询到的结果，返回给用户

4.3.集群分布式存储

当新增文档时，应该保存到不同分片，保证数据均衡，那么coordinating node如何确定数据该存储到哪个分片呢？

4.3.1.分片存储测试

插入三条数据：

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

结果：

4.3.2.分片存储原理

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节点

4.4.集群分布式查询

elasticsearch的查询分成两个阶段：

scatter phase：分散阶段，coordinating node会把请求分发到每一个分片
gather phase：聚集阶段，coordinating node汇总data node的搜索结果，并处理为最终结果集返回给用户

4.5.集群故障转移

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

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

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

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

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

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

3月
05

2-Elasticsearch

微服务,Elasticsearch

分布式搜索引擎02

在昨天的学习中，我们已经导入了大量数据到elasticsearch中，实现了elasticsearch的数据存储功能。但elasticsearch最擅长的还是搜索和数据分析。

所以今天，我们研究下elasticsearch的数据搜索功能。我们会分别使用DSL和RestClient实现搜索。

0.学习目标

1.DSL查询文档

elasticsearch的查询依然是基于JSON风格的DSL来实现的。

1.1.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": {
    }
  }
}

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

1.2.全文检索查询

1.2.1.使用场景

全文检索查询的基本流程如下：

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

比较常用的场景包括：

商城的输入框搜索
百度输入框搜索

例如京东：

因为是拿着词条去匹配，因此参与搜索的字段也必须是可分词的text类型的字段。

1.2.2.基本语法

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

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

match查询语法如下：

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

mulit_match语法如下：

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

1.2.3.示例

match查询示例：

multi_match查询示例：

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

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

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

1.2.4.总结

match和multi_match的区别是什么？

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

1.3.精准查询

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

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

1.3.1.term查询

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

语法说明：

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

示例：

当我搜索的是精确词条时，能正确查询出结果：

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

1.3.2.range查询

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

基本语法：

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

示例：

1.3.3.总结

精确查询常见的有哪些？

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

1.4.地理坐标查询

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

常见的使用场景包括：

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

附近的酒店：

附近的车：

1.4.1.矩形范围查询

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

DKV9HZbVS6

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

语法如下：

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

这种并不符合“附近的人”这样的需求，所以我们就不做了。

1.4.2.附近查询

附近查询，也叫做距离查询（geo_distance）：查询到指定中心点小于某个距离值的所有文档。

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

vZrdKAh19C

语法说明：

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

示例：

我们先搜索陆家嘴附近15km的酒店：

发现共有47家酒店。

然后把半径缩短到3公里：

可以发现，搜索到的酒店数量减少到了5家。

1.5.复合查询

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

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

1.5.1.相关性算分

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

例如，我们搜索 “虹桥如家”，结果如下：

[
  {
    "_score" : 17.850193,
    "_source" : {
      "name" : "虹桥如家酒店真不错",
    }
  },
  {
    "_score" : 12.259849,
    "_source" : {
      "name" : "外滩如家酒店真不错",
    }
  },
  {
    "_score" : 11.91091,
    "_source" : {
      "name" : "迪士尼如家酒店真不错",
    }
  }
]

在elasticsearch中，早期使用的打分算法是TF-IDF算法，公式如下：

在后来的5.1版本升级中，elasticsearch将算法改进为BM25算法，公式如下：

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

小结：elasticsearch会根据词条和文档的相关度做打分，算法由两种：

TF-IDF算法
BM25算法，elasticsearch5.1版本后采用的算法

1.5.2.算分函数查询

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

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

要想认为控制相关性算分，就需要利用elasticsearch中的function score 查询了。

1）语法说明

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）基于运算模式做运算，得到最终结果，作为相关性算分。

因此，其中的关键点是：

过滤条件：决定哪些文档的算分被修改
算分函数：决定函数算分的算法
运算模式：决定最终算分结果

2）示例

需求：给“如家”这个品牌的酒店排名靠前一些

翻译一下这个需求，转换为之前说的四个要点：

原始条件：不确定，可以任意变化
过滤条件：brand = “如家”
算分函数：可以简单粗暴，直接给固定的算分结果，weight
运算模式：比如求和

因此最终的DSL语句如下：

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

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

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

3）小结

function score query定义的三要素是什么？

过滤条件：哪些文档要加分
算分函数：如何计算function score
加权方式：function score 与 query score如何运算

1.5.3.布尔查询

布尔查询是一个或多个查询子句的组合，每一个子句就是一个子查询。子查询的组合方式有：

must：必须匹配每个子查询，类似“与”
should：选择性匹配子查询，类似“或”
must_not：必须不匹配，不参与算分，类似“非”
filter：必须匹配，不参与算分

比如在搜索酒店时，除了关键字搜索外，我们还可能根据品牌、价格、城市等字段做过滤：

每一个不同的字段，其查询的条件、方式都不一样，必须是多个不同的查询，而要组合这些查询，就必须用bool查询了。

需要注意的是，搜索时，参与**打分的字段越多，查询的性能也越差**。因此这种多条件查询时，建议这样做：

搜索框的关键字搜索，是全文检索查询，使用must查询，参与算分
其它过滤条件，采用filter查询。不参与算分

1）语法示例：

GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {"term": {"city": "上海" }}
      ],
      "should": [
        {"term": {"brand": "皇冠假日" }},
        {"term": {"brand": "华美达" }}
      ],
      "must_not": [
        { "range": { "price": { "lte": 500 } }}
      ],
      "filter": [
        { "range": {"score": { "gte": 45 } }}
      ]
    }
  }
}

2）示例

需求：搜索名字包含“如家”，价格不高于400，在坐标31.21,121.5周围10km范围内的酒店。

分析：

名称搜索，属于全文检索查询，应该参与算分。放到must中
价格不高于400，用range查询，属于过滤条件，不参与算分。放到must_not中
周围10km范围内，用geo_distance查询，属于过滤条件，不参与算分。放到filter中

3）小结

bool查询有几种逻辑关系？

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

2.搜索结果处理

搜索的结果可以按照用户指定的方式去处理或展示。

2.1.排序

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

2.1.1.普通字段排序

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

语法：

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

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

示例：

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

2.1.2.地理坐标排序

地理坐标排序略有不同。

语法说明：

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "_geo_distance" : {
          "FIELD" : "纬度，经度", // 文档中geo_point类型的字段名、目标坐标点
          "order" : "asc", // 排序方式
          "unit" : "km" // 排序的距离单位
      }
    }
  ]
}

这个查询的含义是：

指定一个坐标，作为目标点
计算每一个文档中，指定字段（必须是geo_point类型）的坐标到目标点的距离是多少
根据距离排序

示例：

需求描述：实现对酒店数据按照到你的位置坐标的距离升序排序

提示：获取你的位置的经纬度的方式：https://lbs.amap.com/demo/jsapi-v2/example/map/click-to-get-lnglat/

假设我的位置是：31.034661，121.612282，寻找我周围距离最近的酒店。

2.2.分页

elasticsearch 默认情况下只返回top10的数据。而如果要查询更多数据就需要修改分页参数了。elasticsearch中通过修改from、size参数来控制要返回的分页结果：

from：从第几个文档开始
size：总共查询几个文档

类似于mysql中的limit ?, ?

2.2.1.基本的分页

分页的基本语法如下：

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 0, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}

2.2.2.深度分页问题

现在，我要查询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形成快照，保存在内存。官方已经不推荐使用。

2.2.3.小结

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

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

2.3.高亮

2.3.1.高亮原理

什么是高亮显示呢？

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

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

1）给文档中的所有关键字都添加一个标签，例如<em>标签
2）页面给<em>标签编写CSS样式

2.3.2.实现高亮

高亮的语法：

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

注意：

高亮是对关键字高亮，因此搜索条件必须带有关键字，而不能是范围这样的查询。
默认情况下，高亮的字段，必须与搜索指定的字段一致，否则无法高亮
如果要对非搜索字段高亮，则需要添加一个属性：required_field_match=false

示例：

2.4.总结

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

query：查询条件
from和size：分页条件
sort：排序条件
highlight：高亮条件

示例：

3.RestClient查询文档

文档的查询同样适用前面学习的 RestHighLevelClient对象，基本步骤包括：

1）准备Request对象
2）准备请求参数
3）发起请求
4）解析响应

3.1.快速入门

我们以match_all查询为例

3.1.1.发起查询请求

代码解读：

第一步，创建SearchRequest对象，指定索引库名
第二步，利用request.source()构建DSL，DSL中可以包含查询、分页、排序、高亮等
- query()：代表查询条件，利用QueryBuilders.matchAllQuery()构建一个match_all查询的DSL
第三步，利用client.search()发送请求，得到响应

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

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

3.1.2.解析响应

响应结果的解析：

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文档数据

3.1.3.完整代码

完整代码如下：

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

3.1.4.小结

查询的基本步骤是：

创建SearchRequest对象
准备Request.source()，也就是DSL。

① QueryBuilders来构建查询条件

② 传入Request.source() 的 query() 方法
发送请求，得到结果
解析结果（参考JSON结果，从外到内，逐层解析）

3.2.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);

}

3.3.精确查询

精确查询主要是两者：

term：词条精确匹配
range：范围查询

与之前的查询相比，差异同样在查询条件，其它都一样。

查询条件构造的API如下：

3.4.布尔查询

布尔查询是用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);

}

3.5.排序、分页

搜索结果的排序和分页是与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);

}

3.6.高亮

高亮的代码与之前代码差异较大，有两点：

查询的DSL：其中除了查询条件，还需要添加高亮条件，同样是与query同级。
结果解析：结果除了要解析_source文档数据，还要解析高亮结果

3.6.1.高亮请求构建

高亮请求的构建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);

}

3.6.2.高亮结果解析

高亮的结果与查询的文档结果默认是分离的，并不在一起。

因此解析高亮的代码需要额外处理：

代码解读：

第一步：从结果中获取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);
    }
}

4.黑马旅游案例

下面，我们通过黑马旅游的案例来实战演练下之前学习的知识。

我们实现四部分功能：

酒店搜索和分页
酒店结果过滤
我周边的酒店
酒店竞价排名

启动我们提供的hotel-demo项目，其默认端口是8089，访问http://localhost:8090，就能看到项目页面了：

4.1.酒店搜索和分页

案例需求：实现黑马旅游的酒店搜索功能，完成关键字搜索和分页

4.1.1.需求分析

在项目的首页，有一个大大的搜索框，还有分页按钮：

点击搜索按钮，可以看到浏览器控制台发出了请求：

请求参数如下：

由此可以知道，我们这个请求的信息如下：

请求方式：POST
请求路径：/hotel/list
请求参数：JSON对象，包含4个字段：
- key：搜索关键字
- page：页码
- size：每页大小
- sortBy：排序，目前暂不实现
返回值：分页查询，需要返回分页结果PageResult，包含两个属性：
- total：总条数
- List<HotelDoc>：当前页的数据

因此，我们实现业务的流程如下：

步骤一：定义实体类，接收请求参数的JSON对象
步骤二：编写controller，接收页面的请求
步骤三：编写业务实现，利用RestHighLevelClient实现搜索、分页

4.1.2.定义实体类

实体类有两个，一个是前端的请求参数实体，一个是服务端应该返回的响应结果实体。

1）请求参数

前端请求的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;
    }
}

4.1.3.定义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);
    }
}

4.1.4.实现搜索业务

我们在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);
}

4.2.酒店结果过滤

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

4.2.1.需求分析

在页面搜索框下面，会有一些过滤项：

传递的参数如图：

包含的过滤条件有：

brand：品牌值
city：城市
minPrice~maxPrice：价格范围
starName：星级

我们需要做两件事情：

修改请求参数的对象RequestParams，接收上述参数
修改业务逻辑，在搜索条件之外，添加一些过滤条件

4.2.2.修改实体类

修改在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;
}

4.2.3.修改搜索业务

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

4.3.我周边的酒店

需求：我附近的酒店

4.3.1.需求分析

在酒店列表页的右侧，有一个小地图，点击地图的定位按钮，地图会找到你所在的位置：

并且，在前端会发起查询请求，将你的坐标发送到服务端：

我们要做的事情就是基于这个location坐标，然后按照距离对周围酒店排序。实现思路如下：

修改RequestParams参数，接收location字段
修改search方法业务逻辑，如果location有值，添加根据geo_distance排序的功能

4.3.2.修改实体类

修改在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;
}

4.3.3.距离排序API

我们以前学习过排序功能，包括两种：

普通字段排序
地理坐标排序

我们只讲了普通字段排序对应的java写法。地理坐标排序只学过DSL语法，如下：

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "price": "asc"  
    },
    {
      "_geo_distance" : {
          "FIELD" : "纬度，经度",
          "order" : "asc",
          "unit" : "km"
      }
    }
  ]
}

对应的java代码示例：

4.3.4.添加距离排序

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

4.3.5.排序距离显示

重启服务后，测试我的酒店功能：

发现确实可以实现对我附近酒店的排序，不过并没有看到酒店到底距离我多远，这该怎么办？

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

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

我们要做两件事：

修改HotelDoc，添加排序距离字段，用于页面显示
修改HotelService类中的handleResponse方法，添加对sort值的获取

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

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;
    // 排序时的 距离值
    private Object distance;

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

2）修改HotelService中的handleResponse方法

重启后测试，发现页面能成功显示距离了：

4.4.酒店竞价排名

需求：让指定的酒店在搜索结果中排名置顶

4.4.1.需求分析

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

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

那怎样才能让指定的酒店排名置顶呢？

我们之前学习过的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的酒店增加权重

4.4.2.修改HotelDoc实体

给cn.itcast.hotel.pojo包下的HotelDoc类添加isAD字段：

4.4.3.添加广告标记

接下来，我们挑几个酒店，添加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
    }
}

4.4.4.添加算分函数查询

接下来我们就要修改查询条件了。之前是用的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);
}

3月
05

Elasticsearch摘要笔记

面试题,Elasticsearch

1、Elasticsearch是什么

1.1 概念:

Elasticsearch是由 Java语言开发基于Lucene的一款开源的搜索、聚合分析和存储引擎。同时它也可以称作是一种非关系型文档数据库。

ES可以替代MySQL吗？

ElasticSearch和MySql分工不同，MySQL负责存储数据，ElasticSearch负责搜索数据

MySQL有事务性，而ElasticSearch没有事务性，所以你删了的数据是无法恢复的。
ElasticSearch没有物理外键这个特性，如果你的数据强一致性要求比较高还是建议慎用

1.2特点

天生分布式、高性能（PB数据下可以秒读）、高可用、易扩展、易维护
跨语言、跨平台:几乎支持所有主流编程语言，并且支持在“Linux、Windows、MacOs”多平台部署
支持结构化、非结构化、地理位置搜索等

1.3适用场景

海量数据的全文检索，搜索引擎、垂直搜索、站内搜索:
- 百度、知乎、微博、CSDN
- 导航、外卖、团购等软件
- 以京东、淘宝为代表的垂直搜索
- B站、抖音、爱奇艺、QQ音乐等音视频软件Glthub
数据分析和聚合查询.
日志系统 : ELK

Elasticsearch核心概念

MySQL数据库查询存在的问题：

ES的倒排索引

Elasticsearch数据的存储和搜索原理

1. 解决性能低问题：

如果倒排索引中tearm词条太多不会导致一样要遍历很久吗？不会

因为ES生成的到排序索引中，词条会排序，形成一颗树形结构，提升词条的查询速度。

2. 解决功能弱问题：

ES会先对查询关键字进行分词，再进行查询。

3月
04

Netty面试题

面试题

1 基本概念

1、什么是 Netty？

Netty 是由 JBOSS 提供的一个 Java 开源框架。Netty 提供异步的、基于事件驱动的网络应用程序框架，用以快速开发高性能、高可靠性的网络 IO 程序,是目前最流行的 NIO 框架，Netty 在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，知名的 Elasticsearch 、Dubbo 框架内部都采用了 Netty。

2、Netty 的优势？

使用简单：封闭了 Java 原生 NIO 类库繁琐的 API，使用起来更加高效；
功能强大：预置多种编码能力，支持多种主流协议。同时通过 ChannelHandler 可以进行灵活的拓展，支持很强的定制能力；
高性能：与其它业界主流 NIO 框架相比，Netty 综合更优。主要体现在吞吐量更高、延迟更低、减少资源消耗以及最小化不必要的内存复制；
社区活跃与稳定：版本更新周期短，BUG 修复速度快，让开发者可以专注业务本身。

3、Netty 有什么特点？

高并发：Netty 是一款基于 NIO（Nonblocking I/O，非阻塞IO）开发的网络通信框架。
传输快：Netty 使用零拷贝特性，尽量减少不必要的内存拷贝，实现更快的传输效率。
封装好：Netty 封装了 NIO 操作的很多细节，提供易于使用的 API。

4、Netty 有哪些应用场景？

理论上来说，NIO 可以做的事情，Netty 都可以做并且更好。Netty 主要用来做网络通信：

RPC 框架的网络通信工具；
实现一个 HTTP 服务器；
实现一个即时通讯系统；
实现消息推送系统。

5、Netty 的高性能体现在？

IO 线程模型：同步非阻塞；
零拷贝：尽量做到不必要的内存拷贝：
内存池设计：使用直接内存，并且可重复利用；
串行化处理读写：避免使用锁带来的额外开销；
高性能序列化协议：支持 protobuf 等高性能序列化协议。

6、相比原生 NIO 的优势？

1）易用性：Netty 在 NIO 基础上封装了更加人性化的 API，大大降低开发人员的学习成本，同时还提供了很多开箱即用的工具。

2）稳定性：Netty 修复了 Java NIO 较多已知问题，如 select 空转导致 CPU 100%，TCP 断线重连，Keep-alive 检测等问题。

3）高性能：对象池复用（通过对象复用避免频繁创建和销毁带来的开销）和零拷贝技术。

7、Netty 和 Tomcat 的区别？

Netty 和 Tomcat 最大的区别在于对通信协议的支持：

Tomcat 是基于 Http 协议的，本质是一个基于 http 协议的 web 容器，而 Netty 不仅支持 HTTP，还能通过编程自定义各种协议，通过 codec 自定义编码/解码字节流，完成数据传输。
Tomcat 需要遵循 Servlet 规范（HTTP 协议的请求-响应模型），而 Netty 不需要受到 Servlet 规范约束，可以发挥 NIO 最大特性。

8、BIO. NIO. AIO 分别是什么？

BIO（同步阻塞 IO）
服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。BIO 方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK 1.4 以前的唯一选择，但程序直观简单易理解。
NIO（同步非阻塞 IO）
服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 IO 请求时才启动一个线程进行处理。NIO 方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK 1.4 开始支持。
AIO（异步非阻塞 IO）
服务器实现模式为一个有效请求一个线程，客户端的 IO 请求都是由 OS 先完成了再通知服务器应用去启动线程进行处理。 AIO 方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用 OS 参与并发操作，编程比较复杂，JDK 1.7 开始支持。

9、Select、Poll、Epoll 的区别？

ref

10、什么是 Reactor 模型？

2 架构组件

1、Netty 有哪些核心组件？

Channel
基础的 IO 操作，如绑定、连接、读写等都依赖于底层网络传输所提供的原语，在 Java 的网络编程中，基础核心类是 Socket，而 Netty 的 Channel 提供了一组 API，极大地简化了直接与 Socket 进行操作的复杂性，并且 Channel 是很多类的父类，如 EmbeddedChannel、LocalServerChannel、NioDatagramChannel、NioSctpChannel、NioSocketChannel 等。
EventLoop
EventLoop 定义了处理在连接过程中发生的事件的核心抽象。

说白了，EventLoop 的主要作用实际就是负责监听网络事件并调用事件处理器进行相关 IO 操作的处理。

那 Channel 和 EventLoop 直接有啥联系呢？

Channel 为 Netty 网络操作（读写等操作）抽象类，EventLoop 负责处理注册到其上的 Channel 处理 IO 操作，两者配合参与 IO 操作。

ChannelFuture
- 由于 Netty 是异步非阻塞的，所有的 IO 操作也都为异步的，我们不能立刻得到操作是否执行成功，因此 Netty 提供 ChannelFuture 接口，使用其 addListener() 方法注册一个 ChannelFutureListener，当操作执行成功或者失败时，监听就会自动触发返回结果。
- 并且，我们还可以通过 ChannelFuture 的 channel() 方法获取关联的Channel，甚至使用 sync() 方法让异步的操作变成同步的。
ChannelHandler 和 ChannelPipeline
- 从应用开发者看来，ChannelHandler 是最重要的组件，其中存放用来处理进站和出站数据的用户逻辑。ChannelHandler 的方法被网络事件触发，可以用于几乎任何类型的操作，如将数据从一种格式转换为另一种格式或处理抛出的异常。如其子接口ChannelInboundHandler，接受进站的事件和数据以便被用户定义的逻辑处理，或者当响应所连接的客户端时刷新ChannelInboundHandler的数据。
- ChannelPipeline为ChannelHandler 链提供了一个容器并定义了用于沿着链传播入站和出站事件流的 API。当创建 Channel 时，会自动创建一个附属的 ChannelPipeline。
Bootstrap 和 ServerBootstrap
Netty 的引导类应用程序网络层配置提供容器，其涉及将进程绑定到给定端口或连接一个进程到在指定主机上指定端口上运行的另一进程。引导类分为客户端引导 Bootstrap 和服务端引导 ServerBootstrap。

2、什么是 EventLoop 和 EventLoopGroup？

EventLoopGroup 包含多个 EventLoop（每一个 EventLoop 通常内部包含一个线程），上面我们已经说了 EventLoop 的主要作用实际就是负责监听网络事件并调用事件处理器进行相关 I/O 操作的处理。

并且 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理，即 Thread 和 EventLoop 属于 1 : 1 的关系，从而保证线程安全。

上图是一个服务端对 EventLoopGroup 使用的大致模块图，其中 Boss EventloopGroup 用于接收连接，Worker EventloopGroup 用于具体的处理（消息的读写以及其他逻辑处理）。

从上图可以看出：当客户端通过 connect 方法连接服务端时，bossGroup 处理客户端连接请求。当客户端处理完成后，会将这个连接提交给 workerGroup 来处理，然后 workerGroup 负责处理其 IO 相关操作。

3、说说 Netty 的线程模型？

Netty 通过 Reactor 模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss 线程池和 work 线程池，其中 boss 线程池的线程负责处理请求的 accept 事件，当接收到 accept 事件的请求时，把对应的 socket 封装到一个 NioSocketChannel 中，并交给 work 线程池，其中 work 线程池负责请求的 read 和 write 事件，由对应的 Handler 处理。

单线程模型
所有 IO 操作都由一个线程完成，即多路复用、事件分发和处理都是在一个 Reactor 线程上完成的。既要接收客户端的连接请求，向服务端发起连接，又要发送、读取请求或应答、响应消息。一个 NIO 线程同时处理成百上千的链路，性能上无法支撑，速度慢，若线程进入死循环，整个程序不可用，对于高负载、高并发的应用场景不合适。

//1.eventGroup既用于处理客户端连接，又负责具体的处理。 
EventLoopGroup eventGroup = new NioEventLoopGroup(1); 
//2.创建服务端启动引导/辅助类：
ServerBootstrap ServerBootstrap b = new ServerBootstrap(); 
boobtstrap.group(eventGroup, eventGroup) 
//......

多线程模型
有一个 NIO 线程（Acceptor）只负责监听服务端，接收客户端的 TCP 连接请求；NIO 线程池负责网络 IO 的操作，即消息的读取、解码、编码和发送；1 个 NIO 线程可以同时处理 N 条链路，但是 1 个链路只对应 1 个 NIO 线程，这是为了防止发生并发操作问题。但在并发百万客户端连接或需要安全认证时，一个 Acceptor 线程可能会存在性能不足问题。

在这里插入图片描述

对于代码：

// 1.bossGroup 用于接收连接，workerGroup 用于具体的处理
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try { 
    //2.创建服务端启动引导/辅助类：
    ServerBootstrap ServerBootstrap b = new ServerBootstrap(); 
    //3.给引导类配置两大线程组,确定了线程模型 
    b.group(bossGroup, workerGroup) 
    //......
}

主从多线程模型
Acceptor 线程用于绑定监听端口，接收客户端连接，将 SocketChannel 从主线程池的 Reactor 线程的多路复用器上移除，重新注册到 Sub 线程池的线程上，用于处理 IO 的读写等操作，从而保证主 Reactor 只负责接入认证、握手等操作。如果多线程模型无法满足你的需求的时候，可以考虑使用主从多线程模型。

在这里插入图片描述

// 1.bossGroup 用于接收连接，workerGroup 用于具体的处理
EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();
try { 
    //2.创建服务端启动引导/辅助类：
    ServerBootstrap ServerBootstrap b = new ServerBootstrap(); 
    //3.给引导类配置两大线程组,确定了线程模型 
    b.group(bossGroup, workerGroup) 
    //......
}

4、Netty 服务端的启动过程？

先来看一段代码实现：

// 1.bossGroup 用于接收连接，workerGroup 用于具体的处理 
EventLoopGroup bossGroup = new NioEventLoopGroup(1); 
EventLoopGroup workerGroup = new NioEventLoopGroup(); 
try { 
    //2.创建服务端启动引导/辅助类：ServerBootstrap 
    ServerBootstrap b = new ServerBootstrap(); 
    //3.给引导类配置两大线程组,确定了线程模型 
    b.group(bossGroup, workerGroup)
    .handler(new LoggingHandler(LogLevel.INFO))  // (非必备)打印日志  
    .channel(NioServerSocketChannel.class) // 4.指定 IO 模型 
    .childHandler(new ChannelInitializer<SocketChannel>() {
         @Override 
         public void initChannel(SocketChannel ch) {
             ChannelPipeline p = ch.pipeline(); 
             //5.可以自定义客户端消息的业务处理逻辑 
             p.addLast(new HelloServerHandler()); 
        } 
    }); 
    // 6.绑定端口,调用 sync 方法阻塞知道绑定完成 
    ChannelFuture f = b.bind(port).sync();
    // 7.阻塞等待直到服务器Channel关闭(closeFuture()方法获取Channel 的CloseFuture对象,然后调用sync()方法) 
    f.channel().closeFuture().sync(); 
} finally { 
    //8.优雅关闭相关线程组资源 
    bossGroup.shutdownGracefully(); 
    workerGroup.shutdownGracefully(); 
}

3 具体实现

1、Netty 的无锁化体现在哪里？

Netty 采用了串行无锁化设计，在 IO 线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎 CPU 利用率不高，并发程度不够。但是，通过调整 NIO 线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。

在这里插入图片描述

Netty 的 NioEventLoop 读取到消息后，直接调用 ChannelPipeline 的 fireChannelRead（Object msg），只要用户不主动切换线程，一直会由 NioEventLoop 调用到用户的 handler，期间不进行线程切换，这种串行化处理方式避免了多线程操作导致的锁竞争，从性能角度看是最优的。

2、如何解决 JDK epoll 空轮询问题？

这个 BUG 是指 Java 的 NIO 在 Linux 下进行 selector.select() 时，本来如果轮询的结果为空并且不调用 wakeup 方法的话，这个 selector.select() 应该是一直阻塞的，但是 Java 却会打破阻塞，继续执行，导致程序无限空转，造成 CPU 使用率 100%。（这个问题只存在 Linux 是因为 Linux 的 NIO 是基于 epoll 实现的，而 Java 实现的 epoll 存在 BUG，windows 下 NIO 基于 poll 就不存在此问题）

Netty 的解决方案：

为 Selector 的 select 操作设置超时时间，同时定义可以跳出阻塞的四种情况：

有事件发生
wakeup
超时
空轮询 BUG

而前两种返回值不为 0，可以跳出循环，超时有时间戳记录，所以每次空轮询，有专门的计数器进行 +1，如果空轮询的次数超过了 512 次（默认），就认为其触发了空轮询 BUG。

当触发 BUG 后，Netty 直接重建一个 Selector，将原来的 Channel 重新注册到新的 Selector 上，并将旧的 Selector 关掉。

3、什么是拆包和粘包？

TCP 是一个面向流的传输协议，所谓流，就是没有界限的一串数据。TCP 底层并不了解上层业务数据的具体含义，它会根据 TCP 缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被 TCP 拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的 TCP 粘包和拆包问题。

粘包和拆包是 TCP 网络编程中不可避免的，无论是服务端还是客户端，当我们读取或者发送消息的时候，都需要考虑 TCP 底层的粘包/拆包机制。

在这里插入图片描述

数据从发送方到接收方需要经过操作系统的缓冲区，而造成粘包和拆包的主要原因就在这个缓冲区上。粘包可以理解为缓冲区数据堆积，导致多个请求数据粘在一起，而拆包可以理解为发送的数据大于缓冲区，进行拆分处理。

详细来说，造成粘包和拆包的原因主要有以下三个：

1）应用程序 write 写入的字节大小大于套接口发送缓冲区大小；

2）进行 MSS 大小的 TCP 分段；

3）以太网帧的 payload 大于 MTU 进行 IP 分片。

4、拆包粘包的解决方案？

由于底层的 TCP 无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议可以归纳出以下解决方案：

1）消息长度固定，累计读取到长度和为定长LEN的报文后，就认为读取到了一个完整的信息。

2）将特殊的分隔符作为消息的结束标志，如回车换行符。

3）通过在消息头中定义长度字段来标识消息的总长度。

5、Netty 如何解决拆包粘包？

相比粘包，拆包问题比较简单，用户可以自己定义自己的编码器进行处理，Netty 并没有提供相应的组件。对于粘包的问题，代码比较繁琐，Netty 提供了 4 种解码器来解决，分别如下：

固定长度的拆包器（FixedLengthFrameDecoder），每个应用层数据包的都拆分成都是固定长度的大小；
行拆包器（LineBasedFrameDecoder），每个应用层数据包都以换行符作为分隔符，进行分割拆分；
**分隔符拆包器(**DelimiterBasedFrameDecoder），每个应用层数据包，都通过自定义的分隔符，进行分割拆分；
基于数据包长度的拆包器（LengthFieldBasedFrameDecoder），将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度。

6、Netty 零拷贝体现在哪里？

Zero-copy 就是在操作数据时, 不需要将数据 buffer从一个内存区域拷贝到另一个内存区域。少了一次内存的拷贝，CPU 效率就得到的提升。

接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝；
提供了组合 Buffer 对象，可以聚合多个 ByteBuffer 对象，用户可以像操作一个 Buffer 那样方便的对组合 Buffer 进行操作；
文件传输采用了 transferTo 方法，它可以直接将文件缓冲区的数据发送到目标 Channel，避免了传统通过循环 write 方式导致的内存拷贝问题。

和操作系统上的零拷贝的区别？

Netty 的 Zero-copy 完全是在用户态（Java 应用层）的, 更多的偏向于优化数据操作。而在 OS 层面上的 Zero-copy 通常指避免在用户态（User-space）与内核态（Kernel-space）之间来回拷贝数据。

7、TCP 的长连接和短连接？

我们知道 TCP 在进行读写之前，server 与 client 之间必须提前建立一个连接。建立连接的过程，需要我们常说的三次握手，释放/关闭连接的话需要四次挥手。这个过程是比较消耗网络资源并且有时间延迟的。

所谓，短连接说的就是 server 端与 client 端建立连接之后，读写完成之后就关闭掉连接，如果下一次再要互相发送消息，就要重新连接。短连接的有点很明显，就是管理和实现都比较简单，缺点也很明显，每一次的读写都要建立连接必然会带来大量网络资源的消耗，并且连接的建立也需要耗费时间。

长连接说的就是 client 向 server 双方建立连接之后，即使 client 与 server 完成一次读写，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。长连接的可以省去较多的 TCP 建立和关闭的操作，降低对网络资源的依赖，节约时间。对于频繁请求资源的客户来说，非常适用长连接。

8、Netty 长连接、心跳机制了解么？

在 TCP 保持长连接的过程中，可能会出现断网等网络异常出现，异常发生的时候， client 与 server 之间如果没有交互的话，它们是无法发现对方已经掉线的。为了解决这个问题, 我们就需要引入心跳机制。

心跳机制的工作原理是: 在 client 与 server 之间在一定时间内没有数据交互（即处于 idle 状态）时, 客户端或服务器就会发送一个特殊的数据包给对方, 当接收方收到这个数据报文后, 也立即发送一个特殊的数据报文, 回应发送方, 此即一个 PING-PONG 交互。所以, 当某一端收到心跳消息后, 就知道了对方仍然在线, 这就确保 TCP 连接的有效性。

TCP 实际上自带的就有长连接选项，本身是也有心跳包机制，也就是 TCP 的选项：SO_KEEPALIVE。但 TCP 协议层面的长连接灵活性不够，所以，一般情况下我们都是在应用层协议上实现自定义心跳机制的，也就是在 Netty 层面通过编码实现。通过 Netty 实现心跳机制的话，核心类是 IdleStateHandler 。

9、说说 Netty 的对象池技术？

对象池其实就是缓存一些对象从而避免大量创建同一个类型的对象，类似线程池的概念。对象池缓存了一些已经创建好的对象，避免需要时才创建对象，同时限制了实例的个数。池化技术最终要的就是重复的使用池内已经创建的对象。从上面的内容就可以看出对象池适用于以下几个场景：

创建对象的开销大；
会创建大量的实例；
限制一些资源的使用。

Netty 自己实现了一套轻量级的对象池。在 Netty 中，通常会有多个 IO 线程独立工作（基于 NioEventLoop 实现）。每个 IO 线程轮询单独的 Selector 实例来检索 IO 事件，并在 IO 来临时开始处理。最常见的 IO 操作就是读写，具体到 NIO 就是从内核缓冲区拷贝数据到用户缓冲区或者从用户缓冲区拷贝数据到内核缓冲区。这里会涉及到大量的创建和回收 Buffer， Netty 对 Buffer 进行了池化从而降低系统开销。

ref

10 有哪些序列化协议？

序列化（编码）是将对象序列化为二进制形式（字节数组），主要用于网络传输、数据持久化等；而反序列化（解码）则是将从网络、磁盘等读取的字节数组还原成原始对象，主要用于网络传输对象的解码，以便完成远程调用。

影响序列化性能的关键因素：序列化后的码流大小（网络带宽的占用）、序列化的性能（CPU资源占用）；是否支持跨语言（异构系统的对接和开发语言切换）。

目前几种主流协议

Java 默认提供的序列化
无法跨语言、序列化后的码流太大、序列化的性能差。
XML
优点是人机可读性好，可指定元素或特性的名称。缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。适用场景：当做配置文件存储数据，实时数据转换。
JSON
是一种轻量级的数据交换格式，优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好、与XML相比，其协议比较简单，解析速度比较快。缺点：数据的描述性比XML差、不适合性能要求为ms级别的情况、额外空间开销比较大。适用场景（可替代ＸＭＬ）：跨防火墙访问、可调式性要求高、基于Web browser的Ajax请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
Fastjson
采用一种“假定有序快速匹配”的算法。优点：接口简单易用、目前java语言中最快的json库。缺点：过于注重快，而偏离了“标准”及功能性、代码质量不高，文档不全。适用场景：协议交互、Web输出、Android客户端。
Thrift
不仅是序列化协议，还是一个RPC框架。优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。适用场景：分布式系统的RPC解决方案。
Avro
Hadoop的一个子项目，解决了JSON的冗长和没有IDL的问题。优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用RPC、支持跨编程语言实现。缺点：对于习惯于静态类型语言的用户不直观。适用场景：在Hadoop中做Hive、Pig和MapReduce的持久化数据格式。
Protobuf
将数据结构以.proto文件进行描述，通过代码生成工具可以生成对应数据结构的POJO对象和Protobuf相关的方法和属性。优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C++ 、python。适用场景：对性能要求高的RPC调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化。

3月
03

Spring Boot面试题

面试题

Spring Boot面试题（总结最全面的面试题！！！）

2020年04月13日

Java面试总结汇总，整理了包括Java重点知识，以及常用开源框架，欢迎大家阅读。文章可能有错误的地方，因为个人知识有限，欢迎各位大佬指出！文章持续更新中…

ID 标题地址

1 设计模式面试题（总结最全面的面试题） juejin.cn/post/684490…

2 Java基础知识面试题（总结最全面的面试题） juejin.cn/post/684490…

3 Java集合面试题（总结最全面的面试题） juejin.cn/post/684490…

4 JavaIO、BIO、NIO、AIO、Netty面试题（总结最全面的面试题） juejin.cn/post/684490…

5 Java并发编程面试题（总结最全面的面试题） juejin.cn/post/684490…

6 Java异常面试题（总结最全面的面试题） juejin.cn/post/684490…

7 Java虚拟机（JVM）面试题（总结最全面的面试题） juejin.cn/post/684490…

8 Spring面试题（总结最全面的面试题） juejin.cn/post/684490…

9 Spring MVC面试题（总结最全面的面试题） juejin.cn/post/684490…

10 Spring Boot面试题（总结最全面的面试题） juejin.cn/post/684490…

11 Spring Cloud面试题（总结最全面的面试题） juejin.cn/post/684490…

12 Redis面试题（总结最全面的面试题） juejin.cn/post/684490…

13 MyBatis面试题（总结最全面的面试题） juejin.cn/post/684490…

14 MySQL面试题（总结最全面的面试题） juejin.cn/post/684490…

15 TCP、UDP、Socket、HTTP面试题（总结最全面的面试题） juejin.cn/post/684490…

16 Nginx面试题（总结最全面的面试题） juejin.cn/post/684490…

17 ElasticSearch面试题

18 kafka面试题

19 RabbitMQ面试题（总结最全面的面试题） juejin.cn/post/684490…

20 Dubbo面试题（总结最全面的面试题） juejin.cn/post/684490…

21 ZooKeeper面试题（总结最全面的面试题） juejin.cn/post/684490…

22 Netty面试题（总结最全面的面试题）

23 Tomcat面试题（总结最全面的面试题） juejin.cn/post/684490…

24 Linux面试题（总结最全面的面试题） juejin.cn/post/684490…

25 互联网相关面试题（总结最全面的面试题）

26 互联网安全面试题（总结最全面的面试题）

什么是 Spring Boot？

Spring Boot 是 Spring 开源组织下的子项目，是 Spring 组件一站式解决方案，主要是简化了使用 Spring 的难度，简省了繁重的配置，提供了各种启动器，使开发者能快速上手。

为什么要用SpringBoot

快速开发，快速整合，配置简化、内嵌服务容器

SpringBoot与SpringCloud 区别

SpringBoot是快速开发的Spring框架，SpringCloud是完整的微服务框架，SpringCloud依赖于SpringBoot。

Spring Boot 有哪些优点？

Spring Boot 主要有如下优点：
1. 容易上手，提升开发效率，为 Spring 开发提供一个更快、更简单的开发框架。
2. 开箱即用，远离繁琐的配置。
3. 提供了一系列大型项目通用的非业务性功能，例如：内嵌服务器、安全管理、运行数据监控、运行状况检查和外部化配置等。
4. SpringBoot总结就是使编码变简单、配置变简单、部署变简单、监控变简单等等
5. 快速轻松地开发基于 Spring 的应用程序；
6. 无需部署war文件；
7. 创建独立应用程序的能力；
8. 帮助将 Tomcat、Jetty 或 Undertow 直接嵌入到应用程序中；
9. 无需XML配置；
10. 减少源代码数量；
11. 额外的开箱即用功能；
12. 轻松启动；
13. 简单的设置和管理；

Spring Boot 的核心注解是哪个？它主要由哪几个注解组成的？

启动类上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要组合包含了以下 3 个注解：
- @SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。
- @EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项，例如：java 如关闭数据源自动配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。
- @ComponentScan：Spring组件扫描。

Spring Boot 支持哪些日志框架？推荐和默认的日志框架是哪个？

Spring Boot 支持 Java Util Logging, Log4j2, Lockback 作为日志框架，如果你使用 Starters 启动器，Spring Boot 将使用 Logback 作为默认日志框架，但是不管是那种日志框架他都支持将配置文件输出到控制台或者文件中。

Spring Boot 中的 starter 到底是什么 ?

首先，这个 Starter 并非什么新的技术点，基本上还是基于 Spring 已有功能来实现的。首先它提供了一个自动化配置类，一般命名为 XXXAutoConfiguration ，在这个配置类中通过条件注解来决定一个配置是否生效（条件注解就是 Spring 中原本就有的），然后它还会提供一系列的默认配置，也允许开发者根据实际情况自定义相关配置，然后通过类型安全的属性(spring.factories)注入将这些配置属性注入进来，新注入的属性会代替掉默认属性。正因为如此，很多第三方框架，我们只需要引入依赖就可以直接使用了。当然，开发者也可以自定义 Starter

SpringBoot Starter的工作原理

我个人理解SpringBoot就是由各种Starter组合起来的，我们自己也可以开发Starter
在sprinBoot启动时由@SpringBootApplication注解会自动去maven中读取每个starter中的spring.factories文件,该文件里配置了所有需要被创建spring容器中的bean，并且进行自动配置把bean注入SpringContext中 //（SpringContext是Spring的配置文件）

Spring Boot 2.X 有什么新特性？与 1.X 有什么区别？

配置变更
JDK 版本升级
第三方类库升级
响应式 Spring 编程支持
HTTP/2 支持
配置属性绑定
更多改进与加强

SpringBoot支持什么前端模板，

thymeleaf，freemarker，jsp，官方不推荐JSP会有限制

SpringBoot的缺点

尽管 Spring Boot 有很多优点，但它仍然有一些缺点需要牢记：

由于不用自己做的配置，报错时很难定位。
缺乏控制。 Spring Boot 会创建大量未使用的依赖项，导致部署文件很大；
将遗留或现有 Spring 项目转换为 Spring Boot 应用程序的复杂且耗时的过程；
不适合大型项目。尽管它非常适合使用微服务，但许多开发人员声称 Spring Boot 不适合构建单体应用程序。

运行 Spring Boot 有哪几种方式？

打包用命令或者放到容器中运行
用 Maven/ Gradle 插件运行
直接执行 main 方法运行

Spring Boot 需要独立的容器运行吗？

可以不需要，内置了 Tomcat/ Jetty 等容器。

开启 Spring Boot 特性有哪几种方式？

1. 继承spring-boot-starter-parent项目

org.springframework.boot spring-boot-starter-parent 2.2.6.RELEASE

这个时候再导入我们需要的springboot starter时，就可以忽略版本号：

org.springframework.boot spring-boot-starter

2. 导入spring-boot-dependencies项目依赖

org.springframework.boot spring-boot-dependencies 1.5.4.RELEASE pom import

这个时候再导入我们需要的springboot starter时，就可以忽略版本号：

org.springframework.boot spring-boot-starter

SpringBoot 实现热部署有哪几种方式？

热部署就是可以不用重新运行SpringBoot项目可以实现操作后台代码自动更新到以运行的项目中
主要有两种方式：
- Spring Loaded
- Spring-boot-devtools

SpringBoot事务的使用

SpringBoot的事务很简单，首先使用注解@EnableTransactionManagement开启事务之后，然后在Service方法上添加注解@Transactional便可。

Async异步调用方法

在SpringBoot中使用异步调用是很简单的，只需要在方法上使用@Async注解即可实现方法的异步调用。注意：需要在启动类加入**@EnableAsync使异步调用@Async**注解生效。

如何在 Spring Boot 启动的时候运行一些特定的代码？

可以实现接口 ApplicationRunner 或者 CommandLineRunner，这两个接口实现方式一样，它们都只提供了一个 run 方法

1. ApplicationRunner

在项目中，可能会遇到这样一个问题：在项目启动完成之后，紧接着执行一段代码。
在SpringBoot中，提供了一个接口：ApplicationRunner。该接口中，只有一个run方法，他执行的时机是：spring容器启动完成之后，就会紧接着执行这个接口实现类的run方法。
实现了ApplicationRunner接口的类，并重写run方法，在springBoot项目启动后就是调用执行一次run方法

@Component
@Order(1)
public class TestImplApplicationRunner implements ApplicationRunner {
    @Override
    public void run(ApplicationArguments args) throws Exception {
    //do something
        System.out.println("测试ApplicationRunner接口1");

    }
}

@Component注解
这个实现类，要注入到spring容器中，这里使用了@Component注解；
在同一个项目中，可以定义多个ApplicationRunner的实现类，他们的执行顺序通过注解@Order注解或者再实现Ordered接口来实现。
run方法的参数：ApplicationArguments可以获取到当前项目执行的命令参数。（比如把这个项目打成jar执行的时候，带的参数可以通过ApplicationArguments获取到）；由于该方法是在容器启动完成之后，才执行的，所以，这里可以从spring容器中拿到其他已经注入的bean。
@Order注解
如果有多个实现类，而你需要他们按一定顺序执行的话，可以在实现类上加上@Order注解。@Order(value=整数值)。SpringBoot会按照@Order中的value值从小到大依次执行。
@order，使用注解方式使bean的加载顺序得到控制,@Order标记定义了组件的加载顺序，值越小拥有越高的优先级，可为负数。值越小，越先被加载。
@Order(-1)优先于@Order(0)
@Order(1)优先于@Order(2)

2. CommandLineRunner

背景

项目启动之前，预先加载数据。比如，权限容器、特殊用户数据等。通常我们可以使用监听器、事件来操作。但是，springboot提供了一个简单的方式来实现此类需求，即，CommandLineRunner。

先了解一下这个类

import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;

/**
 * Interface used to indicate that a bean should <em>run</em> when it is contained within
 * a {@link SpringApplication}. Multiple {@link CommandLineRunner} beans can be defined
 * within the same application context and can be ordered using the {@link Ordered}
 * interface or {@link Order @Order} annotation.
 * <p>
 * If you need access to {@link ApplicationArguments} instead of the raw String array
 * consider using {@link ApplicationRunner}.
 *
 * @author Dave Syer
 * @see ApplicationRunner
 */
@FunctionalInterface
public interface CommandLineRunner {

	/**
	 * Callback used to run the bean.
	 * @param args incoming main method arguments
	 * @throws Exception on error
	 */
	void run(String... args) throws Exception;

}

文档中，我们可以知道以下几点。

这是一个接口，用户可以自定义实现该接口，具体实现run方法
任何在上下文容器之内的bean都可以实现run方法
如果在上下文中，存在多个该接口实现类，可以通过@order注解，指定加载顺序

所以我们基本上大概已经了解了这个接口的作用以及用法。

案例说明
分别定义一个数据加载类MyStartupRunner1，排序为2；另一个数据加载类MyStartupRunner2,排序为1。看看它们记载数据的顺序。

@Component
@Order(value = 2)
public class MyStartupRunner1 implements CommandLineRunner{
   @Override
   public void run(String... strings) throws Exception {
       System.out.println(">>>>>>>>>>服务启动执行，执行加载数据等操作 MyStartupRunner1 order 2 <<<<");
    }
}

@Component
@Order(value = 1)
public class MyStartupRunner2 implements CommandLineRunner {
@Override
	public void run(String... strings) throws Exception {
   		System.out.println(">>>>服务启动执行，执行加载数据等操作 MyStartupRunner2 order 1 <<<<<<<");
   	}
}

Spring Boot 有哪几种读取配置的方式？

Spring Boot 可以通过 @PropertySource,@Value,@Environment, @ConfigurationPropertie注解来绑定变量

什么是 JavaConfig？

Spring JavaConfig 是 Spring 社区的产品，Spring 3.0引入了他，它提供了配置 Spring IOC 容器的纯Java 方法。因此它有助于避免使用 XML 配置。使用 JavaConfig 的优点在于：
- 面向对象的配置。由于配置被定义为 JavaConfig 中的类，因此用户可以充分利用 Java 中的面向对象功能。一个配置类可以继承另一个，重写它的@Bean 方法等。
- 减少或消除 XML 配置。基于依赖注入原则的外化配置的好处已被证明。但是，许多开发人员不希望在 XML 和 Java 之间来回切换。JavaConfig 为开发人员提供了一种纯 Java 方法来配置与 XML 配置概念相似的 Spring 容器。从技术角度来讲，只使用 JavaConfig 配置类来配置容器是可行的，但实际上很多人认为将JavaConfig 与 XML 混合匹配是理想的。
- 类型安全和重构友好。JavaConfig 提供了一种类型安全的方法来配置 Spring容器。由于 Java 5.0 对泛型的支持，现在可以按类型而不是按名称检索 bean，不需要任何强制转换或基于字符串的查找。
常用的Java config：
- @Configuration：在类上打上写下此注解，表示这个类是配置类
- @ComponentScan：在配置类上添加 @ComponentScan 注解。该注解默认会扫描该类所在的包下所有的配置类，相当于之前的 <context:component-scan >。
- @Bean：bean的注入：相当于以前的< bean id=“objectMapper” class=“org.codehaus.jackson.map.ObjectMapper” />
- @EnableWebMvc：相当于xml的<mvc:annotation-driven >
- @ImportResource：相当于xml的 < import resource=“applicationContext-cache.xml”>

SpringBoot的自动配置原理是什么

主要是Spring Boot的启动类上的核心注解SpringBootApplication注解主配置类，有了这个主配置类启动时就会为SpringBoot开启一个@EnableAutoConfiguration注解自动配置功能。
有了这个EnableAutoConfiguration的话就会：
1. 从配置文件META_INF/Spring.factories加载可能用到的自动配置类
2. 去重，并将exclude和excludeName属性携带的类排除
3. 过滤，将满足条件（@Conditional）的自动配置类返回

你如何理解 Spring Boot 配置加载顺序？

在 Spring Boot 里面，可以使用以下几种方式来加载配置。
- 1.properties文件；
- 2.YAML文件；
- 3.系统环境变量；
- 4.命令行参数；
- 等等……
常用配置文件中读取配置的结论：config配置中心 => jvm参数 => 系统环境变量 => 项目内的application-xxx.yaml => 项目内的application.yaml => bootstrap.yaml

什么是 YAML？

YAML 是一种人类可读的数据序列化语言。它通常用于配置文件。与属性文件相比，如果我们想要在配置文件中添加复杂的属性，YAML 文件就更加结构化，而且更少混淆。可以看出 YAML 具有分层配置数据。
YAML 的语法比较简洁直观，特点是使用空格来表达层次结构，其最大优势在于数据结构方面的表达，所以 YAML 更多应用于编写配置文件，其文件一般以 .yml 为后缀。

YAML 配置的优势在哪里 ?

YAML 现在可以算是非常流行的一种配置文件格式了，无论是前端还是后端，都可以见到 YAML 配置。那么 YAML 配置和传统的 properties 配置相比到底有哪些优势呢？
- 配置有序，在一些特殊的场景下，配置有序很关键
- 简洁明了，他还支持数组，数组中的元素可以是基本数据类型也可以是对象
- 相比 properties 配置文件，YAML 还有一个缺点，就是不支持 @PropertySource 注解导入自定义的 YAML 配置。

Spring Boot 是否可以使用 XML 配置 ?

Spring Boot 推荐使用 Java 配置而非 XML 配置，但是 Spring Boot 中也可以使用 XML 配置，通过 @ImportResource 注解可以引入一个 XML 配置。

spring boot 核心配置文件是什么？bootstrap.properties 和 application.properties 有何区别 ?

单纯做 Spring Boot 开发，可能不太容易遇到 bootstrap.properties 配置文件，但是在结合 Spring Cloud 时，这个配置就会经常遇到了，特别是在需要加载一些远程配置文件的时侯。
spring boot 核心的两个配置文件：
- bootstrap (. yml 或者 . properties)：boostrap 由父 ApplicationContext 加载的，比 applicaton 优先加载，配置在应用程序上下文的引导阶段生效。一般来说我们在 Spring Cloud 配置就会使用这个文件。且 boostrap 里面的属性不能被覆盖；
- application (. yml 或者 . properties)：由ApplicatonContext 加载，用于 spring boot 项目的自动化配置。

什么是 Spring Profiles？

在项目的开发中，有些配置文件在开发、测试或者生产等不同环境中可能是不同的，例如数据库连接、redis的配置等等。那我们如何在不同环境中自动实现配置的切换呢？Spring给我们提供了profiles机制给我们提供的就是来回切换配置文件的功能
Spring Profiles 允许用户根据配置文件（dev，test，prod 等）来注册 bean。因此，当应用程序在开发中运行时，只有某些 bean 可以加载，而在 PRODUCTION中，某些其他 bean 可以加载。假设我们的要求是 Swagger 文档仅适用于 QA 环境，并且禁用所有其他文档。这可以使用配置文件来完成。Spring Boot 使得使用配置文件非常简单。

SpringBoot多数据源拆分的思路

先在properties配置文件中配置两个数据源，创建分包mapper，使用@ConfigurationProperties读取properties中的配置，使用@MapperScan注册到对应的mapper包中

SpringBoot多数据源事务如何管理

第一种方式是在service层的@TransactionManager中使用transactionManager指定DataSourceConfig中配置的事务
第二种是使用jta-atomikos实现分布式事务管理

保护 Spring Boot 应用有哪些方法？

在生产中使用HTTPS
使用Snyk检查你的依赖关系
升级到最新版本
启用CSRF保护
使用内容安全策略防止XSS攻击

如何实现 Spring Boot 应用程序的安全性？

为了实现 Spring Boot 的安全性，我们使用 spring-boot-starter-security 依赖项，并且必须添加安全配置。它只需要很少的代码。配置类将必须扩展WebSecurityConfigurerAdapter 并覆盖其方法。

比较一下 Spring Security 和 Shiro 各自的优缺点 ?

由于 Spring Boot 官方提供了大量的非常方便的开箱即用的 Starter ，包括 Spring Security 的 Starter ，使得在 Spring Boot 中使用 Spring Security 变得更加容易，甚至只需要添加一个依赖就可以保护所有的接口，所以，如果是 Spring Boot 项目，一般选择 Spring Security 。当然这只是一个建议的组合，单纯从技术上来说，无论怎么组合，都是没有问题的。Shiro 和 Spring Security 相比，主要有如下一些特点：
- Spring Security 是一个重量级的安全管理框架；Shiro 则是一个轻量级的安全管理框架
- Spring Security 概念复杂，配置繁琐；Shiro 概念简单、配置简单
- Spring Security 功能强大；Shiro 功能简单

Spring Boot 中如何解决跨域问题 ?

跨域可以在前端通过 JSONP 来解决，但是 JSONP 只可以发送 GET 请求，无法发送其他类型的请求，在 RESTful 风格的应用中，就显得非常鸡肋，因此我们推荐在后端通过（CORS，Cross-origin resource sharing）来解决跨域问题。这种解决方案并非 Spring Boot 特有的，在传统的 SSM 框架中，就可以通过 CORS 来解决跨域问题，只不过之前我们是在 XML 文件中配置 CORS ，现在可以通过实现WebMvcConfigurer接口然后重写addCorsMappings方法解决跨域问题。

@Configuration
public class CorsConfig extends WebMvcConfigurerAdapter {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**") 		//可以被跨域的路径
            .allowedOrigins("*") 		//域名的白名单
            .allowedMethods("*")		/*"GET", "POST", "DELETE", "PUT"*/
            .allowedHeaders("*") 		//允许所有的请求header访问，可以自定义设置任意请求头信息
            .maxAge(3600); 				//这个复杂请求是预检用的，设置预检多久失效
    }
}

如何使用 Spring Boot 实现全局异常处理？

Spring 提供了一种使用 ControllerAdvice 处理异常的非常有用的方法。我们通过实现一个 ControlerAdvice 类，来处理控制器类抛出的所有异常。

@ControllerAdvice 作用

controller 的增强，用于对controller 做一些统一的操作，一般是用于全局的异常处理，也可以用于全局结果的返回处理

可以在一定程度上简化代码，减少代码的书写量，统一对所有结果和异常做处理，包括异常信息的返回和错误日志的答应等

@ControllerAdvice，是Spring3.2提供的新注解,它是一个Controller增强器,可对controller中被 @RequestMapping注解的方法加一些逻辑处理。主要作用有一下三种 :

通过@ControllerAdvice注解可以将对于控制器的全局配置放在同一个位置。
注解了@ControllerAdvice的类的方法可以使用@ExceptionHandler、@InitBinder、@ModelAttribute注解到方法上。
- @ExceptionHandler：用于全局处理控制器里的异常，进行全局异常处理
- @InitBinder：用来设置WebDataBinder，用于自动绑定前台请求参数到Model中，全局数据预处理。
- @ModelAttribute：本来作用是绑定键值对到Model中，此处让全局的@RequestMapping都能获得在此处设置的键值对，全局数据绑定。
@ControllerAdvice注解将作用在所有注解了@RequestMapping的控制器的方法上。

需要配合@ExceptionHandler使用。当将异常抛到controller时,可以对异常进行统一处理,规定返回的json格式或是跳转到一个错误页面

全局异常处理举例以及说明
@ControllerAdvice ，@ExceptionHandler 的全局处理

Slf4j 为日志注解

......
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;

@ControllerAdvice
@Slf4j
public class MyGlobalExceptionHandler {

	// 自定义异常
    @ResponseBody
    @ExceptionHandler(value = MyException.class)
    public Response<String> handle(HttpServletRequest request, MyException e) {
        log.error("错误信息:{}", e.getMessage(), e);
		return Response.failMessage(e.getCode(), e.getMessage());
    }
    
    // @Valid 校验框架抛出的特殊异常类
    @ResponseBody
    @ExceptionHandler(value = MethodArgumentNotValidException.class)
    public Response<String> handleValidException(HttpServletRequest request, MethodArgumentNotValidException e) {
        BindingResult bindingResult = e.getBindingResult();
        StringBuilder message = new StringBuilder();
        if (bindingResult.hasErrors()) {
            List<ObjectError> allErrors = bindingResult.getAllErrors();
            for (ObjectError allError : allErrors) {
                message.append(allError.getDefaultMessage()).append(", ");
            }
        }
        return Response.failMessage(message.toString());
    }

	// 默认其他的所有异常
    @ResponseBody
    @ExceptionHandler(value = Exception.class)
    public Response<String> handleOtherException(HttpServletRequest request, Exception e) {
        log.error("request error Exception:", e);
        return Response.failMessage(e.getMessage());
    }
}

Spring Boot 中的监视器是什么？

Spring boot actuator 是 spring 启动框架中的重要功能之一。Spring boot 监视器可帮助您访问生产环境中正在运行的应用程序的当前状态。有几个指标必须在生产环境中进行检查和监控。即使一些外部应用程序可能正在使用这些服务来向相关人员触发警报消息。监视器模块公开了一组可直接作为 HTTP URL 访问的REST 端点来检查状态。
Spring Boot自带监控组件—Actuator，它可以帮助实现对程序内部运行情况的监控。本章首先介绍Actuator轻松实现应用程序的监控治理，比如健康状况、审计、统计和HTTP追踪、Bean加载情况、环境变量、日志信息、线程信息等，然后介绍如何使用Spring Boot Admin构建完整的运维监控平台。
Actuator的核心是端点（Endpoint），它用来监视、提供应用程序的信息，Spring Boot提供的spring-boot-actuator组件中已经内置了非常多的Endpoint（health、info、beans、metrics、httptrace、shutdown等），每个端点都可以启用和禁用。

监控端点分类：
1）应用配置类：可以查看应用在运行期的静态信息，比如自动配置信息、加载的Spring Bean信息、YML文件配置信息、环境信息、请求映射信息。
2）度量指标类：主要是运行期的动态信息，如堆栈、请求连接、健康状态、系统性能等
3）操作控制类：主要是指shutdown，用户可以发送一个请求将应用的监控功能关闭。

我们如何监视所有 Spring Boot 微服务？

Spring Boot 提供 监视器端点 以监控各个微服务的度量。这些端点对于获取有关应用程序的信息（如它们是否已启动）以及它们的组件（如数据库等）是否正常运行很有帮助。但是，使用监视器的一个主要缺点或困难是，我们必须单独打开应用程序的知识点以了解其状态或健康状况。想象一下涉及 50 个应用程序的微服务，管理员将不得不击中所有 50 个应用程序的执行终端。为了帮助我们处理这种情况，我们将使用位于的开源项目。它建立在 Spring Boot Actuator 之上，它提供了一个 Web UI，使我们能够可视化多个应用程序的度量。

SpringBoot性能如何优化

如果项目比较大，类比较多，不使用@SpringBootApplication，采用@Compoment指定扫包范围
在项目启动时设置JVM初始内存和最大内存相同
将springboot内置服务器由tomcat设置为undertow

如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？Spring Boot项目如何热部署？

这可以使用 DEV 工具来实现。通过这种依赖关系，您可以节省任何更改，嵌入式tomcat 将重新启动。Spring Boot 有一个开发工具（DevTools）模块，它有助于提高开发人员的生产力。Java 开发人员面临的一个主要挑战是将文件更改自动部署到服务器并自动重启服务器。开发人员可以重新加载 Spring Boot 上的更改，而无需重新启动服务器。这将消除每次手动部署更改的需要。Spring Boot 在发布它的第一个版本时没有这个功能。这是开发人员最需要的功能。DevTools 模块完全满足开发人员的需求。该模块将在生产环境中被禁用。它还提供 H2 数据库控制台以更好地测试应用程序。

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

Spring Boot微服务中如何实现 session 共享 ?

在微服务中，一个完整的项目被拆分成多个不相同的独立的服务，各个服务独立部署在不同的服务器上，各自的 session 被从物理空间上隔离开了，但是经常，我们需要在不同微服务之间共享 session ，常见的方案就是 Spring Session + Redis 来实现 session 共享。将所有微服务的 session 统一保存在 Redis 上，当各个微服务对 session 有相关的读写操作时，都去操作 Redis 上的 session 。这样就实现了 session 共享，Spring Session 基于 Spring 中的代理过滤器实现，使得 session 的同步操作对开发人员而言是透明的，非常简便。

您使用了哪些 starter maven 依赖项？

使用了下面的一些依赖项
- spring-boot-starter-web 嵌入tomcat和web开发需要servlet与jsp支持
- spring-boot-starter-data-jpa 数据库支持
- spring-boot-starter-data-redis redis数据库支持
- spring-boot-starter-data-solr solr支持
- mybatis-spring-boot-starter 第三方的mybatis集成starter
- 自定义的starter(如果自己开发过就可以说出来)

Spring Boot 中如何实现定时任务 ?

在 Spring Boot 中使用定时任务主要有两种不同的方式，一个就是使用 Spring 中的 @Scheduled 注解，另一个则是使用第三方框架 Quartz。
使用 Spring 中的 @Scheduled 的方式主要通过 @Scheduled 注解来实现。

spring-boot-starter-parent 有什么用 ?

我们都知道，新创建一个 Spring Boot 项目，默认都是有 parent 的，这个 parent 就是 spring-boot-starter-parent ，spring-boot-starter-parent 主要有如下作用：
1. 定义了 Java 编译版本为 1.8 。
2. 使用 UTF-8 格式编码。
3. 继承自 spring-boot-dependencies，这个里边定义了依赖的版本，也正是因为继承了这个依赖，所以我们在写依赖时才不需要写版本号。看源码发现：
4. 执行打包操作的配置。
5. 自动化的资源过滤。
6. 自动化的插件配置。
7. 针对 application.properties 和 application.yml 的资源过滤，包括通过 profile 定义的不同环境的配置文件，例如 application-dev.properties 和 application-dev.yml。
总结就是打包用的

SpringBoot如何实现打包

进入项目目录在控制台输入mvn clean package，clean是清空已存在的项目包，package进行打包
或者点击右边选项栏中的Maven，先点击clean在点击package

Spring Boot 打成的 jar 和普通的 jar 有什么区别 ?

Spring Boot 项目最终打包成的 jar 是可执行 jar ，这种 jar 可以直接通过 java -jar xxx.jar 命令来运行，这种 jar 不可以作为普通的 jar 被其他项目依赖，即使依赖了也无法使用其中的类。
Spring Boot 的 jar 无法被其他项目依赖，主要还是他和普通 jar 的结构不同。普通的 jar 包，解压后直接就是包名，包里就是我们的代码，而 Spring Boot 打包成的可执行 jar 解压后，在 \BOOT-INF\classes 目录下才是我们的代码，因此无法被直接引用。如果非要引用，可以在 pom.xml 文件中增加配置，将 Spring Boot 项目打包成两个 jar ，一个可执行，一个可引用。

2月
26

Sentinel-限流规则(流控模式：直接、关联、链路)

微服务,Sentinel

QPS Queries Per Second 是每秒查询率 ,是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。

一、流控模式-直接

添加规则：

测试例子分析：

启动测试

点击 察看结果树

上面测试例子，到Sentinel控制台的实时监控可以看到

二、流控模式-关联

•关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

•使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

当**/write资源访问量触发阈值时，就会对/read**资源限流，避免影响/write资源。

案例：

需求：

•在OrderController新建两个端点：/order/query和/order/update，无需实现业务

•配置流控规则，当/order/update资源被访问的QPS超过5时，对/order/query请求限流

1. 编写测试controller方法:

2. 添加规则（想给谁限流，就给谁添加规则）

3. 借助JMeter进行测试：

4. 去网页访问验证:

query被限流

5. 总结：满足下面条件可以使用关联模式

两个有竞争关系的资源
一个优先级较高，一个优先级较低（优先级高的触发阈值时（本案例的order），对优先级低的限流（本案例的query））

三、流控模式-链路

案例：

1. 编写测试代码：

2. 注意：

Sentinel默认只标记Controller中的方法为资源，如果要标记其它方法，需要利用@SentinelResource注解

去配置文件里配置，关闭contextM，就可以让controller里的方法单独成为一个链路；不关闭context的话，controller里的方法都会默认进去sentinel默认的根链路里，这样就只有一条链路，无法流控链路模式

3. 启动之后，并到网页里分别访问了/order/query和/order/save接口后

4. 添加规则：(对query做限制，save没有做限制)

5. 借助JMeter来测试：

启动测试

2月
20

应用层常见协议总结（应用层）

面试题,计算机网络

HTTP:超文本传输协议

超文本传输协议（HTTP，HyperText Transfer Protocol) 主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的，整个过程如下图所示。

HTTP 协是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。

另外， HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。

# SMTP:简单邮件传输(发送)协议

简单邮件传输(发送)协议（SMTP，Simple Mail Transfer Protocol） 基于 TCP 协议，用来发送电子邮件。

注意⚠️：接受邮件的协议不是 SMTP 而是 POP3 协议。

SMTP 协议这块涉及的内容比较多，下面这两个问题比较重要：

电子邮件的发送过程
如何判断邮箱是真正存在的？

电子邮件的发送过程？

比如我的邮箱是“dabai@cszhinan.com”，我要向“xiaoma@qq.com”发送邮件，整个过程可以简单分为下面几步：

通过 SMTP 协议，我将我写好的邮件交给163邮箱服务器（邮局）。
163邮箱服务器发现我发送的邮箱是qq邮箱，然后它使用 SMTP协议将我的邮件转发到 qq邮箱服务器。
qq邮箱服务器接收邮件之后就通知邮箱为“xiaoma@qq.com”的用户来收邮件，然后用户就通过 POP3/IMAP 协议将邮件取出。

如何判断邮箱是真正存在的？

很多场景(比如邮件营销)下面我们需要判断我们要发送的邮箱地址是否真的存在，这个时候我们可以利用 SMTP 协议来检测：

查找邮箱域名对应的 SMTP 服务器地址
尝试与服务器建立连接
连接成功后尝试向需要验证的邮箱发送邮件
根据返回结果判定邮箱地址的真实性

推荐几个在线邮箱是否有效检测工具：

# POP3/IMAP:邮件接收的协议

这两个协议没必要多做阐述，只需要了解 POP3 和 IMAP 两者都是负责邮件接收的协议即可。另外，需要注意不要将这两者和 SMTP 协议搞混淆了。SMTP 协议只负责邮件的发送，真正负责接收的协议是POP3/IMAP。

IMAP 协议相比于POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。

# FTP:文件传输协议

FTP 协议 主要提供文件传输服务，基于 TCP 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽操作系统和文件存储方式。

FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP 服务器之间建立两个连接。如果我们要基于 FTP 协议开发一个文件传输的软件的话，首先需要搞清楚 FTP 的原理。关于 FTP 的原理，很多书籍上已经描述的非常详细了：

FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点就在于它在两台通信的主机之间使用了两条 TCP 连接（其它客户服务器应用程序一般只有一条 TCP 连接）：

控制连接：用于传送控制信息（命令和响应）

数据连接：用于数据传送；

这种将命令和数据分开传送的思想大大提高了 FTP 的效率。

# Telnet:远程登陆协议

Telnet 协议 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的非常安全的协议所取代的主要原因。

# SSH:安全的网络传输协议

SSH（ Secure Shell） 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH 建立在可靠的传输协议 TCP 之上。

Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。

2月
20

TCP 传输可靠性保障（传输层）

面试题,计算机网络

TCP 如何保证传输的可靠性？

基于数据块传输 ：应用数据被分割成 TCP 认为最适合发送的数据块，在传输给网络层，数据块被称为报文段或段。
对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
超时重传 : 当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。接收端实体对已成功收到的包发回一个相应的确认信息（ACK）。如果发送端实体在合理的往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失open in new window并进行重传。
流量控制 : TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的**滑动窗口协议（**TCP 利用滑动窗口实现流量控制）。
拥塞控制 : 当网络拥塞时，减少数据的发送。

# TCP 如何实现流量控制？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

为什么需要流量控制?

这是因为双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来。如果接收方处理不过来的话，就只能把处理不过来的数据存在 接收缓冲区(Receiving Buffers) 里（失序的数据包也会被存放在缓存区里）。如果缓存区满了发送方还在狂发数据的话，接收方只能把收到的数据包丢掉。出现丢包问题的同时又疯狂浪费着珍贵的网络资源。因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

这里需要注意的是（常见误区）：

发送端不等同于客户端
接收端不等同于服务端

TCP 为全双工(Full-Duplex, FDX)通信，双方可以进行双向通信，客户端和服务端既可能是发送端又可能是接收端。因此，两端各有一个发送缓冲区与接收缓冲区，两端都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。通信双方的发送窗口和接收窗口的要求相同

TCP 发送窗口可以划分成四个部分：

已经发送并且确认的TCP段（已经发送并确认）；
已经发送但是没有确认的TCP段（已经发送未确认）；
未发送但是接收方准备接收的TCP段（可以发送）；
未发送并且接收方也并未准备接受的TCP段（不可发送）。

TCP发送窗口结构图示：

SND.WND ：发送窗口。
SND.UNA：Send Unacknowledged 指针，指向发送窗口的第一个字节。
SND.NXT：Send Next 指针，指向可用窗口的第一个字节。

可用窗口大小 = SND.UNA + SND.WND - SND.NXT 。

TCP 接收窗口可以划分成三个部分：

已经接收并且已经确认的 TCP 段（已经接收并确认）；
等待接收且允许发送方发送 TCP 段（可以接收未确认）；
不可接收且不允许发送方发送TCP段（不可接收）。

TCP 接收窗口结构图示：

接收窗口的大小是根据接收端处理数据的速度动态调整的。 如果接收端读取数据快，接收窗口可能会扩大。否则，它可能会缩小。

另外，这里的滑动窗口大小只是为了演示使用，实际窗口大小通常会远远大于这个值。

# TCP 的拥塞控制是怎么实现的？

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.
快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

# ARQ 协议了解吗?（Automatic Repeat-reQuest）

自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认信息（Acknowledgements，就是我们常说的 ACK），它通常会重新发送，直到收到确认或者重试超过一定的次数。

ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

# 停止等待 ARQ 协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

1) 无差错情况:

发送方发送分组, 接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况（超时重传）:

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。

3) 确认丢失和确认迟到

确认丢失 ：确认消息在传输过程丢失。当 A 发送 M1 消息，B 收到后，B 向 A 发送了一个 M1 确认消息，但却在传输过程中丢失。而 A 并不知道，在超时计时过后，A 重传 M1 消息，B 再次收到该消息后采取以下两点措施：1. 丢弃这个重复的 M1 消息，不向上层交付。 2. 向 A 发送确认消息。（不会认为已经发送过了，就不再发送。A 能重传，就证明 B 的确认消息丢失）。
确认迟到 ：确认消息在传输过程中迟到。A 发送 M1 消息，B 收到并发送确认。在超时时间内没有收到确认消息，A 重传 M1 消息，B 仍然收到并继续发送确认消息（B 收到了 2 份 M1）。此时 A 收到了 B 第二次发送的确认消息。接着发送其他数据。过了一会，A 收到了 B 第一次发送的对 M1 的确认消息（A 也收到了 2 份确认消息）。处理如下：1. A 收到重复的确认后，直接丢弃。2. B 收到重复的 M1 后，也直接丢弃重复的 M1。

# 连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点：

信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点：

不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5 条消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

2月
19

OSI 和 TCP/IP 网络分层模型详解（基础）

面试题,计算机网络

OSI模型: 即开放式通信系统互联参考模型（Open System Interconnection Reference Model），是国际标准化组织（ISO）提出的一个试图使各种计算机在世界范围内互连为网络的标准框架，简称OSI。

OSI 七层模型

OSI 七层模型 是国际标准化组织a提出一个网络分层模型，其大体结构以及每一层提供的功能如下图所示：

每一层都专注做一件事情，并且每一层都需要使用下一层提供的功能比如传输层需要使用网络层提供的路由和寻址功能，这样传输层才知道把数据传输到哪里去。

OSI 的七层体系结构概念清楚，理论也很完整，但是它比较复杂而且不实用，而且有些功能在多个层中重复出现。

上面这种图可能比较抽象，再来一个比较生动的图片。下面这个图片是我在国外的一个网站上看到的，非常赞！

既然 OSI 七层模型这么厉害，为什么干不过 TCP/IP 四层模型呢？

的确，OSI 七层模型当时一直被一些大公司甚至一些国家政府支持。这样的背景下，为什么会失败呢？我觉得主要有下面几方面原因：

OSI 的专家缺乏实际经验，他们在完成 OSI 标准时缺乏商业驱动力
OSI 的协议实现起来过分复杂，而且运行效率很低
OSI 制定标准的周期太长，因而使得按 OSI 标准生产的设备无法及时进入市场（20 世纪 90 年代初期，虽然整套的 OSI 国际标准都已经制定出来，但基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了）
OSI 的层次划分不太合理，有些功能在多个层次中重复出现。

OSI 七层模型虽然失败了，但是却提供了很多不错的理论基础。为了更好地去了解网络分层，OSI 七层模型还是非常有必要学习的。

最后再分享一个关于 OSI 七层模型非常不错的总结图片！

# TCP/IP 四层模型

TCP/IP 四层模型 是目前被广泛采用的一种模型,我们可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成：

应用层
传输层
网络层
网络接口层

需要注意的是，我们并不能将 TCP/IP 四层模型和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来，如下图所示：

# 应用层（Application layer）

应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。 我们把应用层交互的数据单元称为报文。

应用层协议定义了网络通信规则，对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如支持 Web 应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。

应用层常见协议总结，请看这篇文章：应用层常见协议总结（应用层）。

# 传输层（Transport layer）

传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务。 应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。

运输层主要使用以下两种协议：

传输控制协议 TCP（Transmisson Control Protocol）–提供 面向连接 的，可靠的 数据传输服务。
用户数据协议 UDP（User Datagram Protocol）–提供 无连接 的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

# 网络层（Network layer）

网络层负责为分组交换网上的不同主机提供通信服务。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。

⚠️注意：不要把运输层的“用户数据报 UDP”和网络层的“IP 数据报”弄混。

网络层的还有一个任务就是选择合适的路由，使源主机运输层所传下来的分组，能通过网络层中的路由器找到目的主机。

这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称。

互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Internet Prococol）和许多路由选择协议，因此互联网的网络层也叫做 网际层 或 IP 层。

网络层常见协议 ：

IP:网际协议 ：网际协议 IP 是TCP/IP协议中最重要的协议之一，也是网络层最重要的协议之一，IP协议的作用包括寻址规约、定义数据包的格式等等，是网络层信息传输的主力协议。目前IP协议主要分为两种，一种是过去的IPv4，另一种是较新的IPv6，目前这两种协议都在使用，但后者已经被提议来取代前者。
ARP 协议 ：ARP协议，全称地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个IP数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但IP地址属于逻辑地址，而MAC地址才是物理地址，ARP协议解决了IP地址转MAC地址的一些问题。
NAT:网络地址转换协议 ：NAT协议（Network Address Translation）的应用场景如同它的名称——网络地址转换，应用于内部网到外部网的地址转换过程中。具体地说，在一个小的子网（局域网，LAN）内，各主机使用的是同一个LAN下的IP地址，但在该LAN以外，在广域网（WAN）中，需要一个统一的IP地址来标识该LAN在整个Internet上的位置。
…

# 网络接口层（Network interface layer）

我们可以把网络接口层看作是数据链路层和物理层的合体。

数据链路层(data link layer)通常简称为链路层（两台主机之间的数据传输，总是在一段一段的链路上传送的）。数据链路层的作用是将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异

# 总结

简单总结一下每一层包含的协议和核心技术:

应用层协议 :

HTTP 协议（超文本传输协议，网页浏览常用的协议）
DHCP 协议（动态主机配置）
DNS 系统原理（域名系统）
FTP 协议（文件传输协议）
Telnet协议（远程登陆协议）
电子邮件协议等（SMTP、POP3、IMAP）
…

传输层协议 :

TCP 协议
- 报文段结构
- 可靠数据传输
- 流量控制
- 拥塞控制
UDP 协议
- 报文段结构
- RDT（可靠数据传输协议）

网络层协议 :

IP 协议（TCP/IP 协议的基础，分为 IPv4 和 IPv6）
ARP 协议（地址解析协议，用于解析 IP 地址和 MAC 地址之间的映射）
ICMP 协议（控制报文协议，用于发送控制消息）
NAT 协议（网络地址转换协议）
RIP 协议、OSPF 协议、BGP 协议（路由选择协议）
…

网络接口层 :

差错检测技术
多路访问协议（信道复用技术）
CSMA/CD 协议
MAC 协议
以太网技术
…

# 网络分层的原因

在这篇文章的最后，我想聊聊：“为什么网络要分层？”。

说到分层，我们先从我们平时使用框架开发一个后台程序来说，我们往往会按照每一层做不同的事情的原则将系统分为三层（复杂的系统分层会更多）:

Repository（数据库操作）
Service（业务操作）
Controller（前后端数据交互）

复杂的系统需要分层，因为每一层都需要专注于一类事情。网络分层的原因也是一样，每一层只专注于做一类事情。

好了，再来说回：“为什么网络要分层？”。我觉得主要有 3 方面的原因：

各层之间相互独立：各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）。这个和我们对开发时系统进行分层是一个道理。
提高了整体灵活性 ：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。
大问题化小 ：分层可以将复杂的网络间题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。

我想到了计算机世界非常非常有名的一句话，这里分享一下：

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，计算机整个体系从上到下都是按照严格的层次结构设计的。

ID	标题	地址
1	设计模式面试题（总结最全面的面试题）	juejin.cn/post/684490…
2	Java基础知识面试题（总结最全面的面试题）	juejin.cn/post/684490…
3	Java集合面试题（总结最全面的面试题）	juejin.cn/post/684490…
4	JavaIO、BIO、NIO、AIO、Netty面试题（总结最全面的面试题）	juejin.cn/post/684490…
5	Java并发编程面试题（总结最全面的面试题）	juejin.cn/post/684490…
6	Java异常面试题（总结最全面的面试题）	juejin.cn/post/684490…
7	Java虚拟机（JVM）面试题（总结最全面的面试题）	juejin.cn/post/684490…
8	Spring面试题（总结最全面的面试题）	juejin.cn/post/684490…
9	Spring MVC面试题（总结最全面的面试题）	juejin.cn/post/684490…
10	Spring Boot面试题（总结最全面的面试题）	juejin.cn/post/684490…
11	Spring Cloud面试题（总结最全面的面试题）	juejin.cn/post/684490…
12	Redis面试题（总结最全面的面试题）	juejin.cn/post/684490…
13	MyBatis面试题（总结最全面的面试题）	juejin.cn/post/684490…
14	MySQL面试题（总结最全面的面试题）	juejin.cn/post/684490…
15	TCP、UDP、Socket、HTTP面试题（总结最全面的面试题）	juejin.cn/post/684490…
16	Nginx面试题（总结最全面的面试题）	juejin.cn/post/684490…
17	ElasticSearch面试题
18	kafka面试题
19	RabbitMQ面试题（总结最全面的面试题）	juejin.cn/post/684490…
20	Dubbo面试题（总结最全面的面试题）	juejin.cn/post/684490…
21	ZooKeeper面试题（总结最全面的面试题）	juejin.cn/post/684490…
22	Netty面试题（总结最全面的面试题）
23	Tomcat面试题（总结最全面的面试题）	juejin.cn/post/684490…
24	Linux面试题（总结最全面的面试题）	juejin.cn/post/684490…
25	互联网相关面试题（总结最全面的面试题）
26	互联网安全面试题（总结最全面的面试题）

其然乐衣

2、

3、

分布式搜索引擎03

0.学习目标

1.数据聚合

1.1.聚合的种类

1.2.DSL实现聚合

1.2.1.Bucket聚合语法

1.2.2.聚合结果排序

1.2.3.限定聚合范围

1.2.4.Metric聚合语法

1.2.5.小结

1.3.RestAPI实现聚合

1.3.1.API语法

1.3.2.业务需求

1.3.3.业务实现

2.自动补全

2.1.拼音分词器

2.2.自定义分词器

总结：

2.3.自动补全查询

2.4.实现酒店搜索框自动补全

2.4.1.修改酒店映射结构

2.4.2.修改HotelDoc实体

2.4.3.重新导入

2.4.4.自动补全查询的JavaAPI

2.4.5.实现搜索框自动补全

3.数据同步

3.1.思路分析

3.1.1.同步调用

3.1.2.异步通知

3.1.3.监听binlog

3.1.4.选择

3.2.实现数据同步

3.2.1.思路

3.2.2.导入demo

3.2.3.声明交换机、队列

1）引入依赖

2）声明队列交换机名称

3）声明队列交换机

3.2.4.发送MQ消息

3.2.5.接收MQ消息

4.集群

4.1.搭建ES集群

4.2.集群脑裂问题

4.2.1.集群职责划分

4.2.2.脑裂问题

4.2.3.小结

4.3.集群分布式存储

4.3.1.分片存储测试

4.3.2.分片存储原理

4.4.集群分布式查询

4.5.集群故障转移

分布式搜索引擎02

0.学习目标

1.DSL查询文档

1.1.DSL查询分类

1.2.全文检索查询

1.2.1.使用场景

1.2.2.基本语法

1.2.3.示例

1.2.4.总结

1.3.精准查询

1.3.1.term查询

1.3.2.range查询

1.3.3.总结

1.4.地理坐标查询

1.4.1.矩形范围查询

1.4.2.附近查询

1.5.复合查询

1.5.1.相关性算分

1.5.2.算分函数查询

1）语法说明

2）示例

3）小结

1.5.3.布尔查询

1）语法示例：

2）示例

3）小结