Elasticsearch集群

冷不防 2022-10-31 13:44 253阅读 0赞

# 集群节点 #

ELasticsearch的集群是由多个节点组成的，通过cluster.name设置集群名称，并且用于区分其它的集群，每个节点  
通过node.name指定节点的名称。  
在Elasticsearch中，节点的类型主要有4种：

*  master节点
    
     *  配置文件中node.master属性为true(默认为true)，就有资格被选为master节点。
     *  master节点用于控制整个集群的操作。比如创建或删除索引，管理其它非master节点等。
 *  data节点
    
     *  配置文件中node.data属性为true(默认为true)，就有资格被设置成data节点。
     *  data节点主要用于执行数据相关的操作。比如文档的CRUD。
 *  客户端节点
    
     *  配置文件中node.master属性和node.data属性均为false。
     *  该节点不能作为master节点，也不能作为data节点。
     *  可以作为客户端节点，用于响应用户的请求，把请求转发到其他节点
 *  部落节点
    
     *  当一个节点配置tribe.\*的时候，它是一个特殊的客户端，它可以连接多个集群，在所有连接的集群上执行  
        搜索和其他操作。

# 搭建集群示例 #

#启动3个虚拟机，分别在3台虚拟机上部署安装Elasticsearch
    mkdir /es/es-cluster
    #分发到其它机器
    scp -r es-cluster elsearch@host:/es
    
    #node01的配置：
    cluster.name: es-cluster  # 集群名称 
    node.name: node01 # 节点名称
    node.master: true # 是否可以成为master节点
    node.data: true # 是否可以成为data节点
    network.host: 0.0.0.0 # ip
    http.port: 9200  # port
    discovery.zen.ping.unicast.hosts: ["host1","host2","host3"] # 集群ip列表
    discovery.zen.minimum_master_nodes: 2 # 可以成为master节点的数量， 配置规则 n/2+1
    # 设置cors
    http.cors.enabled: true
    http.cors.allow-origin: "*"
    
    
    #node02的配置：
    cluster.name: es-cluster
    node.name: node02
    node.master: true
    node.data: true
    network.host: 0.0.0.0
    http.port: 9200
    discovery.zen.ping.unicast.hosts: ["host1","host2","host3"] 
    discovery.zen.minimum_master_nodes: 2
    http.cors.enabled: true
    http.cors.allow-origin: "*"
    
    
    #node03的配置：
    cluster.name: es-cluster
    node.name: node02
    node.master: true
    node.data: true
    network.host: 0.0.0.0
    http.port: 9200
    discovery.zen.ping.unicast.hosts:["host1","host2","host3"] 
    discovery.zen.minimum_master_nodes: 2
    http.cors.enabled: true
    http.cors.allow-origin: "*"
    
    
    #分别启动3个节点
    ./elasticsearch

#### 查看集群 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70]

#### 查询集群状态：/\_cluster/health ####

{
      cluster_name: "es-cluster"
      status: "green"
      timed_out: false
      number_of_nodes: 3
      number_of_data_nodes: 3
      active_primary_shards: 5
      active_shards: 10
      relocating_shards: 0
      initializing_shards: 0
      unassigned_shards: 0
      delayed_unassigned_shards: 0
      number_of_pending_tasks: 0
      number_of_in_flight_fetch: 0
      task_max_waiting_in_queue_millis: 0
      active_shards_percent_as_number: 100
    }

#### 集群状态的三种颜色: ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 1]

# 分片和副本 #

