Elasticsearch用于构建高可用和可扩展的系统。
可扩展：横向扩展(增加集群的节点数)和纵向扩展(使用更好的服务器)。纵向扩展有其局限性，真正的可扩展性应该是横向扩展，通过增加节点来均摊负载和增加可靠性。
本节介绍集群(cluster)、节点(node)和分片(shards)，以及按照需求进行扩展、并保证硬件故障时数据依旧安全问题。
一、集群与节点的关系
一个集群有多个节点组成，他们具有相同的cluster.name,当加入或者删除一个节点，集群会感知到并平衡数据。
主节点(master) ==》临时管理集群级别的一些变动，如新建删除索引、增加或移动节点等
节点(node) ==》我们可以和任何节点通信，包括主节点，每一个节点都知道文档存储在那个节点，他们可以转发请求到相应的节点上。我们访问的节点会收集各节点返回的数据，一并返回给客户端。
二、添加索引
添加数据到elasticsearch，需要添加索引---一个存储关联数据的地方。索引是一个用来指向一个或多个分片(shards)的"逻辑命名空间"。
分片分为主分片和复制分片，复制分配可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。
当索引创建完成，主分片数量就固定了，但复制分片的数量可以随时调整。
单节点上建立一个索引blogs:
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}输入cluster-health可见
{
"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>
}- <1> 集群的状态现在是
yellow - <2> 我们的三个复制分片还没有被分配到节点上
由于是单节点建立的索引，三个主分片启动并正常运行了，但复制节点没有正常运行(在同一个节点保存相同数据的复制节点是没有必要的，如果此节点发生故障，所有数据副本也会丢失)，因此集群健康状态yellow.
三、增加节点
elasticsearch集群上增加节点，只需要启动新增加的节点，并且第二个节点和集群节点的cluster.name相同(请看./config/elasticsearch.yml文件),新节点就能自动发现并加入elasticsearch集群。如果没有加入集群，检查日志查找问题出在哪里，可能是网络广播被禁止，或者防火墙阻止了节点间的通信。
文档的索引首先被存储在主分片上，然后并发复制到对应的复制节点上。这样数据在主节点和复制节点上都可以被检索到。
由于主分片在数据存储完时就已经决定了，但是主分片和复制分片都可以处理读请求---搜索或文档检索的功能，所以数据的冗余越多，我们能处理的搜索吞吐量就越大。
主分片的数量无法改变，那么我们如何增加复制分片的数量:
PUT /blogs/_settings
{
"number_of_replicas" : 2
}*****注意****，在同样数量的节点上增加更多的复制节点并不能提高性能，因为增加复制分片数量会使每个分片所占有的硬件资源减少，(译者注，大量的请求都聚集到分片少的节点上，导致一个节点的吞吐量太大，反而降低性能)，因此需要增加硬件节点来提高性能。
四、如何应对故障
当主节点master挂掉时候，此时检查集群stats显示red---不是所有的主分片都可以工作。但幸运的是丢失的主分片的拷贝(复制分片)保存在其他的节点上，所以新的master要做的第一件事是把其他节点上可以工作的复制分片升级为主分片，这样集群的健康又回到yellow状态。此时由于复制分片数量没达到设置数量，集群无法恢复到green状态，重新启动故障节点，集群将能够分配丢失的复制分片。如果故障节点保留着旧分片的拷贝，他将会再次利用他们，他只会从master上拷贝故障期间有数据变更的那一部分。