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节点的配置如下（elasticsearch.yml）

1. 数据节点

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

1. 协调节点

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

注意：

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

2、索引分片

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. 解决方案

场景分析

一个生产环境的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随时修改的，特别是在节点上线和下线的时候，都需要作出对应的修改。而且一旦修改过后，   这个配置就会持久化保存下来。

5、集群扩展

1. 横向扩展

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

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

1. 继续扩展

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

更新副本数量：

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

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

6、故障转移

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

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

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

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

从图可知：

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

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