为了将数据添加到Elasticsearch，我们需要索引(index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.

*  一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
 *  我们需要知道是分片就是一个Lucene实例，并且它本身就是一个完整的搜索引擎。应用程序不会和它直接通信。
 *  分片可以是主分片(primary shard)或者是复制分片(replica shard)。
 *  索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。
 *  复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。
 *  当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

# 故障转移 #

### 总结：如果data节点停止，其他节点会自动分配主分片和和副分片，不会影响使用，当data节点恢复后，整个集群又可以恢复为之前的集群状态。如果master的节点停止，那么其他的data会自动分配一个master节点，如果之前停掉的master节点恢复后，则变为data节点，因为之前的data节点变为了master节点，同一个集群只能有一个master节点。 ###

特别说明：  
如果在配置文件中discovery.zen.minimum\_master\_nodes设置的不是N/2+1时，会出现脑裂问题，之前宕机  
的主节点恢复后不会加入到集群。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 2]

# 分布式文档 #

## 路由 ##

首先，来看个问题：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 3]  
如图所示：当我们想一个集群保存文档时，文档该存储到哪个节点呢？ 是随机吗？ 是轮询吗？  
实际上，在ELasticsearch中，会采用计算的方式来确定存储到哪个节点，计算公式如下：

shard = hash(routing) % number_of_primary_shards

*  routing值是一个任意字符串，它默认是\_id但也可以自定义。
 *  这个routing字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是0到number\_of\_primary\_shards - 1，这个数字就是特定文档所在的分片。

这就是为什么创建了主分片后，不能修改的原因。

## 文档的写操作 ##

新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 4]  
下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：

1.  客户端给 Node 1 发送新建、索引或删除请求。
2.  节点使用文档的 \_id 确定文档属于分片 0 。它转发请求到 Node 3 ，分片 0 位于这个节点上。
3.  Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和 Node 2 的复制节点上。当所有的复制节点报告成功， Node 3 报告成功到请求的节点，请求的节点再报告给客户端。客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。

## 搜索文档(单个文档) ##

文档能够从主分片或任意一个复制分片被检索。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 5]  
下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤：

1.  客户端给 Node 1 发送get请求。
2.  节点使用文档的 \_id 确定文档属于分片 0 。分片 0 对应的复制分片在三个节点上都有。此时，它转发请求到Node 2 。
3.  Node 2 返回文档(document)给 Node 1 然后返回给客户端。

对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。  
可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。

## 全文搜索 ##

对于全文搜索而言，文档可能分散在各个节点上，那么在分布式的情况下，如何搜索文档呢？  
搜索，分为2个阶段，搜索（query）+取回（fetch）。

### 搜索（query） ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 6]  
查询阶段包含以下三步：

1.  客户端发送一个 search（搜索） 请求给 Node 3 , Node 3 创建了一个长度为 from+size 的空优先级队
2.  Node 3 转发这个搜索请求到索引中每个分片的原本或副本。每个分片在本地执行这个查询并且结果将结果到一个大小为 from+size 的有序本地优先队列里去。
3.  每个分片返回document的ID和它优先队列里的所有document的排序值给协调节点 Node 3 。 Node 3 把这些值合并到自己的优先队列里产生全局排序结果。

### 取回（fetch） ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 7]  
分发阶段由以下步骤构成：

1.  协调节点辨别出哪个document需要取回，并且向相关分片发出 GET 请求。
2.  每个分片加载document并且根据需要丰富（enrich）它们，然后再将document返回协调节点。
3.  一旦所有的document都被取回，协调节点会将结果返回给客户端。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70]: /images/20221024/57cb4e5a60034b4eab0bb14d14648396.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 1]: /images/20221024/20473562f0584dc7aa49630e8f6608f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 2]: /images/20221024/a344b3e4e3b84ecaa53374c83a62c148.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 3]: /images/20221024/d25432872522413dbc08f67afd3b42ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 4]: /images/20221024/2a6b9bc275254664b9aa280743d20159.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 5]: /images/20221024/ae84f368d9e84e678862598f86402201.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 6]: /images/20221024/f569c21757684ab38efb6d3cc708804a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMTkzMzg2_size_16_color_FFFFFF_t_70 7]: /images/20221024/b764ab9659354003ba7e8d4386b28d25.png