分布式ElasticSearch简单介绍

这里我们解释一些通用的术语，比如集群(cluster)、节点(node)和分片(shard)。Elasticsearch的扩展机制，以及它怎样处理硬件故障。在此将探索怎样创建你的集群(cluster)、节点(node)和分片(shards)，使其依照你的需求进行扩展。并保证在硬件故障时数据依然安全。

一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有同样的cluster.name。它们协同工作，分享数据和负载。

当增加新的节点或者删除一个节点时，集群就会感知到并平衡数据。

集群中一个节点会被选举为主节点(master),它将暂时管理集群级别的一些变更，比如新建或删除索引、添加或移除节点等。主节点不參与文档级别的变更或搜索，这意味着在流量增长的时候。该主节点不会成为集群的瓶颈。不论什么节点都能够成为主节点。我们样例中的集群仅仅有一个节点，所以它会充当主节点的角色。

做为用户。我们可以与集群中的不论什么节点通信。包含主节点。每个节点都知道文档存在于哪个节点上，它们可以转发请求到对应的节点上。我们訪问的节点负责收集各节点返回的数据。最后一起返回给client。

这一切都由Elasticsearch处理。

集群健康

在Elasticsearch集群中能够监控统计非常多信息。可是仅仅有一个是最重要的：集群健康(cluster health)。集群健康有三种状态：green、yellow或red。

GET /_cluster/health

在我这里能够看到：

{

   "cluster_name": "elasticsearch",

   "status": "yellow",

   "timed_out": false,

   "number_of_nodes": 1,

   "number_of_data_nodes": 1,

   "active_primary_shards": 10,

   "active_shards": 10,

   "relocating_shards": 0,

   "initializing_shards": 0,

   "unassigned_shards": 10,

   "number_of_pending_tasks": 0,

   "number_of_in_flight_fetch": 0

}

status字段提供一个综合的指标来表示集群的的服务状况。

三种颜色各自的含义：

颜色	意义
green	全部主要分片和复制分片都可用
yellow	全部主要分片可用，但不是全部复制分片都可用
red	不是全部的主要分片都可用

在接下来将说明什么是主要分片(primary shard)和复制分片(replica shard)，并说明这些颜色（状态）在实际环境中的意义。

为了将数据加入到Elasticsearch。我们须要索引(index)——一个存储关联数据的地方。

实际上。索引仅仅是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical
namespace)”.

一个分片(shard)是一个最小级别“工作单元(worker unit)”,它仅仅是保存了索引中全部数据的一部分。

在接下来的《深入分片》一章。我们将具体说明分片的工作原理，可是如今我们仅仅要知道分片就是一个Lucene实例，而且它本身就是一个完整的搜索引擎。

我们的文档存储在分片中。而且在分片中被索引，可是我们的应用程序不会直接与它们通信，取而代之的是，直接与索引通信。

分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小。Elasticsearch将会自己主动在你的节点间迁移分片，以使集群保持平衡。

分片能够是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每一个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。

理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量全然取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、怎样索引和查询你的文档，以及你期望的响应时间。

复制分片仅仅是主分片的一个副本，它能够防止硬件故障导致的数据丢失，同一时候能够提供读请求。比方搜索或者从别的shard取回文档。

当索引创建完毕的时候。主分片的数量就固定了，可是复制分片的数量能够随时调整。

集群的健康状态yellow表示全部的主分片(primary shards)启动而且正常执行了——集群已经能够正常处理不论什么请求——可是复制分片(replica shards)还没有全部可用。

其实全部的三个复制分片如今都是unassigned状态——它们还未被分配给节点。在同一个节点上保存同样的数据副本是没有必要的，假设这个节点故障了，那全部的数据副本也会丢失。

如今我们的集群已经功能完备，可是依然存在因硬件故障而导致数据丢失的风险。

在单一节点上执行意味着有单点故障的风险——没有数据备份。

幸运的是，要防止单点故障。我们唯一须要做的就是启动还有一个节点。文档的索引将首先被存储在主分片中，然后并发拷贝到相应的复制节点上。

这能够确保我们的数据在主节点和复制节点上都能够被检索。

这样以来我们的集群不仅是功能完备的，并且是高可用的。

随着应用需求的增长，我们该怎样扩展？假设我们启动第三个节点，我们的集群会又一次组织自己。

分片本身就是一个完整的搜索引擎。它能够使用单一节点的全部资源。

假设我们拥有6个分片（3个主分片和三个复制分片），最多能够扩展到6个节点，每一个节点上有一个分片，每一个分片能够100%使用这个节点的资源。