DSL查询文档

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

使用下面的代码首先看es的，把数据批量导入之后在运行在Kibana中

查询所有，查询类型时match_all ，没有查询条件

#显示所有
GET /hotel/_search
{
  "query": {
    "match_all": {
      
    }
  }
}

全文检索查询：

使用场景：对内容分词得到词条，根据词条去倒排索引库中匹配，得到文档id。根据文档id找到文档，返回给用户。（因为时词条去匹配，字段是可分词的text类型的字段）

match查询：单字段查询

#单字段查询
GET /hotel/_search
{
  "query": {
    "match": {
      "FIELD": "TEXT"
    }
  }
}

multi

#多字段查询，结果只能是并集     
GET /hotel/_search
{
  "query": {
    "multi_match": {
      "query": "外滩如家",
      "fields": ["name","all"]
    }
  }
}


#多字段分词查询 结果可控，并集或交集  OR  AND
GET /hotel/_search
{
  "query": {
    "query_string": {
      "fields": ["name","all"],
      "query": "北京 OR 如家"
    }
  }
}

#多字段查询，结果可控，交集或并集  +  |
GET /hotel/_search
{
  "query": {
    "simple_query_string": {
      "query": "北京+如家",
      "fields": ["name","all"]
    }
  }
}

精确查询：一般用于查找keyword，数值，日期，boolean等字段，不会对搜索条件分词

term查询：不分词的词条，查询时用户输入内容和自动值完全匹配才符合条件

##term查询，根据字段值精确查询   FIELD是符合的字段
GET /hotel/_search
{
  "query": {
    "term": {
      "FIELD": {
        "value": "VALUE"
      }
    }
  }
}

range查询：范围查询，一般是对数值型做范围过滤的时候，（如果要复制，把#和前面的空格删除）

#range查询  范围查询
GET /hotel/_search
{
  "query": {
    "range": {
      "price": {
        "gte": 1000,         #gte表示大于等于，gt表示大于
        "lte": 3000         #lte代表小于等于，lt表示小于
      }
    }
  }
}

地理坐标查询

根据经纬度查询，官方文档：Geo queries | Elasticsearch Guide [8.1] | Elastic

geo_bounding_box ：矩形查询，坐标落在某个矩形范围的文档，查询时指定矩形左上，右下两个点的坐标（如果要复制，把#和前面的空格删除）

#矩形查询
GET /hotel/_search
{
  "query": {
    "geo_bounding_box":{
      "location":{
        "top_left":{            #左上
        "lat":31.1,
        "lon":121.5
      },
      "bottom_right":{         #右下
        "lat":30.9,
        "lon":121.7
      }
    }
  }
}
}

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

圆型查询

#圆形查询
GET /hotel/_search
{
  "query": {
    "geo_distance":{
      "distance": "15km" ,    #半径
      "location": "31.21,121.5"   #圆心
    }
  }
}

复合查询：将其他简单查询组合起来，实现更复杂的搜索逻辑

fuction score：算分函数查询，可以控制文档相关性算分，控制文档排名

bool query：布尔查询，利用逻辑关系组合多个其它的查询，实现复杂搜索

相关性算法：在用match查询时，文档结果会根据与搜索词条的关联度打分（_score），返回结果时按照分值降序排列。

在es5.1之前的版本使用TF-IDF算法

在5.1版本之后使用BM25算法

算法函数查询

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

#算法相关性   满足外滩条件的所有查询中，满足如家的相关性算法加10，获得查询结果
GET /hotel/_search
{
  "query": {
    "function_score": {
      "query": {"match": {
        "all": "外滩"
      }},
      "functions": [
        {
          "filter":{"term": {
            "brand": "如家"
          }
        },
        "weight": 10
        }
      ],
      "boost_mode":"sum"
    }
  }
}

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

must：必须匹配每个子查询，类似”与“

should：选择性匹配子查询，类似”或“

