ElasticseArch cluster internal workings

用 Elasticsearch 的时候可以长时间都不必担心 shard、 replicate、 failover ——但是它会帮助你理解Elasticsearch内部的工作流程

Elasticsearch 通过增加 node 来均摊负载和增加可靠性。

Elasticsearch 天生就是分布式的：它知道如何管理节点来提供高扩展和高可用。这意味着你的程序不需要关心这些。

2.1 Empty cluster

只有一个空节点的集群

一个 node 就是一个 Elasticsearch实例. cluster 中的多个 node，they have the same cluster.name.
它们协同工作，分享数据和负载。当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据。

集群中一个 node 会被选举为 master, 它将临时管理 cluster level 的一些变更，例如 create index、add or del node 等。master 不参与 doc level 的变更或搜索，这意味着在流量增长的时候，该 master 不会成为集群的瓶颈。任何 node 都可以成为 master

As user，cluster any node 通信。每个 node 都知道文档存在于哪个node上，它们可以转发请求到相应的node上。我们访问的 node 负责收集 各nodes 返回的数据，最后一起返回给客户端。这一切都由 Elasticsearch 处理。

2.2 Cluster healthy

green、yellow、red。

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
}

2.3 Add index

index 只是一个用来指向多个 shards “LOGical namespace”.

一个shard是一个最小级别 “worker unit” ,它只是保存了 index 中所有数据的一部分。但是现在我们只要知道shard 就是一个Lucene实例，并且它本身就是一个完整的搜索引擎。我们的 doc 存储在 shard 中，并且在shard 中被索引，但是我们的应用程序不会直接与它们通信，而是，直接与 index 通信。

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

当index创建完成的时候，primary-shard 的数量就固定了，但是 replica-shard 的数量可以随时调整

当index创建完成的时候，primary-shard　的数量就固定了，但是 replica-shard 的数量可以随时调整。

让我们在集群中唯一一个空节点上创建一个叫做blogs的索引。默认情况下，一个索引被分配5个主分片，但是为了演示的目的，我们只分配3个 primary-shard 和一个 replica-shard（每个 primary-shard 都有一个replica-shard）：

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

{
   "cluster_name":          "elasticsearch",
   "status":                "yellow", <1>
   "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 <2>
}

事实上所有的 3 个 replica-shard 现在都是 unassigned状态——它们还未被分配给节点

2.4 Failover，横向扩展

故障转移

横向扩展

shard 本身就是一个完整的搜索引擎，它可以使用单一 node 的所有资源。我们拥有6个分片（3个 primary-shard and replica-shard），最多可以扩展到 6 个 node，每个node上有一个shard，每个 shard 可以100%使用这个节点的资源。

2.5 更多扩展

我们要扩展到6个以上的节点 begin...

primary-shard 的数量在create index 时已经确定。实际上，这个数量定义了能存储到索引里数据的最大数量（实际的数量取决于你的数据、硬件和应用场景）。然而，primary-shard or replica-shard 都可以处理读请求——搜索或文档检索，所以数据的冗余越多，我们能处理的搜索吞吐量就越大。2

复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩大或者缩小规模。让我们把replica-shard 的数量从原来的 1 增加到 2 ：

PUT /blogs/_settings
{
   "number_of_replicas" : 2
}

blogs 索引现在有9个分片：3 primary-shard 和 6 replica-shard。这意味着我们能够扩展到 9个 node，再次变成每个 node 一个 shard。这样理论上，搜索性能相比原始的 3node 集群增加三倍。

杀掉第一个节点后的集群

primary-shard 1 和 2 在我们杀掉 Node 1 时已经丢失，我们的 index 在丢失 primary-shard 时不能正常工作。如果此时我们检查集群健康，我们将看到状态 red ：不是所有 primary-shard 都可用！

幸运的是丢失的两个 primary-shard 的完整拷贝存在于其他节点上，所以 new primary-shard 做的第一件事是把这些在 Node 2 和 Node 3上的 replica-shard 升级为 primary-shard，这时集群健康回到 yellow 状态。

Reference articles

Elasticsearch权威指南