ElasticSearch 的主旨是随时可用和按需扩容。而扩容可以通过购买性能更强大（垂直扩容，或纵向扩容）或者数量更多的服务器（水平扩容，或横向扩容）来实现。
虽然 Elasticsearch 可以获益于更强大的硬件设备，但是垂直扩容是有极限的。真正的扩容能力是来自于水平扩容–为集群添加更多的节点，并且将负载压力和稳定性分散到这些节点中。
对于大多数的数据库而言，通常需要对应用程序进行非常大的改动，才能利用上横向扩容的新增资源。与之相反的是，ElastiSearch天生就是分布式的，它知道如何通过管理多节点来提高扩容性和可用性。这也意味着你的应用无需关注这个问题。
本章将讲述如何按需配置集群、节点和分片，并在硬件故障时确保数据安全。

空集群

如果我们启动了一个单独的节点，里面不包含任何的数据和索引，那我们的集群看起来就是一个 Figure 1, “包含空内容节点的集群”。
Elasticsearch（七）elasticsearch集群内原理
一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

集群健康

Elasticsearch 的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是集群健康，它在 status 字段中展示为 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
}
status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

green 所有的主分片和副本分片都正常运行。
yellow 所有的主分片都正常运行，但不是所有的副本分片都正常运行。
red 有主分片没能正常运行。
在本章节剩余的部分，我们将解释什么是主分片和副本分片，以及上面提到的这些颜色的实际意义。
Elasticsearch（七）elasticsearch集群内原理

添加索引

我们往 Elasticsearch 添加数据时需要用到索引 —— 保存相关数据的地方。
索引实际上是指向一个或者多个物理分片的逻辑命名空间。

一个分片是一个底层的工作单元，它仅保存了全部数据中的一部分。在分片内部机制中，我们将详细介绍分片是如何工作的，而现在我们只需知道一个分片是一个 Lucene 的实例，以及它本身就是一个完整的搜索引擎。我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。

Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。

技术上来说，一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档，但是实际最大值还需要参考你的使用场景：包括你使用的硬件，文档的大小和复杂程度，索引和查询文档的方式以及你期望的响应时长。

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。

让我们在包含一个空节点的集群内创建名为 blogs 的索引。索引在默认情况下会被分配5个主分片，但是为了演示目的，我们将分配3个主分片和一份副本（每个主分片拥有一个副本分片）：

PUT /blogs
{
“settings” : {
“number_of_shards” : 3,
“number_of_replicas” : 1
}
}
我们的集群现在是Figure 2, “拥有一个索引的单节点集群”。所有3个主分片都被分配在 Node 1 。

Elasticsearch（七）elasticsearch集群内原理
如果我们现在查看集群健康，我们将看到如下内容：
{
“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,
“delayed_unassigned_shards”: 0,
“number_of_pending_tasks”: 0,
“number_of_in_flight_fetch”: 0,
“task_max_waiting_in_queue_millis”: 0,
“active_shards_percent_as_number”: 50
}
集群 status 值为 yellow 。
“unassigned_shards”: 3 没有被分配到任何节点的副本数。

集群的健康状况为 yellow 则表示全部主分片都正常运行（集群可以正常服务所有请求），但是副本分片没有全部处在正常状态。实际上，所有3个副本分片都是 unassigned —— 它们都没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。

当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。

添加故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。幸运的是，我们只需再启动一个节点即可防止数据丢失。

如果启动了第二个节点，我们的集群将会如Figure 3, “拥有两个节点的集群——所有主分片和副本分片都已被分配”所示。
Elasticsearch（七）elasticsearch集群内原理
当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。

所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

cluster-health 现在展示的状态为 green ，这表示所有6个分片（包括3个主分片和3个副本分片）都在正常运行。
{
“cluster_name”: “elasticsearch”,
“status”: “green”,
“timed_out”: false,
“number_of_nodes”: 2,
“number_of_data_nodes”: 2,
“active_primary_shards”: 3,
“active_shards”: 6,
“relocating_shards”: 0,
“initializing_shards”: 0,
“unassigned_shards”: 0,
“delayed_unassigned_shards”: 0,
“number_of_pending_tasks”: 0,
“number_of_in_flight_fetch”: 0,
“task_max_waiting_in_queue_millis”: 0,
“active_shards_percent_as_number”: 100
}
集群 status 值为 green 。
我们的集群现在不仅仅是正常运行的，并且还处于始终可用的状态。