must_not:不匹配，不参与算法，类似’非‘

filter：必须匹配，不参与算分

#布尔查询
#must:必须匹配每个子查询
#should选择性匹配
#must_not 不匹配 不参与算分
#filter必须匹配，不参与算分
#-城市在北京，品牌二选一、价格不小于500、评分大于45
GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "city": {
              "value": "北京"
            }
          }
        }
      ],
      "should": [
        {
          "term": {
            "brand": {
              "value": "皇冠假日"
            }
          }
        },
        {
          "term": {
            "brand": {
              "value": "华美达"
            }
          }
        }
      ],
      "must_not": [
        {
          "range":{
            "price": {
              "lte": 500
            }
          }
        }
      ],
      "filter": [
        {"range": {
          "score": {
            "gte": 45
          }
        }}
      ]
    }
  }
}

#boolean查询 名字包含如家 、价格不高于400
GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "name": "如家"
          }
        }
      ],
      "must_not": [
        {
          "range": {
            "price": {
              "gte": 400
              
            }
          }
        }
      ]
    }
  }
}

将搜索结构按指定方式处理

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

1.普通字段排序：keyword、数值、日期类型排序的语法基本一致。排序条件可以是多个，依次排序

#搜索方法结果处理(简写)   FIELD是排序字段，排序方式ASC,DESC
GET /hotel/_search
{
  "query": {
    "match": {
      "name": "北京如家"
    }
  },
  "sort":[
    {
      "FIELD":"desc"
    }]
}
GET /hotel/_search
{
  "query": {
    "match": {
      "name": "北京如家"
    }
  },
  "sort": [
    {
      "price": {
        "order": "desc"
      }
    }
  ]
}

基本的分页

#分页   from 分页开始位置默认为0   size期望获取的文档总数
GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 200
  , "size": 1
}

深度分页问题

要查询990~1000的数据，查询逻辑要这么写

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

查询从990开始的数据，也就是990~1000条数据

如果es是单点模式，elasticsearch内部分页时，先查询 0~1000条，然后截取其中的990 ~ 1000的这10条

如果es是集群模式，例如集群有5个节点，查询TOP1000的数据，并不是每个节点查询200条就可以了。因为节点A的TOP200，在另一个节点可能排到10000名以外了。因此要想获取整个集群的TOP1000，必须先查询出每个节点的TOP1000，汇总结果后，重新排名，重新截取TOP1000。

当查询分页深度较大时，汇总数据过多，对内存和CPU会产生非常大的压力，因此elasticsearch会禁止from+ size 超过10000的请求。

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

1.search after：分页时需要排序，原理是从上一次的排序值开始，查询下一页数据。官方推荐使用的方式。

2.scroll：原理将排序后的文档id形成快照，保存在内存。官方已经不推荐使用。

分页查询的常见实现方法

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

高亮显示：在搜索的时候关键字变成红色，比较醒目

实现高亮，就是给文档中的所有关键字都添加一个标签，例如标签，页面给标签编写CSS样式

#高亮 GET /hotel/_search { "query": { "match": { "name": "北京如家" } } , "highlight": { "fields": { "name": { "pre_tags": "" , "post_tags": "" } } } }

默认情况下，高亮的字段，必须与搜索指定的字段一致，否则无法高亮。如果要对非搜索字段高亮，则需要添加一个属性：required_field_match=false

RestClient查询文档

前期准备，先连接上虚拟机中的es

