---

ES集群

集群 cluster

由多个ES节点构成
集群提供负载均衡,以及es搜索吞吐量等功能,避免单节点故障

• 一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。一个集群 由一个唯一的名字标识，这个名字默认就是elasticsearch。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。

节点 node

Elasticsearch实例的Java进程，在启动时通过 -Enode.name指定节点名, 每个节点都会存储集群的状态信息

集群状态包括：所有节点信息、所有的索引及Mapping和Setting信息、分片路由信息

• 一个节点是你集群中的一个服务器，作为集群的一部分，它存储你的数据，参与集群的索引和搜索功能。一个节点也是由一个名字来标识的，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在这个管理过程中，你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。

• 一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫 做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。 在一个集群里，只要你想，可以拥有任意多个节点。

节点的类别

只有master节点可以修改集群状态信息

• Data Node：保存分片数据的节点
• Coordinating Node：协调节点负责接受客户端请求并将请求转发到合适的节点，并负责汇总结果；默认情况下每个节点都会启到Coordinating Node的职责
• Hot&Warm Node：由不同配置的Data Node组成，主要为了降低成本，Hot节点使用高配置，Warm节点使用低配置
  
  

分片 shard

索引用来存储文档数据,创建索引的时候可以指定分片和副本; 现在版本的es,默认会给索引创建1个分片和1个副本

分片是针对索引的,将一个索引的数据分别由多个分片存储, 分片又存储在不同的节点上; 分片的好处是提高了索引的物理存储,提高了es查询的检索速度,吞吐量

• 一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

• 分片很重要，主要有两方面的原因：

  • 允许你水平分割/扩展你的内容容量
  • 允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量。

• 默认情况下(ES7.X)，Elasticsearch中的每个索引被分片1个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有1个主分片和另外1个复制分片（1个完全拷贝），这样的话每个索引总共就有2个分片。

分片的合理配置

• 类比kafka的分区，一个分片运行的Lucene的实例 (搜索引擎)
• 在创建索引的时候指定，之后修改需要Reindex(索引再分配到其他节点)
• 分片数与节点数相关，分片数过少影响节点扩容，分片数过多影响查询性能
• 多分片分担写压力，当分片数 > 节点数，新节点加入分片会自动分配新节点,(分配中的分片也称为迁移分片relocating_shards)
• 分片过多会导致潜在性能，查询需要从多个分片上检索数据，比如：集群总分片控制几万内
• 日志单个分片数据存储大小50G内，搜索类单个分片存储20G内，降低merge/rebalancing耗损资源

副本 replicas

• 在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片，或者直接叫复制(副本), 解决数据高可用问题。
• 副本之所以重要，有两个主要原因：
  • 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。(如果在同一节点,节点挂了,副本也没了)
  • 扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行。总之，每个索引可以被分成多个分片。

一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。

分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。

注意:

• 类比kafka的副本，副本分片可以动态调整
• 增加副本数除了解决高可用外，可以提高读取性能，同时增加存储成本

eg:

对es索引进行备份,默认是复制1份; (这里备份的是索引的分片,备份的分片也称为副本分片)

• eg: 创建索引的时候, 设置了三个分片,一个副本, 此时es集群有3个节点,如下图
  一个索引的三个主分片和三个副分片会分别在不同的节点上
  
  主分片 : Primary shard
  副本分片 : Replica shard

分配

• 将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由 master 节点完成的。

集群健康值检查

• 健康值状态
  • Green：所有Primary和Replica均为active，集群健康
  • Yellow：至少一个Replica不可用，但是所有Primary均为active，数据仍然是可以保证完整性的。
  • Red：至少有一个Primary为不可用状态，数据不完整，集群不可用。
• 健康值检查 (带_的都是一些ES的API)
  • _cat/health?v
  • _cluster/health

GET _cluster/health
1

