Elasticsearch核心原理之集群与分片

阿飞算法

已于 2022-04-30 20:55:24 修改

阅读量1.9k

点赞数

分类专栏： BigData ElasticSearch 文章标签： bigdata

于 2022-04-30 09:14:18 首次发布

本文链接：https://blog.csdn.net/wat1r/article/details/124508474

版权

BigData 同时被 2 个专栏收录

10 篇文章 1 订阅

订阅专栏

ElasticSearch

2 篇文章 0 订阅

订阅专栏

Elasticsearch核心原理之集群与分片

集群

空集群

请添加图片描述

启动一个单独的节点，里面不包含任何的数据和索引，集群看起来就是一个上图一样的包含空内容节点的集群。

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含所需文档的节点收集回数据，并将最终结果返回给客户端。 Elasticsearch 对这一切的管理都是透明的。

集群健康

可以使用下面的请求获取集群的状态

GET /_cluster/health

返回的内容如下：

{
   "cluster_name":          "elasticsearch",
   "status":                "green", 
   "timed_out":             false,
   "number_of_nodes":       1,
   "number_of_data_nodes":  1,
   "active_primary_shards": 0,
   "active_shards":         0,
   "relocating_shards":     0,
   "initializing_shards":   0,
   "unassigned_shards":     0
}

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

green :所有主要分片和复制分片都可用
yellow:所有主要分片可用，但不是所有复制分片都可用
red:不是所有的主要分片都可用

添加索引

往Elasticsearch添加数据时需要用到索引 (保存相关数据的地方)。索引实际上是指向一个或者多个物理分片的逻辑命名空间。

一个分片是一个底层的工作单元，它仅保存了全部数据中的一部分。一个分片是一个 Lucene 的实例，以及它本身就是一个完整的搜索引擎。文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。

Elasticsearch是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。

在包含一个空节点的集群内创建名为 blogs 的索引。索引在默认情况下会被分配5个主分片，但是为了演示目的，将分配3个主分片和一份副本（每个主分片拥有一个副本分片）：

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

请添加图片描述
可以看出来，在集群中，所有3个主分片都被分配在 Node 1 。

查询集群的健康状态：

{
  "cluster_name": "elasticsearch",
  "status": "yellow", 
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 3,
  "active_shards": 3,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 3, 
  "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": 50
}

集群的健康状况为 yellow 则表示全部主分片都正常运行（集群可以正常服务所有请求），但是副本分片没有全部处在正常状态。实际上，所有3个副本分片都是 unassigned —— 它们都没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，也将丢失该节点上的所有副本数据。

当前的集群是正常运行的，但是在硬件故障时有丢失数据的风险

添加故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题。

请添加图片描述
当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。

所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

cluster-health 现在展示的状态为 green ，这表示所有6个分片（包括3个主分片和3个副本分片）都在正常运行。

{
  "cluster_name": "elasticsearch",
  "status": "green", 
  "timed_out": false,
  "number_of_nodes": 2,
  "number_of_data_nodes": 2,
  "active_primary_shards": 3,
  "active_shards": 6,
  "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
}

水平扩容

请添加图片描述
Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

应对故障

请添加图片描述

关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 2 。

在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。

幸运的是，在其它节点上存在着这两个主分片的完整副本，所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片，此时集群的状态将会为 yellow 。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

为什么我们集群状态是 yellow 而不是 green 呢？虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 Node 2 ，我们的程序依然可以保持在不丢任何数据的情况下运行，因为 Node 3 为每一个分片都保留着一份副本。

如果重新启动 Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将如上一章节所示。如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。

分片与副本

分片分为主分片（Primary）和副本分片（Replica）。副本分片主要功能如下：

高可用性：副本分片作为数据备份，当某个主分片发生故障时，副本分片能够成为新的主分片，保证服务的可用性。
提高性能：副本分片本身也是一个功能齐全的独立的分片(所以才能够随时取代故障的主分片)，当有查询请求时，既可以在主分片中完成查询，也可以在副本分片中完成查询，当然数据添加、更新的操作只能在主分片中完成。

准备环境

查看集群的状态

GET http://localhost:2001/_cluster/health
{
    "cluster_name": "my-application",
    "status": "green",
    "timed_out": false,
    "number_of_nodes": 3,
    "number_of_data_nodes": 3,
    "active_primary_shards": 3,
    "active_shards": 9,
    "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.0
}

创建test索引（1个分片）

