es基础（二)——分布式集群

1. 集群和节点

如果我们启动一个单独的节点，它还没有数据和索引，这个集群看起来就像下图。

一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有相同的 cluster.name ， 它们协同工作，分享数据和负载。当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据。

集群中一个节点会被选举为主节点(master),它将临时管理集群级别的一些变更，例如新建或删除索引、增加或移除节点等。 主节点不参与文档级别的变更或搜索，这意味着在流量增长的时候，该主节点不会成为集群的瓶颈。任何节点都可以成为主 节点。

做为用户，我们能够与集群中的任何节点通信，包括主节点。每一个节点都知道文档存在于哪个节点上，它们可以转发请求 到相应的节点上。我们访问的节点负责收集各节点返回的数据，最后一起返回给客户端。这一切都由Elasticsearch处理。

2. 集群健康

在Elasticsearch集群中可以监控统计很多信息，但是只有一个是最重要的：集群健康(cluster health)。
集群健康有三种状 态： green 、 yellow 或 red 。

GET /_cluster/health

3. 添加索引

索引只是一个用来指向一个 或多个分片(shards)的“逻辑命名空间(logical namespace)”

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

现在我们只要知道分片就是一个Lucene实例，并且它本身就是一个完整的 搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是，直 接与索引通信。

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

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

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

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

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整

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

我们的集群现在看起来就像下图——三个主分片都被分配到 Node 1

此时的集群的健康状态为 yellow ，表示所有的主分片(primary shards)启动并且正常运行了——集群已经可以正常处理任何请求——但 是复制分片(replica shards)还没有全部可用。事实上所有的三个复制分片现在都是 unassigned 状态——它们还未被分配给 节点。在同一个节点上保存相同的数据副本是没有必要的，如果这个节点故障了，那所有的数据副本也会丢失。

4. 增加故障转移

在单一节点上运行意味着有单点故障的风险——没有数据备份。幸运的是，要防止单点故障，我们唯一需要做的就是启动另 一个节点。

只要第二个节点与第一个节点有相同的 cluster.name （请看 ./config/elasticsearch.yml 文件），它就能自动发现并加 入第一个节点所在的集群。如果没有，检查日志找出哪里出了问题。这可能是网络广播被禁用，或者防火墙阻止了节 点通信。

第二个节点已经加入集群，三个复制分片(replica shards)也已经被分配了——分别对应三个主分片，这意味着在丢失任意一 个节点的情况下依旧可以保证数据的完整性。

文档的索引将首先被存储在主分片中，然后并发复制到对应的复制节点上。这可以确保我们的数据在主节点和复制节点上都 可以被检索。

cluster-health 现在的状态是 green ，这意味着所有的6个分片（三个主分片和三个复制分片）都已可用

我们的集群不仅是功能完备的，而且是高可用的。

5. 横向扩展

随着应用需求的增长，我们该如何扩展？如果我们启动第三个节点，我们的集群会自我感知，这时便成为了三节点集群 (cluster-three-nodes)

6. 更多扩展

主分片的数量在创建索引时已经给定，不能变，复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩大或者缩小规模。

让我们增加复制分片的数 量，从原来的 1 变成 2 ：

7. 应对故障

我们已经说过Elasticsearch可以应对节点失效，所以让我们继续尝试。如果我们杀掉第一个节点的进程（以下简称杀掉节点）

我们杀掉的节点是一个主节点。必须有一个主节点来让集群的功能可用，所以发生的第一件事就是各节点选举了一个新的主 节点： Node 2 。

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

幸运的是丢失的两个主分片的完整拷贝在其他节点上还存在，所以新主节点的第一件事是提升这些在 Node 2 和 Node 3 上的 分片的副本为主分片，集群健康回到 yellow 状态。这个提升是瞬间完成的，就好像按了一下开关。

为什么集群健康状态是 yellow 而不是 green ？我们有三个主分片，但是我们指定了每个主分片对应两个复制分片，当前却只 有一个被定义。这阻止我们达到 green 状态，不过不用太担心这个：当我们杀掉 Node 2 ，我们的程序依旧可以在没有丢失数 据的情况下运行，因为 Node 3 还有每个分片的拷贝。

如果我们重启 Node 1 ，集群将能够分配丢失的复制分片，结果状态与三主节点双复制一致。如果 Node 1 依旧有旧节点的拷 贝，它将会尝试再利用它们，它只会复制在故障期间数据变更的部分。

摘自：es权威指南