ElasticSearch 深入理解系列2 -集群，分布式特性

一、 总结：

1 创建集群只需要修改配置的 node.name即可，集群名称luster.name需要保持一样。

2 集群的管理由ES自动完成。

二、 集群、节点、分片概念

1 节点和集群

节点(node)是你运行的Elasticsearch实例。一个 集群(cluster)是一组具有相同cluster.name的节点集合，他们协同工作，共享数据并提供故障转移和扩展功能，当有新的节点加入或者删除节点，集群就会感知到并平衡数据。集群中一个节点会被选举为主节点(master),它用来管理集群中的一些变更，例如新建或删除索引、增加或移除节点等;当然一个节点也可以组成一个集群。

2 节点和分片区别。

2.1 分片是最小级别的”工作单元“。也是Lucene的一个实例。

2.2 分片分为主分片(primary shard)和复制分片(replica shard)，复制分片只是主分片的一个副本。它防止故障时数据丢失，同时提供数据访问。

2.3 主分片的多少觉得了索引能存储的数据量，

2.4 索引确定时，分片的数量就确定了，即主分片数量只能在确定索引时确定(确定索引后再进行修改，会造成数据丢失)。所以常说的分片也是对于某一个索引的分片。而副分片可以在索引确定之后动态修改。

2.5 分片设置及数量

命令

PUT /blogs{ "settings" : { "number_of_shards" : 3 , "number_of_replicas" : 1 }}

上述配置设置一个3个主分片，每个分片有一个复制分片。主副分配一共有6个。

若 number_of_replicas" 设置为2 ，则每个主分片有2个赋值分片，总共会有9个分片。

分片数量计算公式：

number_of_shards + number_of_replicas*number_of_shards=number_of_shards*（1+number_of_replicas）

主分片的数量和复制分片的数量都可以通过配置文件配置。但是主切片的数量只能在创建索引时定义且不能修改.相同的分片不会放在同一个节点上。总结：主分片和副分配不是1

3 集群结构、主节：

• 节点被选为master节点。负责管理集群范畴的变更，例如创建或删除索引，添加节点到集群或从集群删除节点。master 节点无需参与文档层面的变更和搜索，这意味着仅有一个 master 节点并不会因流量增长而成为瓶颈。任意一个节点都可以成为 master 节点。
• 用户可以访问包括master节点的任意节点
• 各个节点知道各个文档的位置。并能够将我们的请求直接转发到拥有我们想要的数据的节点。都有ES透明管理

4 集群自动完成的操作。

• 可以将你的文档分区到不同容器或者 分片 中，这些文档可能被存在一个节点或者多个节点。

• 跨节点平衡集群中节点间的索引与搜索负载。

• 自动复制你的数据以提供冗余副本，防止硬件错误导致数据丢失。

• 自动在节点之间路由，以帮助你找到你想要的数据。

• 无缝扩展或者恢复你的集群。

5 集群健康-3个状态

状态	意义
green	所有主分片和从分片都可用
yellow	所有主分片可用，但存在不可用的从分片
red	存在不可用的主要分片

默认为1个副本。如果采用默认设置，而你集群只配置了一台机器，那么集群的健康度为 yellow ，也就是所有的数据都是可用的，但是某些复制没有被分配。 yellow 表示所有的 主分片(primary shards) 启动并且正常运行了——集群已经可以正常处理任何请求——但是 复制分片(replica shards) 还没有全部可用。

5 创建节点。

修改 elasticsearch.yml   文件的node.name即可.

6 设置节点数量

PUT /blogs{ "settings" : { "number_of_shards" : 3 , "number_of_replicas" : 1 }}

设置一个3个主分片，每个分片有一个复制分片。主副分配一共有6个。

下面的情况主副分片有12个。

若只有一个节点。则

集群的status是yellow。

若有2个

若有3个。

7 分片的介绍

分片本身就是一个完整的搜索引擎，它可以使用单一节点的所有资源。我们拥有6个分片（3个主分片和三个复制分片），最多可以扩展到6个节点，每个节点上有一个分片，每个分片可以100%使用这个节点的资源。

10 节点通信 :  

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

11 分片与副本分片

分片用于 Elasticsearch 在你的集群中分配数据。想象把分片当作数据的容器。文档存储在分片中，然后分片分配给你集群中的节点上。

当你的集群扩容或缩小， Elasticsearch 将会自动在你的节点间迁移分片，以使集群保持平衡。

一个分片 (shard) 是一个最小级别的“工作单元 (worker unit) ” , 它只是保存索引中所有数据的一小片 . 我们的文档存储和被索引在分片中，但是我们的程序不知道如何直接与它们通信。取而代之的是，他们直接与索引通信 .Elasticsearch 中的分片分为主分片和副本分片 , 复制分片只是主分片的一个副本，它用于提供数据的冗余副本，在硬件故障之后提供数据保护，同时服务于像搜索和检索等只读请求 ，主分片的数量和复制分片的数量都可以通过配置文件配置。但是主切片的数量只能在创建索引时定义且不能修改.相同的分片不会放在同一个节点上。

1) 分片算法 :

shard = hash(routing) % number_of_primary_shards

