1. 单节点

集群: 一个或者多个具有相同 cluster.name 配置的节点组成集群

节点：一个运行的Elasticsearch实例为一个节点

分片：底层的工作单元，简单来说它就是Lucene的一个实例

1.1 集群

1. 集群内的节点共同承担数据和负载的压力。
2. 当有节点加入或者移出集群时，集群会重新平均分配所有的数据。

1. 2 节点

1. 主节点负责集群内的所有变更（如增加、删除节点，增加、删除索引等）
2. 主节点并不需要涉及到文档级别的变更和搜索
3. 任何节点都可以成为主节点
4. 每个节点都知道任意文档所处的位置，当用户请求时无论请求哪个节点都能直接将请求转发给实际存储文档的节点
5. 无论用户请求哪个节点，它都能负责从个个包含我们所需文档的各个节点收集回数据并发给客户端，对这一切都是透明的

1. 3分片

1. 一个分片是一个底层的 工作单元
2. 它本身就是一个完整的搜索引擎
3. 应用程序是直接与索引而不是与分片进行交互
4. Elasticsearch 是利用分片将数据分发到集群内各处的
5. 分片是数据的容器，文档保存在分片内
6. 分片又被分配到集群内的各个节点里
7. 当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。
8. 一个分片可以是主分片或者副本分片
9. 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量
10. 一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务
11. 在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改

PUT /blogs{
	"settings" : {
		"number_of_shards" : 3, //blogs的数据分为3片存储
		"number_of_replicas" : 1 //每一片的副本为1
	}
}

2. 集群健康

Elasticsearch的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是集群健康﹐它在 status字段中展示为green、yellow、red

GET /_cluster/health

status字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下:

• green：所有的主分片和副本分片都正常运行。
• yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。
• red:有主分片没能正常运行。

3. 新增节点

当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的cluster.name配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。详细信息请查看最好使用单播代替组播
此时, cluster-health 现在展示的状态为green ，这表示所有6个分片(包括3个主分片和3个副本分片）都在正常运行。我们的集群现在不仅仅是正常运行的，并且还处于始终可用的状态。

4. 水平扩容——启动第三个节点

Node 1和Node 2上各有一个分片被迁移到了新的Node 3节点，现在每个节点上都拥有2个分片，而不是之前的3个。这表示每个节点的硬件资源（CPU, RAM, IO）将被更少的分片所共享，每个分片的性能（负载能力）将会得到提升。

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的1调整到2：

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

blogs 索引现在拥有9个分片：3个主分片和6个副本分片。这意味着我们可以将集群扩容到9个节点，每个节点上一个分片。相比原来3个节点时，集群搜索性能可以提升3倍。

5. 应对故障

• 我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点:Node 2 。
• 在我们关闭 Node 1 的同时也失去了主分片1和2，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为red :不是所有主分片都在正常工作。
• 幸运的是，在其它节点上存在着这两个主分片的完整副本,所以新的主节点立即将这些分片在 Node 2和 Node 3上对应的副本分片提升为主分片，此时集群的状态将会yellow .这个提升主分片的讨程是瞬间发生的﹐如同按下一个开关一样
• 为什么我们集群状态是yellow而不是 green 呢?虽然我们拥有所有的三个主分片，但是我们同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了Node 2 ,我们的程序依然可以保持在不丢任何数据的情况下运行，因为 Node 3为每一个分片都保留着一份副本。
• 如果我们重新启动 Node 1，集群可以将缺失的副本分片再次进行分配。如果Node 1依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。

6. 问题与解决

1、主节点
主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch,中的主节点的工作量相对较轻，用户的请求可以发往集群中任何一个节点，由该节点负责分发和返回结果，而不需要经过主节点转发。而主节点是由候选主节点通过ZenDiscovery,机制选举出来的，所以要想成为主节点，首先要先成为候选主节点。

2、候选主节点
在elasticsearch,集群初始化或者主节点宕机的情况下,由候选主节点中选举其中一个作为主节点。指定候选主节点的配置为: node.master: true（只要配置了这个，都有资格成为主节点）

当主节点负载压力过大，或者集中环境中的网络问题，导致其他节点与主节点通讯的时候,主节点没来的及响应，这样的话，某些节点就认为主节点宕机，重新选择新的主节点，这样的话整个集群的工作就有问题了，比如我们集群中有10个节点，其中7个候选主节点，1个候选主节点成为了主节点，这种情况是正常的情况。但是如果现在出现了我们上面所说的主节点响应不及时，导致其他某些节点认为主节点宕机而重选主节点，那就有问题了，这剩下的6个候选主节点可能有3个候选主节点去重选主节点,最后集群中就出现了两个主节点的情况，这种情况官方成为"脑裂现象"；

集群中不同的节点对于master的选择出现了分歧，出现了多个master竞争，导致主分片和副本的识别也发生了分歧,对一些分歧中的分片标识为了坏片。

3、数据节点
数据节点负责数据的存储和相关具体操作，比如 CRUD、搜索、聚合。所以，数据节点对机器配置要求比较高，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统CPU、Memory和IO的性能消耗都很大。通常随着集群的扩大，需要增加更多的数据节点来提高可用性。指定数据节点的配置: node.data: true
elasticsearch是允许一个节点既做候选主节点也做数据节点的，但是数据节点的负载较重，所以需要考虑将二者分离开，设置专用的候选主节点和数据节点，避免因数据节点负载重导致主节点不响应。

4、客户端节点
客户端节点就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等等,但是这样的工作，其实任何一个节点都可以完成，因为在elasticsearch，中一个集群内的节点都可以执行任何请求，其会负责将请求转发给对应的节点进行处理。所以单独增加这样的节点更多是为了负载均衡。指定该节点的配置为：

node.master: false
node.data: false

5、脑裂问题成因与解决方案

1. 网络问题:集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对 master上的分片和副本标红，分配新的主分片
2. 节点负载:主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。3.内存回收: data 节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

脑裂问题解决方案:

• 角色分离：即 master节点与data节点分离，限制角色;数据节点是需要承担存储和搜索的工作的，压力会很大。所以如果该节点同时作为候选主节点和数据节点,那么一旦选上它作为主节点了，这时主节点的工作压力将会非常大,出现脑裂现象的概率就增加了。
• 减少误判：配置主节点的响应时间，在默认情况下，主节点3秒没有响应，其他节点就认为主节点宕机了，那我们可以把该时间设置的长一点，该配置是:discovery.zen.ping_timeout: 5
• 选举触发：discovery.zen.minimum_master_nodes:1(默认是1)，该属性定义的是为了形成一个集群,有主节点资格并互相连接的节点的最小数目。
  • 一个有10节点的集群，且每个节点都有成为主节点的资格，discovery.zen.minimum_master_nodes参数设置为6。（少于这个值就不能选主）
  • 正常情况下，10个节点，互相连接，大于6，就可以形成一个集群。
  • 若某个时刻，其中有3个节点断开连接。剩下7个节点，大于6，继续运行之前的集群。而断开的3个节点,小于6，不能形成一个集群。
  • 该参数就是为了防止"脑裂"的产生。
  • 建议设置为(候选主节点数/2)+1,