@SpringBootTest public class HotelSearchTest { //初始化ES客户端连接实例 private RestHighLevelClient client; //单元测试执行前创建客户端实例 @BeforeEach void initClient(){ client = new RestHighLevelClient(RestClient.builder(HttpHost.create("192.168.190.136:9200"))); } //单元测试执行后关系客户端实例 @AfterEach void closeClient(){ try { client.close(); } catch (IOException e) { e.printStackTrace(); } } }

发起请求代码解读：

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

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

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

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

//查询所有 @Test void testMatchAll(){ //1创建搜索请求对象 SearchRequest searchRequest = new SearchRequest("hotel"); //2设置搜索类型 searchRequest.source().query(QueryBuilders.matchAllQuery()); try { //3.发起请求 SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); //4.解析响应结果（从外向内解析） long total = searchResponse.getHits().getTotalHits().value; //4.2 遍历获取命中的具体文档数据SON字符串 SearchHit[] searchHits = searchResponse.getHits().getHits(); if(searchHits!=null && searchHits.length>0){ for (SearchHit hit : searchHits) { String hotelDocJson = hit.getSourceAsString(); System.out.println("命中的数据：" + hotelDocJson); } } } catch (IOException e) { e.printStackTrace(); } }

响应结果解析：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文档数据

//查询类型2：全文检索查询 @Test void testMatch(){ //1.创建搜索对象 SearchRequest searchRequest = new SearchRequest("hotel"); //2设置搜索类型 //单字段查询 //searchRequest.source().query(QueryBuilders.matchQuery("name","北京如家")); //多字段查询 searchRequest.source().query(QueryBuilders.multiMatchQuery("北京如家","name","all")); try { //3发起请求 SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); //4解析响应结果 //4.1搜索名中的记录总数 long total = searchResponse.getHits().getTotalHits().value; //4.2 遍历获取命中的具体文档数据SON字符串 SearchHit[] searchHits = searchResponse.getHits().getHits(); if(searchHits!=null&&searchHits.length>0){ for (SearchHit hit : searchHits) { String hotelDocJson = hit.getSourceAsString(); System.out.println("命中数据"+hotelDocJson); } } } catch (IOException e) { e.printStackTrace(); } } //查询3，精确查询 @Test void testTerm(){ //创建搜索实例 SearchRequest searchRequest = new SearchRequest("hotel"); //2.设置搜索类型 //term查询 //searchRequest.source().query(QueryBuilders.termQuery("city","上海")); //ids查询 //searchRequest.source().query(QueryBuilders.idsQuery().addIds("45845","47066")); //range查询 searchRequest.source().query(QueryBuilders.rangeQuery("price").gte(300).lte(500)); try { //3.发起请求 SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); //4.解析响应结果（从外向内解析） //4.1 搜索命中的记录总数 long total = searchResponse.getHits().getTotalHits().value; System.out.println("总记录数：" + total); //4.2 遍历获取命中的具体文档数据SON字符串 SearchHit[] searchHits = searchResponse.getHits().getHits(); if(searchHits!=null && searchHits.length>0){ for (SearchHit hit : searchHits) { String hotelDocJson = hit.getSourceAsString(); System.out.println("命中的数据：" + hotelDocJson); } } } catch (IOException e) { e.printStackTrace(); } } //查询4 布尔查询 @Test void testComp() { //创建查询请求对象 SearchRequest searchRequest = new SearchRequest("hotel"); //设置搜索类型 //创建布尔查询 BoolQueryBuilder boolQuery = QueryBuilders.boolQuery(); //添加must条件 boolQuery.must(QueryBuilders.termQuery("city", "上海")); //添加filter条件 boolQuery.filter(QueryBuilders.rangeQuery("price").lte(250)); //构建查询语句 searchRequest.source().query(boolQuery); try { //3.发起请求 SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); //4.解析响应结果（从外向内解析） //4.1 搜索命中的记录总数 long total = searchResponse.getHits().getTotalHits().value; System.out.println("总记录数：" + total); //4.2 遍历获取命中的具体文档数据SON字符串 SearchHit[] searchHits = searchResponse.getHits().getHits(); if (searchHits != null && searchHits.length > 0) { for (SearchHit hit : searchHits) { String hotelDocJson = hit.getSourceAsString(); System.out.println("命中的数据：" + hotelDocJson); } } } catch (IOException e) { e.printStackTrace(); } } /** * 查询结果处理：排序和分析 */ @Test void testSortAndPage(){ //1.创建搜索请求对象 SearchRequest searchRequest = new SearchRequest("hotel"); //2.设置搜索类型 BoolQueryBuilder boolQueryBuilder = QueryBuilders.boolQuery(); boolQueryBuilder.must(QueryBuilders.termQuery("city","上海")); boolQueryBuilder.filter(QueryBuilders.rangeQuery("price").lte(250)); //range查询 searchRequest.source().query(boolQueryBuilder); searchRequest.source().from(0).size(3);//从第0条开始查询3条 searchRequest.source().sort("price", SortOrder.DESC);//按照价格倒序 try { //3.发起请求 SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); //4.解析响应结果（从外向内解析） //4.1 搜索命中的记录总数 long total = searchResponse.getHits().getTotalHits().value; System.out.println("总记录数：" + total); //4.2 遍历获取命中的具体文档数据SON字符串 SearchHit[] searchHits = searchResponse.getHits().getHits(); if(searchHits!=null && searchHits.length>0){ for (SearchHit hit : searchHits) { String hotelDocJson = hit.getSourceAsString(); System.out.println("命中的数据：" + hotelDocJson); } } } catch (IOException e) { e.printStackTrace(); } } /** * 查询结果处理：高亮 */ @Test void testHighLight(){ //1.创建搜索请求对象 SearchRequest searchRequest = new SearchRequest("hotel"); //2.设置搜索类型 searchRequest.source().query(QueryBuilders.matchQuery("all","北京酒店")); searchRequest.source().from(8).size(10);//从第4条开始查询3条 searchRequest.source().sort("price", SortOrder.DESC);//按照价格倒序 // HighlightBuilder highlightBuilder = new HighlightBuilder(); // highlightBuilder.field("name"); //高亮字段 // highlightBuilder.requireFieldMatch(false); //高亮字段是否与查询条件字段一致 // highlightBuilder.preTags(""); //高亮前置标签 // highlightBuilder.postTags(""); //高亮后置标签 searchRequest.source().highlighter(new HighlightBuilder().field("name").requireFieldMatch(false).preTags("").postTags("")); try { //3.发起请求 SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); //4.解析响应结果（从外向内解析） //4.1 搜索命中的记录总数 long total = searchResponse.getHits().getTotalHits().value; System.out.println("总记录数：" + total); //4.2 遍历获取命中的具体文档数据SON字符串 SearchHit[] searchHits = searchResponse.getHits().getHits(); if(searchHits!=null && searchHits.length>0){ for (SearchHit hit : searchHits) { String hotelDocJson = hit.getSourceAsString(); HotelDoc hotelDoc = JSON.parseObject(hotelDocJson, HotelDoc.class); HighlightField highlightField = hit.getHighlightFields().get("name"); if(highlightField!=null){ //获取带高亮标签的酒店名称 String highLightName = highlightField.getFragments()[0].toString(); hotelDoc.setName(highLightName); } System.out.println("处理后的数据：" + JSON.toJSONString(hotelDoc)); } } } catch (IOException e) { e.printStackTrace(); } }

高亮结果解析，高亮的结果与查询的文档结果默认是分离的

代码解读：

第一步：从结果中获取source。hit.getSourceAsString()，这部分是非高亮结果，json字符串。还需要反序列为HotelDoc对象

第二步：获取高亮结果。hit.getHighlightFields()，返回值是一个Map，key是高亮字段名称，值是HighlightField对象，代表高亮值

第三步：从map中根据高亮字段名称，获取高亮字段值对象HighlightField

第四步：从HighlightField中获取Fragments，并且转为字符串。这部分就是真正的高亮字符串了

第五步：用高亮的结果替换HotelDoc中的非高亮结果

数据聚合

聚合（aggregations)可以让我们方便的实现对数据的统计运算分析

