1-EleasticSearch高可用集群核心原理

一、ES集群的相关概念

ES集群是一个 P2P类型(使用 gossip 协议)的分布式系统，除了集群状态管理以外，其他所有的请求都可以发送到集群内任意一台节点上，这个节点可以自己找到需要转发给哪些节点，并且直接跟这些节点  通信。所以，从网络架构及服务配置上来说，构建集群所需要的配置极其简单。在 Elasticsearch 2.0  之前，无阻碍的网络下，所有配置了相同 cluster.name 的节点都自动归属到一个集群中。2.0 版本之后， 基于安全的考虑避免开发环境过于随便造成的麻烦，从 2.0 版本开始，默认的自动发现方式改为了单播(unicast)方式。配置里提供几台节点的地址，ES 将其视作 gossip router 角色，借以完成集群的发现。由于这只是 ES 内一个很小的功能，所以 gossip router 角色并不需要单独配置，每个 ES 节点都可以担任。所以，采用单播方式的集群，各节点都配置相同的几个节点列表作为 router 即可。

集群中节点数量没有限制，一般大于等于2个节点就可以看做是集群了。一般处于高性能及高可用方  面来考虑一般集群中的节点数量都是3个及3个以上。

1. 集群 cluster

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

1. 节点 node

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

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

在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运行任何

Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。

1. 分片和副本 shards&replicas

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

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

至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户  的你来说，这些都是透明的。

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

副本之所以重要，有两个主要原因：    在分片/节点失败的情况下，提供了高可用性。因为这个原因，注 意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。扩展你的搜索量/       吞吐量，因为搜索可以在所有的复制上并行运行。总之，每个索引可以被分成多个分片。一个索引也可  以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的    分片）和副本分片（主分片的拷贝）之别。分片和副本的数量可以在索引创建的时候指定。在索引创建  之后，你可以在任何时候动态地改变副本的数量，但是你事后不能改变分片的数量。

默认情况下，Elasticsearch中的每个索引被分片5个主分片和1个副本，这意味着，如果你的集群中至少   有两个节点，你的索引将会有5个主分片和另外5个副本分片（1个完全拷贝），这样的话每个索引总共   就有10个分片。

二、集群搭建及使用

1、集群搭建

略

2、集群的使用

使用方法同单机版
三、ES集群核心原理

 

1、节点类型

1）master节点

master节点特点：

整个集群只会有一个master节点，它将负责管理集群范围内的所有变更，例如增加、删除索引；或者增    加、删除节点等。而master节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个master节点的情况下，即使流量的增加它也不会成为瓶颈。 master节点需要从众多候选master节点中选择一个。

master节点的作用：

负责集群节点上下线，shard分片的重新分配。 创建、删除索引。 负责接收集群状态(`cluster state`)的变化，并推送给所有节点。集群节点都各有一份完整的cluster state，只是master node负责维护。 利用自身空闲资源，协调创建索引请求或者查询请求，将请求分发到相关node服务器。

master节点的配置如下（elasticsearch.yml）

node.master: true node.data: false

1. 数据节点

负责存储数据，提供建立索引和搜索索引的服务。 data节点消耗内存和磁盘IO的性能比较大。

data节点的配置如下（elasticsearch.yml）

node.master: false node.data: true

1. 协调节点

不会被选作主节点，也不会存储任何索引数据。主要用于查询负载均衡。将查询请求分发给多个node服务    器，并对结果进行汇总处理。 协调节点的作用： 第一：诸如搜索请求或批量索引请求之类的请求可能涉及保存在不同数据节点上的数据。    例如，搜索请求在两个阶段中执行（query 和 fetch），这两个阶段由接收客户端请求的节点 - 协调节点协调。 第二：在请求阶段，协调节点将请求转发到保存数据的数据节点。    每个数据节点在本地执行请求并将其结果返回给协调节点。 在收集fetch阶段，协调节点将每个数据节点的结果汇集为单个全局结果集。 第三：每个节点都隐式地是一个协调节点。 这意味着将所有三个node.master，node.data设置为false的节点作为仅用作协调节点，无法禁用该节点。    结果，这样的节点需要具有足够的内存和CPU以便处理收集阶段。 6 7  协调节点最好不要分离，跟数据节点在一起就行。

