Elasticsearch集群

Elasticsearch集群简介

一个集群就是由一个或多个节点组织在一起，它们共同持有整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是 “elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。在产品环境中显式地设定这个名字是一个好习惯，但是使用默认值来进行测试/开发也是不错的。

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

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

在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运行任何Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。

Elasticsearch集群要达到基本高可用，一般要至少启动3个节点，3个节点互相连接，单个节点包括所有角色，其中任意节点停机集群依然可用。为什么要至少3个节点？因为集群选举算法奇数法则。

Elasticserach管理节点职责是管理集群元数据、索引信息、节点信息等，自身不涉及数据存储与查询，资源消耗低；相反数据节点是集群存储与查询的执行节点。管理节点与数据节点分离，各司其职，任意数据节点故障或者全部数据节点故障，集群仍可用；管理节点一般至少启动3个，任意节点停机，集群仍正常运行。

Elasticsearch内部执行查询或者更新操作时，需要路由，默认所有节点都具备此职能，特别是大的查询时，协调节点需要分发查询命令到各个数据节点，查询后的数据需要在协调节点合并排序，这样原有数据节点代价很大，所以分离职责

Elasticsearch设置读写分离指的是在协调节点上，不是数据节点上，集群大量的查询需要消耗协调节点很大的内存与CPU合并结果，同时集群大量的数据写入会阻塞协调节点，所以在协调节点上做读写分离很少必要，也很简单，由集群设计搭建时规划好

Elasticsearch给数据节点标签，目的是分离索引数据的分布，在一个集群规模中等以上，索引数据用途多种多样，对于数据节点的资源需求不一样，数据节点的配置可以差异化，有的数据节点配置高做实时数据查询，有的数据节点配置低做历史数据查询，有的数据节点做专门做索引重建。Elasticsearch集群部署时需要考虑基础硬件条件，集群规模越来越大，需要多个数据中心，多个网络服务、多个服务器机架，多个交换机等组成，索引数据的分布与这些基础硬件条件都密切相关。

Elasticsearch集群规模大了之后得考虑集群容灾，若某个机房出现故障，则可以迅速切换到另外的容灾机房。

分片和复制（shards & replicas）

一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片之所以重要，主要有两方面的原因：

允许你水平分割/扩展你的内容容量
允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量
至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户的你来说，这些都是透明的。

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

复制之所以重要，有两个主要原因：

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

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

index: es里的index相当于一个数据库。

type: 相当于数据库里的一个表。

id： 唯一，相当于主键。

node:节点是es实例，一台机器可以运行多个实例，但是同一台机器上的实例在配置文件中要确保http和tcp端口不同（下面有讲）。

cluster:代表一个集群，集群中有多个节点，其中有一个会被选为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。

shards：代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上，构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

replicas:代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当个某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率，es会自动对搜索请求进行负载均衡。

实战建议：对生产环境中，分片设置很重要，需要最好容量评估与规划

根据数据容量评估分配数，设置过小，后续无法水平扩展；单分片数据量太大，也容易导致数据分片耗时严重

分片数设置如果太大，会导致资源浪费，性能降低；同时也会影响搜索结果打分和搜索准确性

可扩展

随着公司业务发展，Elasticsearch 也面临两个挑战：

搜索数据量从百万到亿量级

搜索请求 QPS 也猛增

那么需要将原来节点和增量数据重新从 10 个节点分布到 100 个节点。Elasticsearch 可以横向扩展至数百（甚至数千）的服务器节点，同时可以处理PB级数据。Elasticsearch 为了可扩展性而生，由小规模集群增长为大规模集群的过程几乎完全自动化，这是水平扩展的体现。

部分节点停止服务，整个集群服务不受影响，照样正常提供服务

Elasticsearch 在后台自动完成了分布式相关工作，如下：

自动分配文档到不同分片或者多节点上

均衡分配分片到集群节点上，index 和 search 操作时进行负载均衡

复制每个分片，支持数据冗余，防止硬件故障数据丢失

集群扩容时，无缝整合新节点，并且重新分配分片

Elasticsearch 集群知识点如下：

不同集群通过名字区分，默认集群名称为 “elasticsearch”

集群名 cluster name ，可以通过配置文件修改或者 行 -E cluster.name=user-es-cluster 进行设置一个集群由多个节点组成

Elasticsearch集群容灾

Elasticsearch 在高可用性上，体现如下两点：

服务可用性：允许部分节点停止服务，整体服务没有影响

数据可用性：允许部分节点丢失，最终不会丢失数据

Elasticsearch单个集群规模不能无限增长，理论上可以，实际很危险，通过创建多个分集群分解，集群直接建立直接连接，客户端可以通过一个代理集群访问任意集群，包括代理集群本身数据。Elasticsearch集群支持异地容灾，采用的是跨集群复制的机制，与同一集群主分片副本分片分离是不同的概念，2个集群完全是独立部署运行，仅数据同步复制。

动态维护参与选举的节点列表（集群成员变化）

集群扩容，缩容，节点临时或永久离线时是如何处理的。在7.x 之前的版本中，用户需要手工配置 discovery.zen.minimum_master_nodes，来明确告诉集群过半节点数应该是多少，并在集群扩缩容时调整他。现在，集群可以自行维护。

在取消了discovery.zen.minimum_master_nodes配置后，ES 如何判断多数？是自己计算和维护minimum_master_nodes值么？不，现在的做法不再记录“quorum” 的具体数值，取而代之的是记录一个节点列表，这个列表中保存所有具备 master 资格的节点（有些情况下不是这样，例如集群原本只有1个节点，当增加到2个的时候，这个列表维持不变，因为如果变成2，当集群任意节点离线，都会导致无法选主。这时如果再增加一个节点，集群变成3个，这个列表中就会更新为3个节点），称为 VotingConfiguration，他会持久化到集群状态中。

在节点加入或离开集群之后，Elasticsearch会自动对VotingConfiguration做出相应的更改，以确保集群具有尽可能高的弹性。在从集群中删除更多节点之前，等待这个调整完成是很重要的。你不能一次性停止半数或更多的节点。

通过下面的命令查看集群当前的 VotingConfiguration

curl -X GET “localhost:9200/_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config&pretty”

默认情况下，ES 自动维护VotingConfiguration，有新节点加入的时候比较好办，但是当有节点离开的时候，他可能是暂时的重启，也可能是永久下线。你也可以人工维护 VotingConfiguration，配置项为：cluster.auto_shrink_voting_configuration，当你选择人工维护时，有节点永久下线，需要通过 voting exclusions API 将节点排除出去。如果使用默认的自动维护VotingConfiguration，也可以使用 voting exclusions API 来排除节点，例如一次性下线半数以上的节点。

如果在维护VotingConfiguration时发现节点数量为偶数，ES 会将其中一个排除在外，保证 VotingConfiguration是奇数。因为当是偶数的情况下，网络分区将集群划分为大小相等的两部分，那么两个子集群都无法达到“多数”的条件。

ES 可以在集群节点增减的时候自动维护VotingConfiguration，但是他需要一个初始化配置，也就是说在第一次的时候你必须明确告诉 ES，VotingConfiguration中都有哪些节点。

节点切换集群

曾经有一个节点在 A 集群，现在要把他加入到 B 集群，如何操作？在 ES 7.x之前的版本中，直接修改集群名称和发现地址就可以，现在由于选举算法的差异，需要以下操作：

删除节点/data/nodes/0/_state目录。
集群名称改成相同
cluster.initial_master_nodes配置修改成一致，或者删除该配置
启动节点