routing 值是一个任意字符串，它默认是 _id 但也可以自定义，这个 routing 字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数 (remainder) ，余数的范围永远是 0 到 number_of_primary_shards - 1 ，这个数字就是特定文档所在的分片。

这也解释了为什么主切片的数量只能在创建索引时定义且不能修改：如果主切片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。

所有的文档 API （ get 、 index 、 delete 、 bulk 、 update 、 mget ）都接收一个 routing 参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档 . 比如用户的文章 , 按照用户账号路由 , 就可以实现属于同一用户的文档被保存在同一分片上。

2) 分片和副本交互：

新建、索引和删除请求都是写 (write) 操作，它们必须在主分片上成功完成才能复制到相关的复制分片上 , 下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：

1 、客户端给 Node 1 发送新建、索引或删除请求。

2 、节点使用文档的 _id 确定文档属于分片 0 。它转发请求到 Node 3 ，分片 0 位于这个节点上。

3 、 Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和 Node 2 的复制节点上。当所有的复制节点报告成功， Node 3 报告成功到请求的节点，请求的节点再报告给客户端。

客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。

3) 副本分片复制时的相关的参数说明 :

replication:

复制默认的值是 sync 。这将导致主分片得到复制分片的成功响应后才返回，如果你设置 replication 为 async ，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。

默认的 sync 复制允许 Elasticsearch 强制反馈传输。 async 复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使 Elasticsearch 过载。

consistency:

默认主分片在尝试写入时需要 ** 规定数量 (quorum)** 或过半的分片（可以是主节点或复制节点）可用。这是防止数据被写入到错的网络分区。规定的数量计算公式如下：

int( (primary + number_of_replicas) / 2 ) + 1

consistency 允许的值为 one （只有一个主分片）， all （所有主分片和复制分片）或者默认的 quorum 或过半分片。

注意 number_of_replicas 是在索引中的的设置，用来定义复制分片的数量，而不是现在活动的复制节点的数量。如果你定义了索引有 3 个复制节点，那规定数量是： int( (primary + 3 replicas) / 2 ) + 1 = 3

但如果你只有 2 个节点，那你的活动分片不够规定数量，也就不能索引或删除任何文档。

注意 :  新索引默认有 1 个复制分片，这意味着为了满足 quorum 的要求 ** 需要 ** 两个活动的分片。当然，这个默认设置将阻止我们在单一节点集群中进行操作。为了避开这个问题，规定数量只有在 number_of_replicas 大于一时才生效。

timeout：

当分片副本不足时 Elasticsearch 会等待更多的分片出现。默认等待一分钟。如果需要，你可以设置 timeout 参数让它终止的更早： 100 表示 100 毫秒， 30s 表示 30 秒。

 

集群生态 :

1. 同集群中节点之间可以扩容缩容 ,

2.主分片的数量会在其索引创建完成后修正，但是副本分片的数量会随时变化。

3.相同的分片不会放在同一个节点上.

集群-自动发现

Zen发现是ES自带的默认发现机制，使用多播发现其它节点。只要启动一个新的ES节点并设置和集群相同的名称这个节点就会被加入到集群中。

代表es的自动发现节点机制，es是一个基于p2p的系统，它先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互。

注：es是基于p2p的系统，各个节点之间直接交互。所有的主要API操作（index、delete、search）都不会和主节点交流。主节点只负责维护全局的集群状态。

1. 节点启动后先ping（这里的ping是 Elasticsearch 的一个RPC命令。如果 discovery.zen.ping.unicast.hosts 有设置，则ping设置中的host，否则尝试ping localhost 的几个端口， Elasticsearch 支持同一个主机启动多个节点）
2. Ping的response会包含该节点的基本信息以及该节点认为的master节点
3. 选举开始，先从各节点认为的master中选，规则很简单，按照id的字典序排序，取第一个
4. 如果各节点都没有认为的master，则从所有节点中选择，规则同上。这里有个限制条件就是 discovery.zen.minimum_master_nodes，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举
5. 最后选举结果是肯定能选举出一个master，如果只有一个local节点那就选出的是自己
6. 如果当前节点是master，则开始等待节点数达到 minimum_master_nodes，然后提供服务, 如果当前节点不是master，则尝试加入master.
7. ES支持任意数目的集群（1-N）,所以不能像 Zookeeper/Etcd 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则，只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的. 但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题，大多数解决方案就是设置一个quorum值，要求可用节点必须大于quorum（一般是超过半数节点），才能对外提供服务。而 Elasticsearch 中，这个quorum的配置就是 discovery.zen.minimum_master_nodes 。

集群中三种角色

Elasticsearch集群中有的节点一般有三种角色:master node、data node和client node。

1. master node:master几点主要用于元数据(metadata)的处理，比如索引的新增、删除、分片分配等。
2. data node:data 节点上保存了数据分片。它负责数据相关操作，比如分片的 CRUD，以及搜索和整合操作。这些操作都比较消耗 CPU、内存和 I/O 资源；
3. client node:client 节点起到路由请求的作用，实际上可以看做负载均衡器。

对应不同配置 https://my.oschina.net/Yumikio/blog/805877