聚合常见的三类：

桶（Bucket）聚合：用来对文档分组

度量（Metric）聚合：用以计算一些值

管道（pipeline）聚合：其他聚合的结果为基础做聚合

注：参加聚合的字段必须为keyword，日期，数值，布尔类型

DSL实现聚合

Bucket聚合语法

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

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

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

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

限定聚合范围

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

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

Metric聚合语法

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

聚合的三要素：聚合名称，聚合类型，聚合字段

聚合可配置属性：

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

自动补全

在搜索框输入字符时，我们应该提示出与该字符有关的搜索项。要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。地址：GitHub - medcl/elasticsearch-analysis-pinyin: This Pinyin Analysis plugin is used to do conversion between Chinese characters and Pinyin. 安装方式：安装elasticsearch_m0_50601240的博客-CSDN博客

自定义分词器

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

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

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

自动补全查询

elasticsearch提供了Completion Suggester查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。为了提高补全查询的效率，对于文档中字段的类型有一些约束：

参与补全查询的字段必须是completion类型。

字段的内容一般是用来补全的多个词条形成的数组。

// 自动补全查询 GET /test/_search {   "suggest": {     "title_suggest": {       "text": "s", // 关键字       "completion": {         "field": "title", // 补全查询的字段         "skip_duplicates": true, // 跳过重复的         "size": 10 // 获取前10条结果       }     }   } }