{
  # 集群名称
  "cluster_name" : "AppCommonLogElasticsearch",
  # 健康状态,yellow表示有的副本分片不可用
  "status" : "yellow",
  "timed_out" : false,
  # 节点总数
  "number_of_nodes" : 42,
  # 数据节点数量
  "number_of_data_nodes" : 36,
  # 活跃的主分片数量
  "active_primary_shards" : 15057,
  # 活跃的分片数量(主分片+副本分片)
  "active_shards" : 24265,
  # 迁移中的分片数量(当新增一个节点时,会进行分片均衡,此时会将其他节点的分片,部分迁移到新的节点上, 这个就叫做迁移中的分片)
  "relocating_shards" : 0,
  # 初始化中的分片数量(刚创建的索引设置的分片,还在进行初始化的分片)
  "initializing_shards" : 0,
  # 未分配的分片数量(不可使用的分片)
  "unassigned_shards" : 1,
  "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" : 99.99587900766504
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

常用集群部署架构

todo

单节点集群

我们在包含一个空节点的集群内创建名为 users 的索引，为了演示目的，我们将分配 3个主分片和一份副本（每个主分片拥有一个副本分片）。
所以我们这里拥有3个主分片和3个副本分片

• 集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在 node-1 。

通过 elasticsearch-head 插件（一个Chrome插件）查看集群情况 。

单节点故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余(只有一个节点的时候, 副本是不会生效的)。

我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上, 运行的节点才会自动组成集群。

如果启动了第二个节点，集群将会拥有两个节点 : 所有主分片和副本分片都已被分配 。

新增节点到集群

怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配 。

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

但是如果我们想要扩容超过 6 个节点怎么办呢？

• 主分片的数目在索引创建时就已经确定了下来(一旦确认下来,就不能更改)。实际上，这个数目定义了这个索引能够存储的最大数据量。（实际大小取决于你的数据、硬件和使用场景。写操作是往主分片上写,再往副本分片同步

  

• 读操作(搜索数据和返回数据)——可以同时被主分片或副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。

• 虽然主分片不能修改, 但在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2, 这样就意味着拥有了6个副本分片

  PUT /users/_settings
  {
      "number_of_replicas" : 2
  }
  1
  2
  3
  4

更多的副本会造成数据的冗余,在大数据的情况下,副本数量如果太多,对存储的压力是很大的。

集群节点故障

当第一个节点离开集群，这时集群的状态为:两个节点。

如果挂掉的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以主节点挂掉的第一件事情就是选举一个新的主节点： Node 2 选中为主节点

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

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

---

进阶 : 路由计算 & 分片控制 (协调节点)

路由计算

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个主分片中呢？

当我们创建文档时，它如何决定这个文档应当被存储在主分片1还是主分片2中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

shard = hash(routing) % number_of_primary_shards (主分片数量)

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

分片控制 (协调节点)

我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求(因为每个节点的分片都有副本,针对于上图)。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。

在下面的例子中，如果将所有的请求发送到Node 1001，我们将其称为 协调节点coordinating node。

为什么会存在协调节点,因为上面也说了, 假如zhangsan这个文档, 通过路由计算,存储到了Node-1003节点的P2主分片上, Node1和Node2的R2,R2也都会同步主分片上的数据。

这样的话我们请求哪个节点都可以索引到zhangsan这个文档。但是这样也会存在一个问题, 比如正好请求到Node-1节点,但是它现在CPU很高,检索能力比较差。此时Node-1节点就可以充当协调节点,将请求转发到其他节点上

当发送查询请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。轮询到节点也称为协调节点, 该节点收到客户端查询请求后,会把查询子句分发到其它的节点，然后合并各个节点返回的查询结果，最后返回一个完整的数据集给用户

进阶 : 数据写流程

新建文档、索引文档和删除文档请求都是写操作， 必须在主分片上面完成之后才能被复制到相关的副本分片。

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很少使用，因为 Elasticsearch 已经很快，但是为了完整起见， 请参考下文：

进阶 : 数据读流程

下图分析

• 当查询请求到了,首先通过轮询,来找到一个节点充当协调节点,请求到协调节点
• 协调节点通过请求的DSL语句, 计算文档所在的主分片和副本分片,所在的节点
• 文档所在的所有节点,通过轮询策略,将请求转发到其他节点上
• 节点返回到查询文档后, 结果返回给客户端
  

在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。

进阶 : 数据更新流程

部分更新一个文档结合了先前说明的读取和写入流程：

部分更新一个文档的步骤如下：

• 客户端向Node1发送更新请求 (此时Node1就是协调节点)。
• 它将请求转发到主分片所在的Node 3 。
• Node 3从主分片检索文档(读操作)，修改_source字段中的JSON。如果文档已经被另一个进程修改,它会重试步骤3 ,超过retry_on_conflict次后放弃。
• 如果 Node 3成功地更新文档，它将新版本的文档并行转发到Node 1和 Node 2上的副本分片，重新建立索引。一旦所有副本分片都返回成功，Node 3向协调节点也返回成功，协调节点向客户端返回成功。

进阶 : 倒排索引

• Elasticsearch使用一种称为倒排索引的结构，它适用于快速的全文搜索。

• 见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引（forward index），反向索引（inverted index）更熟悉的名字是倒排索引。

• 所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件ID，搜索时将这个ID和搜索关键字进行对应，形成K-V对，然后对关键字进行统计计数。
  
  但是互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回排名结果的要求。所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词。
  

倒排索引例子