协调节点的配置如下（elasticsearch.yml）

node.master: false node.data: false

注意：

一个节点可以充当一个或多个角色。默认 3个角色都有。

2、索引分片

分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然         后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间         迁移分片，以使集群保持平衡。 属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据，每一个分片都是一个搜索 引擎。 # 分片详情(文档存储、主分片、分片引擎) 分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档 属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据，每一个分片都是一个搜索 引擎。      # 分片存储大小限制         •   理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量完  全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期    望的响应时间。     # 副本分片作用 •   复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比  如搜索或者从别的shard取回文档。 # 主分片数量及 副本分片数量       •   当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

3、集群选举

选举的时机

master选举当然是由master-eligible节点发起，当一个master-eligible节点发现满足以下条件时发起选举：

1. 1. 该master-eligible节点的当前状态不是master。并且该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点，没有任何节点连接到master。
   2. 包括本节点在内，当前已有超过minimum_master_nodes 个节点没有连接到master。

总结一句话，即当一个节点发现包括自己在内的多数派的master-eligible节点认为集群没有master时，     就可以发起master选举。

选举的过程

先根据节点的clusterStateVersion比较，clusterStateVersion越大，优先级越高。clusterStateVersion 相同时，进入compareNodes，其内部按照节点的Id比较(Id为节点第一次启动时随机生成)。

1. 1. 当clusterStateVersion越大，优先级越高。这是为了保证新Master拥有最新的clusterState(即集    群的meta)，避免已经commit的meta变更丢失。因为Master当选后，就会以这个版本的clusterState为基础进行更新。(一个例外是集群全部重启，所有节点都没有meta，需要先选出一  个master，然后master再通过持久化的数据进行meta恢复，再进行meta同步)。
   2. 当clusterStateVersion相同时，节点的Id越小，优先级越高。即总是倾向于选择Id小的Node，这个Id是节点第一次启动时生成的一个随机字符串。之所以这么设计，应该是为了让选举结果尽可能  稳定，不要出现都想当master而选不出来的情况。

4、脑裂问题

1. 什么是脑裂现象

由于部分节点网络断开，集群分成两部分，且这两部分都有master选举权。就成形成一个与原集群一样  名字的集群，这种情况称为集群脑裂（split-brain）现象。这个问题非常危险，因为两个新形成的集群    会同时索引和修改集群的数据。

1. 解决方案

# 决定选举一个master最少需要多少master候选节点。默认是1。 # 这个参数必须大于等于为集群中master候选节点的quorum数量，也就是大多数。 # quorum算法：master候选节点数量 / 2 + 1 # 例如一个有3个节点的集群，minimum_master_nodes 应该被设置成 3/2 + 1 = 2（向下取整） discovery.zen.minimum_master_nodes:2 #  等待ping响应的超时时间,默认值是3秒。如果网络缓慢或拥塞，会造成集群重新选举，建议略微调大这个值。 # 这个参数不仅仅适应更高的网络延迟，也适用于在一个由于超负荷而响应缓慢的节点的情况。 discovery.zen.ping.timeout:10s #  当集群中没有活动的Master节点后，该设置指定了哪些操作（read、write）需要被拒绝（即阻塞执行）。有两个设置值：all和write，默认为wirte。 discovery.zen.no_master_block : write

场景分析

一个生产环境的es集群，至少要有3个节点，同时将discovery.zen.minimum_master_nodes设置为

2， 那么这个是参数是如何避免脑裂问题的产生的呢？

比如我们有3个节点，quorum是2。现在网络故障，1个节点在一个网络区域，另外2个节点在另    外一个网络区域，不同的网络区域内无法通信。这个时候有两种情况情况：