启动第二个节点

为了测试第二个节点启动后的情况，你可以在同一个目录内，完全依照启动第一个节点的方式来启动一个新节点（参考安装并运行 Elasticsearch）。多个节点可以共享同一个目录。

当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。

本地示例

完全按照第一个节点的方式启动一个新的节点

参考：
https://www.cnblogs.com/wxw16/p/6160186.html
将之前已安装好的elasticseach文件重新复制一份名为elasticsearch-5.3.0-node2
elasticsearch-5.3.0-node2的elasticsearch.yml中的节点名复制而来的111改为222（与第一个节点名不同即可）
以上做的原因是一个elasticsearch中只能有一个node，否则报错
elasticsearch-5.3.0-node2的data文件夹下所有内容清除
分别启动连接
Elasticsearch（七）elasticsearch集群内原理

本地集群健康查询现在显示：
Elasticsearch（七）elasticsearch集群内原理

配置一个可连接到的单播主机列表

最好使用单播代替组播
Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。

虽然组播仍然作为插件提供，但它应该永远不被使用在生产环境了，否在你得到的结果就是一个节点意外的加入到了你的生产环境，仅仅是因为他们收到了一个错误的组播信号。对于组播本身并没有错，组播会导致一些愚蠢的问题，并且导致集群变的脆弱（比如，一个网络工程师正在捣鼓网络，而没有告诉你，你会发现所有的节点突然发现不了对方了）。

使用单播，你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 master 节点，并加入集群。

这意味着你的单播列表不需要包含你的集群中的所有节点，它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。如果你使用 master 候选节点作为单播列表，你只要列出三个就可以了。这个配置在 elasticsearch.yml 文件中：

discovery.zen.ping.unicast.hosts: [“host1”, “host2:port”]
这个功能有防火墙，暂未实验。

水平扩容

怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将会看起来如Figure 4, “拥有三个节点的集群——为了分散负载而对分片进行重新分配”所示。
Elasticsearch（七）elasticsearch集群内原理
Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。
分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

应对故障

我们之前说过 Elasticsearch 可以应对节点故障，接下来让我们尝试下这个功能。如果我们关闭第一个节点，这时集群的状态为Figure 6, “关闭了一个节点后的集群”。

我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 2 。

在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。

幸运的是，在其它节点上存在着这两个主分片的完整副本，所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片，此时集群的状态将会为 yellow 。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

为什么我们集群状态是 yellow 而不是 green 呢？虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 Node 2 ，我们的程序依然可以保持在不丢任何数据的情况下运行，因为 Node 3 为每一个分片都保留着一份副本。

如果我们重新启动 Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将如Figure 5, “将参数 number_of_replicas 调大到 2”所示。如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。

到目前为止，你应该对分片如何使得 Elasticsearch 进行水平扩容以及数据保障等知识有了一定了解。接下来我们将讲述关于分片生命周期的更多细节。

总结

建立索引时，确定了主分片和副分片的数量，副分片数量可以修改。
假设新建blogs索引时设定它3个主分片，每个主分片1个副分片，即有3个主分片3个副分片。那么
1个节点： node1 3分片（yello）
2个节点： node1 3分片 node2 3分片 (green ，所有主分片与副分片同时运行)
3个节点： node1 2分片 node2 2分片 node3 2分片（green）
。。。。
6个节点： node1~node6每个节点1个分片
如果此时还想增加节点，可以增大副分片数量，即可以设定为每个主分片2个副分片，即有3个主分片6个副分片，那么
1个节点： node1 3分片（yello）
2个节点： node1 3分片 node2 3分片（yello）
3个节点： node1 3分片 node2 3分片 node3 3分片(green ，所有主分片与副分片同时运行)

。。。。
9个节点： node1~node6每个节点1个分片
这样做可以提高搜索性能，同时避免风险。其中一个节点宕机，所有分片会自动均匀分布在其他节点上，保证数据的完整。

秒客网

Elasticsearch（七）elasticsearch集群内原理

空集群