这一章节主要介绍，ElasticSearch在分布式环境下的工作机制，主要包括：
术语解释：集群cluster，节点node，分片shard；
ES的扩展机制，以及它如何处理故障．
ES用于构建高可用和可扩展的系统，扩展的方式有两种：
纵向扩展vertical scale or scaling up：购买更好的服务器
横向扩展horizontal scale or scaling out：购买更多的服务器
ES虽然能够从更强大的硬件中获取性能的提升，但是纵向扩展有其局限性；真正的扩展是横向扩展，通过增加节点来均摊负载和增加可靠性．
对比于大多数据库来讲，ES天生就是分布式的：它知道如何管理节点来提供高扩展和高可用．
在这一章，将探索如何创建集群cluster，节点node，分片shard，使其按照你的需求扩展，并保证硬件故障时，数据依旧安全．
1. 集群
如果启动一个单独的节点，还没有数据和索引，这个集群就像下图：
图：只有一个空节点的集群
一个节点node就是一个ElasticSearch实例，而集群cluster是一个或多个节点组成，它们具有相同的cluster.name，它们协同工作，分享数据和负载．
当新加入或移除一个节点时，集群就会感知，并平衡数据．
主节点：集群中一个结点会被选为主节点，它将临时管理集群级别的一些变更，如新建或移除索引，增加或移除节点等．
主节点不参与文档级别的变更或搜索，这意味着在流量增长的时候，主节点不会成为集群的瓶颈．
任何节点都可以充当主节点．
作为用户，我们可以与集群中的任何节点进行通信，包括主节点，每一个节点都知道文档存在于哪一个节点上，可以转发请求到相应的节点上．
我们访问的节点负责收集各节点返回的数据，最后一起返回给客户端，这一切由ES封装处理．
2. 集群健康
ES集群中可以监控统计很多信息，有一个是最重要的，集群健康cluster health，集群健康有三种状态：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
}green：所有主分片和复制分片都可用；
yellow：所有主分片可用，但不是所有复制分片都可用；
red：不是所有主要分片都可用；
后续介绍主分片和复制分片，并介绍颜色状态的实际意义．
字段active_shards是可用分片shard的数量，包括主分片和复制分片．
3. 添加索引
为了将数据添加到ES中，我们需要索引index，它是一个存储关联数据的地方．实际上，索引只是一个用来指向一个或多个分片的逻辑命名空间．
一个分片是最小级别的工作单元，它只保存了索引中所有数据的一部分，分片是ES在集群中分发数据的关键，把分片看作存储数据的容器，文档存储在分片中，然后分片分配到集群中的节点上．当集群扩容或缩小时，ES会自动的在节点间迁移分片，以使集群保持平衡．
我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是直接与索引进行通信．
主分片primary shards和复制分片replica shards：
索引中的每一个文档都属于一个单独的主分片，主分片的数量决定了索引最多能存储多少数据．
注：理论上一个主分片能存储的数据大小是没有限制的，限制取决于使用情况：硬件存储的大小，文档的大小和复杂度，如何索引和查询文档，期望响应时间等．
复制分片是主分片的一个副本，一是可以防止硬件故障导致的数据丢失，二是提供读请求，比如搜索或者从别的分片取回文档．
当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整．
在只有一个空节点的集群上创建一个索引blogs，默认情况下一个索引被分配5个主分片，为了演示，为blogs索引只分配3个主分片，以及每个主分片分配一个复制分片：
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
现在的集群就像上图，三个主分片都被分配到节点node1，现在检查集群健康得到：
{
"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
}yellow表示所有主分片启动并且正常运行了，集群已经可以正常处理任何请求，但是复制分片还没有完全可用．
事实上，所有三个复制分片还处于unassigned未分配的状态，它们还未分配给节点，因为在同一个节点上保存相同的数据副本是没有必要的．
集群现在的状态是功能已经完备，但是仍旧存在因硬件故障而导致数据丢失的风险．
4. 故障转移
在单一节点上运行，意味着有单点故障的风险，因为没有数据备份，解决这个问题，唯一做的就是启动另一个节点．
启动第二个节点，可以在一台主机上启动多个ES实例，每个ES实例可以作为一个节点．
只要第二个节点与第一个节点具有相同的cluster.name，可以查看/config/elasticsearch.yml文件，它就能自动发现并加入第一个节点所在的ES集群．
如果没有自动加入，可以查看日志，可能是网络广播被禁用，或者防火墙阻止了通信．
当启动了第二个节点之后，双节点集群，所有的主分片和复制分片都已分配，如下图：
文档的索引将首先被存储在主分片中，然后并发复制到对应的复制节点上．这可以确保我们的数据在主节点和复制节点上都可以被检索．
查看集群健康：
{
"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
}集群现在的状态不但是功能完备的，而且是高可用的．
5. 横向扩展
随着应用需求的增长，可以启动第三个节点来进行扩展，集群会重新组织自己，如图：
包含3个节点的集群，分片已经被重新分配以平衡负载．
每个节点有2个分片，和之前的比少了一个，这意味着每个节点上的分片将获得更多的硬件资源．CPU，RAM，IO
分片本身是一个完整的搜索引擎，它可以使用单一节点的所有资源，主分片和复制分片总共为6个，最多可以扩展到6个节点上，每个节点上有一个分片，每个分片可以100%的利用节点资源．
如果要扩展到6个以上的节点，该怎么做？
主分片的数量在创建索引时已经确定．这个数量定义了能存储到索引中的数据的最大量．然而主分片和复制分片都可以处理读请求，搜索或文档检索，所以数据的冗余量越多，能够处理的搜索吞吐量越大．
复制分片的数量可以在运行中的集群中动态的变更．这允许我们根据需求扩大或缩小规模．
将复制分片的数量从1变更为2：
PUT /blogs/_settings
{
"number_of_replicas" : 2
}变更后的集群如下图：
从图中可以看出，blogs索引现在有9个分片，3个主分片和6个复制分片，这意味着我们可以扩展到9个节点，再次变成每个节点一个分片．
这样搜索性能，相比原始的三节点集群性能增加三倍．
注意，在同样数量节点上增加更多的复制分片并不能提高性能，因为每个分片所分配到的资源硬件少了．
6. 故障应对
ES可以应对节点失效，现在杀掉第一个节点的进程，现在的集群如图：
杀掉的第一个节点是集群的主节点，一个集群必须要有一个主节点才能使其功能正常，所以集群现在要做的就是，各个节点选举出了一个主节点node2．
主分片1和主分片2在杀掉node1时已经丢失，索引在丢失主分片时不能正常工作，如果我们此时检查节点健康状态，是red：不是所有的主分片都可用．
幸运的是丢失的两个主分片在其他节点上有完整的拷贝，所以新主节点的第一件事请就是把node2和node3上的复制分片升级为主分片，这时集群回到yellow状态，这个提升是瞬间完成的．
为什么是yellow状态而不是green状态？
因为有三个主分片，但是我们指定了每个分片有2个复制分片，当前却只有一个复制分片被分配到节点，这就是集群无法达到green的原因．
如果重启node1，集群将重新分配丢失的复制分片，如同横向扩展一个节点．如果node1依旧有旧分片的拷贝，ES将会尝试重新利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分．