1. 1. 如果master是单独的那个节点，另外2个节点是master候选节点，那么此时那个单独的master节点因为没有指定数量的候选master node在自己当前所在的集群内，因此就会取消当前master的角色，尝试重新选举，但是无法选举成功。然后另外一个网络区域内的node因为无法连    接到master，就会发起重新选举，因为有两个master候选节点，满足了quorum，因此可以成功选举出一个master。此时集群中就会还是只有一个master。
   2. 如果master和另外一个node在一个网络区域内，然后一个node单独在一个网络区域内。那    么此时那个单独的node因为连接不上master，会尝试发起选举，但是因为master候选节点数量不到quorum，因此无法选举出master。而另外一个网络区域内，原先的那个master还会继续工作。这也可以保证集群内只有一个master节点。

综上所述，通过在elasticsearch.yml 中配置discovery.zen.minimum_master_nodes: 2 ，就可以避免脑裂问题的产生。

但是因为ES集群是可以动态增加和下线节点的，所以可能随时会改变quorum 。所以这个参数也是可以通过api随时修改的，特别是在节点上线和下线的时候，都需要作出对应的修改。而且一旦修改过后，   这个配置就会持久化保存下来。

1  PUT /_cluster/settings { "persistent" : { "discovery.zen.minimum_master_nodes" : 2 } }

5、集群扩展

1. 横向扩展

一个索引可以存储超出单个结点硬件限制的大量数据。

# 问题：随着应用需求的增长，我们该如何扩展？ 如果我们启动第三个节点，我们的集群会重新组织自己。分片已经被重新分配以平衡负载 3 4  Node3 包含了分别来自 Node 1 和 Node 2 的一个分片，这样每个节点就有两个分片，和之前相比少了一个，这意味着每个节点上的分片将获得更多的硬件资源（CPU、RAM、I/O）

 

注意：分片本身就是一个完整的搜索引擎，它可以使用单一节点的所有资源。我们拥有6个分片（3个  主分片和三个复制分片），最多可以扩展到6个节点，每个节点上有一个分片，每个分片可以100%使用 这个节点的资源。

1. 继续扩展

如果我们要扩展到6个以上的节点，要怎么做？

主分片的数量在创建索引时已经确定。实际上，这个数量定义了能存储到索引里数据的最大数量（实  际的数量取决于你的数据、硬件和应用场景）。        然而，主分片或者复制分片都可以处理读请求——搜索或文档检索，所以数据的冗余越多，我们能处   理的搜索吞吐量就越大。复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩    大或者缩小规模。让我们把复制分片的数量从原来的 1 增加到 2 ：

更新副本数量：

# 更新副本数量 PUT /blogs/_settings 3  { 4  "number_of_replicas" : 2 5  }

从图中可以看出，  索引现在有9个分片：3个主分片和6个复制分片。这意味着我们能够扩展到9个节点，再次变成每个节点一个分片。这样使我们的搜索性能相比原始的三节点集群增加三倍。

当然，在同样数量的节点上增加更多的复制分片并不能提高性能，因为这样做的话平均每个分片的所  占有的硬件资源就减少了（大部分请求都聚集到了分片少的节点，导致一个节点吞吐量太大，反而降低 性能），你需要增加硬件来提高吞吐量。不过这些额外的复制节点使我们有更多的冗余：通过以上对节 点的设置，我们能够承受两个节点故障而不丢失数据。

6、故障转移

ES有两种集群故障探查机制：

1. 1. 通过master进行的，master会ping集群中所有的其他node，确保它们是否是存活着的。
   2. 每个node都会去ping master来确保master是存活的，否则会发起一个选举过程。

有下面三个参数用来配置集群故障的探查过程：

ping_interval : 每隔多长时间会ping一次node，默认是1s ping_timeout : 每次ping的timeout等待时长是多长时间，默认是30s ping_retries : 如果一个node被ping多少次都失败了，就会认为node故障，默认是3次

 

分片不会放在同一个节点上

从图可知：

1. 每个索引被分成了5个分片；
2. 每个分片有一个副本；

3）5个分片基本均匀分布在3个dataNode上；

注意分片的边框（border）有粗有细，具体区别是： 粗边框代表：primary（true）

细边框代表：replica

演示负载均衡效果： 关闭集群中其中一个节点，剩余分片将会重新进行均衡分配。