数据同步

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

常见的同步方式：1.同步调用 2.异步通知 3.监听binlog

同步调用

基本步骤如下：

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

异步通知

流程如下：

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

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

监听binlog

流程如下：

给mysql开启binlog功能

mysql完成增、删、改操作都会记录在binlog中

hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容

选择

方式一：同步调用

优点：实现简单，粗暴

缺点：业务耦合度高

方式二：异步通知

优点：低耦合，实现难度一般

缺点：依赖mq的可靠性

方式三：监听binlog

优点：完全解除服务间耦合

缺点：开启binlog增加数据库负担、实现复杂度高

集群

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

海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点

单点故障问题：将分片数据在不同节点备份（replica ）

ES集群相关概念:

集群（cluster）：一组拥有共同的 cluster name 的节点。

节点（node) ：集群中的一个 Elasticearch 实例

分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中解决问题：数据量太大，单点存储量有限的问题。

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

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

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

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

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

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

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

集群职责划分

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

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

master节点：对CPU要求高，但是内存要求低。参与集群选主，主节点可以管理集群状态、管理分片信息、处理创建和删除索引库的请求

data节点：对CPU和内存要求都高。数据的CRUD

coordinating节点：对网络带宽、CPU要求高。路由请求到其它节点，合并查询到的结果，返回给用户

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

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

集群中的脑裂问题：

脑裂是因为集群中的节点失联导致的，例如一个集群中，主节点m与其他节点失联。此时，其他节点任务主节点宕机，会重新选择选主。当选出新的主节点n时，n和其他节点自成集群，m自成集群，两个集群数据不同步，出现数据差异。当网络恢复时，因为集群中有两个主节点，集群状态不一致，出现脑裂问题。

解决脑裂的方案是，要求选票超过 ( eligible节点数量 + 1 ）/ 2 才能当选为主，因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum_master_nodes，在es7.0以后，已经成为默认配置，因此一般不会发生脑裂问题

例如：3个节点形成的集群，选票必须超过（3 + 1） / 2 ，也就是2票。node3得到node2和node3的选票，当选为主。node1只有自己1票，没有当选。集群中依然只有1个主节点，没有出现脑裂。

分片存储原理

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

_routing默认是文档的id。算法与分片数量有关，因此索引库一旦创建，分片数量不能修改！

新增文档的流程如下：

集群分布式查询

elasticsearch的查询分成两个阶段：

scatter phase：分散阶段，coordinating node会把请求分发到每一个分片

gather phase：聚集阶段，coordinating node汇总data node的搜索结果，并处理为最终结果集返回给用户

集群故障转移

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