PUT http://localhost:2001/test
{
    "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 0
    }
}

创建test1索引（2个分片）

PUT http://localhost:2001/test1
{
    "settings": {
        "number_of_shards": 2,
        "number_of_replicas": 0
    }
}

创建test2索引（3个分片）

PUT http://localhost:2001/test1
{
    "settings": {
        "number_of_shards": 3,
        "number_of_replicas": 0
    }
}

创建test3索引（4个分片）

PUT http://localhost:2001/test1
{
    "settings": {
        "number_of_shards": 4,
        "number_of_replicas": 0
    }
}

请添加图片描述

从上面的结果看出，集群节点为3个（node-2001，node-2002，node-2003）,当分片的个数小于等于3的时候，其分布在三个节点或者三个节点的部分节点上，当分片的数量大于3为4的时候，有两个分片分布在其中的一个节点（图中为node-2001）

副本

在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片(副本)。

副本存在的两个重要原因：

1.提高可用性：注意的是副本不能与主/原分片位于同一节点。
2.提高吞吐量：搜索操作可以在所有的副本上并行运行。

创建test4索引（1分片2副本）

PUT http://localhost:2001/test4
{
    "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 2
    }
}

看到了3个绿色的0，其中在node-2002节点的边框是粗体的，这个表示分片，而另外两个节点的0的边框是细体的，这两个就是分片的副本。

通常我们三个节点建立两个副本就可以了，三份数据均匀得到分布在三个节点。如果建立三个副本会怎么样呢？

创建test5索引（1分片3副本）

PUT http://localhost:2001/test5
{
    "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 3
    }
}

请添加图片描述

如上所示我们看到多出一个Unassigned的副本，这个副本其实是多余的了，因为每个节点已经包含了分片的本身和其副本，多于这个没有意义。

创建test6索引（默认）

PUT http://localhost:2001/test6
{
    "settings": {
       
    }
}

可以看出，对于三节点的集群来说，默认是一个分片，一个副本。

创建test7索引（2分片2副本）

PUT http://localhost:2001/test7
{
    "settings": {
        "number_of_shards": 2,
        "number_of_replicas": 2
    }
}

创建test8索引（3分片2副本）

PUT http://localhost:2001/test8
{
    "settings": {
        "number_of_shards": 3,
        "number_of_replicas": 2
    }
}

请添加图片描述

可以看出，分片和副本均匀地分布在每个节点上（粗线框表示分片，细线框表示副本）

缩容

如果其中一个节点挂掉，会发生什么？

原本的node-2003节点变成了Unassigned，并且注意标注的三个红框内的分片，这三个分片已经随着节点的宕机消息了，这就造成了数据的丢失；反观后面几个，虽然node-2003宕机了，但是由于做了分片与备份，索引仍然可以正常的工作，而且test8索引上原属于node-2003的2号分片转移到node-2001节点上。

请添加图片描述

如果再挂一个节点会出现什么？node-2002宕机后，集群已经不可见了，说明只有1个节点的集群不可用。

请添加图片描述

扩容

创建test9索引（3分片2副本）

PUT http://localhost:2001/test9
{
    "settings": {
        "number_of_shards": 3,
        "number_of_replicas": 2
    }
}

恢复节点node-2002后，再次创建test9索引，集群的恢复可以访问的状态

请添加图片描述

当恢复node-2003后，集群恢复正常
请添加图片描述
但是node-2003上的全部是副本，并没有将分片转移到node-2003节点上

索引的路由

通过上面的结果，发现分片和副本的存储规律，那么在每次我们进行索引的时候，是通过什么样的路由方式去找到对应的分片，从而获取想要的数据呢？

实际es是通过hash运算找到每次数据存储的位置，公式如下：

shard=hash(routing)%number_of_primary_shards

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过hash 函数生成一个数字，然后这个数字再模上 number_of_primary_shards （主分片的数量）后得到余数。这个分布在0到 number_of_primary_shards-1 之间的余数，就是所寻求的文档所在分片的位置。

通过上面的公式，我们理解并且也需要记住一个重要的概念：

创建索引的时候就确定好主分片的数量，并且永远不会改变这个数量，数量的改变将导致上述公式的结果变化，最终会导致我们的数据无法被找到。

阿飞算法

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Elasticsearch核心原理之集群与分片

集群空集群启动一个单独的节点，里面不包含任何的数据和索引，集群看起来就是一个上图一样的包含空内容节点的集群。一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等
复制链接

扫一扫