[Elasticsearch] 集群的工作原理 - 第一部分

本文翻译自Elasticsearch官方指南的life inside a cluster一章。

ES就是为高可用和可扩展而生的。

扩展能够通过购置性能更强的server(垂直扩展或者向上扩展，Vertical Scale/Scaling Up)，亦或是通过购置很多其它的server(水平扩展或者向外扩展，Horizontal Scale/Scaling Out)来完毕。

虽然ES可以利用更强劲的硬件。垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展 - 通过向集群中加入很多其它的节点来分布负载，添加可靠性。

在大多数数据库中，水平扩展通常都须要你相应用进行一次大的重构来利用很多其它的节点。相反。ES天生就是分布式的：它知道怎样管理多个节点来完毕扩展和实现高可用性。

这也意味着你的应用不须要在乎这一点。

在本章中，我们会介绍怎样建立集群(Cluster)，节点(Node)和分片(Shard)来依据你的需求完毕扩展，同一时候也可以保证即使发生硬件故障你的数据也会安然无恙。

一个空的集群

假设我们启动了一个没有不论什么数据和索引的节点(Node)，我们的集群(Cluster)看起来就像以下这样：

一个节点会执行一个ES的实例。而一个集群则会包括拥有同样cluster.name的一个或者多个节点。这些节点共同工作来完毕数据共享和负载分担。

随着节点被加入到集群，或者从集群中被删除，集群会通过自身调节来将数据均匀分布。

集群中的一个节点会被选为主节点(Master Node)。它负责管理整个集群的变化。如创建或者删除一个索引(Index)。向集群中加入或者删除节点。主节点并不须要參与到文档级别的变化或者搜索中，这意味着尽管仅仅有一个主节点，但它并不会随着流量的添加而成为瓶颈。

不论什么节点都能够成为主节点。

在我们的样例中仅仅有一个节点，所以它就承担了主节点的功能。

对于用户，可以和集群中的随意节点进行通信，包含主节点。每一个节点都知道每份文档的存放位置，而且可以将请求转发到持有所需数据的节点。

用户通信的节点会负责将须要的数据从各个节点收集起来，然后返回给用户。以上整个过程都会由ES透明地进行管理。

集群健康指标(Cluster Health)

在一个ES集群中。有非常多能够被监測的统计数据，可是当中最重要的是集群健康指标。它会以green，yellow和red来报告集群的健康状态。

# Retrieve the cluster health
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：全部的主分片(Primary Shard)和副本分片(Replica Shard)都处于活动状态
• yellow：全部的主分片都处于活动状态，可是并非全部的副本分片都处于活跃状态
• red：不是全部的主分片都处于活动状态

在本章剩下的部分中，我们会解释什么是主分片和副本分片，以及以上的几种颜色状态信息所带来的实际影响。

加入索引

为了向ES中加入数据，我们须要一个索引(Index) - 它是一个用来存储相关数据的地方。

实际上，一个索引实际上仅仅是一个"逻辑命名空间(Logical Namespace)"，用来指向一个或者多个物理分片(Physical Shard)。

一个分片就是底层的"工作单元(Worker Unit)"。它拥有索引中全部数据的一部分。在分片一章中，会对分片的工作方式进行具体说明，可是就如今而言，我们仅仅须要知道一个分片就是一个Lucene的实例，一个分片本身就是一个完整的搜索引擎。

我们的文档会被存储和索引在分片中，可是应用是不会直接和分片进行交互的。相反地，应用和索引进行交互。

ES通过分片将数据分布在集群中。可以将分片想象成数据的容器。文档会被存储在分片中。而分片则会被分配到集群中的节点中。随着集群的扩大和虽小，ES会自己主动地将分片在节点之间进行迁移。以保证集群可以保持一种平衡。

一个分片可以是主分片(Primary Shard)或者副本分片(Replica Shard)。索引中的每份文档都属于一个主分片，所以主分片的数量就决定了你的索引可以存储的最大数据量。

虽然在理论上，一个主分片可以容纳的最大数据量并没有限制，可是在实际生产中这个限制是存在的。

分片的最大空间全然取决于你的用例：硬件条件，文档的大小和复杂度，怎样索引和查询文档。以及期望的响应时间。

一个副本分片则仅仅是一个主分片的拷贝。副本用来提供数据冗余，用来保护数据在发生硬件故障是不会丢失，同一时候也可以处理像搜索和获取文档这种读请求。

主分片的数量在索引建立之初就会被确定下来，而副本分片的数量则能够在不论什么时候被更改。

让我们在当前仅仅有一个节点的集群中创建一个新的blogs索引。默认情况下。索引会拥有5个主分片。可是为了演示，我们会让索引有3个主分片和1个副本分片(每一个主分片都有1个副本分片)：

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 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 
}

集群的健康状态变成了黄色，同一时候响应中还说明了有3个未被分配的分片。

黄色说明了全部的主分片都正在正常执行，处于活动状态 - 集群如今可以成功处理来自外部的请求 - 可是并非全部的副本分片都处于活动状态。实际上，全部的3个副本分片眼下都处于"未分配"的状态 - 它们不存在于不论什么节点上。这是由于将同样数据的拷贝存放在同一节点上是没有意义的。

假设我们失去了该节点。那么我们会失去全部数据和它们的拷贝。

因此当前我们的集群可以正常工作，仅仅只是抵御不了硬件故障带来的风险。