ElasticSearch之二——集群

ElasticSearch 集群

 

首先看下ElasticSearch（ES）的架构：

术语解释：

• cluster：表明一个集群，集群中有多个节点，其中有一个master节点，master经过选举自动产生；
• shards：表明索引分片，ES能够把一个完整的索引分红多个分片，并将它们分布到不一样的节点上，从而构成分布式索引；
• replicas：表明索引副本，副本能够保证系统的高可用性，当某个节点的某个分片损坏时能够从副本中恢复，此外，多个分片副本还能够起到负载均衡的做用；
• recovery：表明数据恢复，ES在有节点加入或退出时会根据机器的负载对索引分片进行从新分配；
• river：表明ES的一个数据源，它是以插件方式存在的一个ES服务，经过读取river中的数据并把它索引到ES中，官方的river有couchDB、RabbitMQ、Kafka、 Wikipedia等；
• geteway：表明ES索引快照的存储方式，ES默认是把索引存放到内存中，当内存满了再持久化到磁盘。geteway对索引快照进行存储，当这个集群关闭再从新启动时就会从geteway中读取索引备份数据。ES支持多种类型的gateway，如本地文件系统（默认），分布式文件系统（HDFS）；

• discovery.zen，ES自动发现节点的机制，ES是一个基于P2P协议的系统，它先经过广播寻找存在的节点，再经过多播协议来进行节点之间的通讯，同时也支持点对点的交互；

• transport，表明ES内部节点之间或集群与客户端的交互方式，默认使用TCP协议，同时支持HTTP协议（json格式）、thrift、servlet、zeroMQ、memcached等传输协议（经过插件方式集成）；

 

ES的分布式操做大可能是自动完成的：
一、跨节点平衡集群中各节点的索引与搜索负载；
二、自动复制索引数据以提供冗余副本，防止硬件错误致使数据丢失；
三、自动在节点之间路由，以帮助找到检索的数据；
四、无缝扩展或者恢复集群；

 

node（节点）是ES运行中的实例，一个或多个具备相同cluster.name的节点构成一个cluster（集群），它们协同工做，共享数据，并共同分担工做负载。
集群中的一个节点会被选为master，它将负责管理集群范畴的变动，例如建立或删除索引，在集群中添加或删除节点，但master无需参与文档层面的变动和搜索，这意味着仅有一个master并不会因流量增加而成为瓶颈。
做为用户，咱们能够访问包括master在内的集群中的任一节点，每一个节点都知道各个文档的位置，并可以将咱们的请求直接转发到拥有咱们想要的数据的节点，不管咱们访问的是哪一个节点它都会控制从拥有数据的节点收集响应的过程，并返回给客户端最终的结果，这一切都是由ES透明管理的。

 

一、添加索引

在ES中，分片用来分配集群中的数据。把分片想象成一个数据的容器。数据被存储在分片中，而后分片又被分配在集群的节点上。当你的集群扩展或者缩小时，elasticsearch会自动的在节点之间迁移分配分片，以便集群保持均衡。

分片分为 主分片(primary shard) 以及 从分片(replica shard) 两种：

• 主分片，在你的索引中，每个文档都属于一个主分片。理论上主分片对存储多少数据是没有限制的，但分片的最大数量彻底取决于你的实际情况：硬件的配置、文档的大小和复杂度、如何索引和查询你的文档，以及你指望的响应时间。
• 从分片，从分片只是主分片的一个副本，它用于提供数据的冗余副本，在硬件故障时提供数据保护，同时服务于搜索和检索这种只读请求。

索引中的主分片的数量在索引建立后就固定下来了，可是从分片的数量能够随时改变。

 

接下来，咱们在空的单节点集群中上建立一个叫作blogs的索引。一个索引默认设置了5个主分片，可是为了演示，咱们这里只设置3个主分片和一组从分片（每一个主分片有一个从分片对应）：

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

如今，咱们的集群看起来就像下图所示了有索引的单节点集群，这三个主分片都被分配在Node 1。

 

在ES集群中能够监控统计不少信息，其中最重要的就是：集群健康(cluster health)。它的 status 有 green、yellow、red 三种；

GET /_cluster/health

返回：

{
"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 
}

 

其中status能够告诉咱们当前集群是否处于一个可用的状态。三种颜色分别表明：

 

状态	意义
green	全部主分片和从分片均可用
yellow	全部主分片可用，但存在不可用的从分片
red	存在不可用的主要分片

 

集群的健康情况yellow意味着全部的 主分片(primary shards) 启动而且运行了，这时集群已经能够成功的处理任意请求，可是 从分片(replica shards) 没有彻底被激活。事实上，当前这3个从分片都处于unassigned（未分配）的状态，它们还未被分配到节点上。在同一个节点上保存相同的数据副本是没有必要的，若是这个节点故障了，就等同于全部的数据副本也丢失了。

 

二、容错转移

为了提升系统的可用性，生产环境几乎不会使用单节点ES集群。

下面介绍如何使用双节点集群(cluster-two-nodes)，只要第二个节点与第一个节点的cluster.name相同（参见./config/elasticsearch.yml文件中的配置），它就能自动发现并加入到第一个节点的集群中。若是没有，请结合日志找出问题所在。这多是多播（multicast）被禁用，或者防火墙阻止了节点间的通讯。

 

以下图，双节点集群——全部的主分片和从分片都被分配: 

当第二个节点加入后，就产生了三个 从分片(replica shards) ，它们分别于三个主分片一一对应。也就意味着即便有一个节点发生了损坏，咱们能够保证数据的完整性。

全部被索引的新文档都会先被存储在主分片中，以后才会被平行复制到关联的从分片上。这样能够确保咱们的文档在主节点和从节点上都能被检索。

 

三、横向扩展

随着应用需求的增加，咱们该如何扩展？若是咱们启动第三个节点，集群内会自动重组，这时便成为了三节点集群(cluster-three-nodes)。

分片已经被从新分配以平衡负载： 

在Node 1和Node 2中分别会有一个分片被移动到Node 3上，这样一来，每一个节点上就都只有两个分片了。这意味着每一个节点的硬件资源（CPU、RAM、I/O）被更少的分片共享，因此每一个分片就会有更好的性能表现。

分片自己就是一个很是成熟的搜索引擎，它可使用单个节点的全部资源。咱们一共有6个节点（3个主分片和3个从分片），所以最多能够扩展到6个节点，每一个节点上有一个分片，这样每一个分片均可以使用到所在节点100%的资源了。

 

前面提到，主分片的数量在索引建立时就肯定了，而从分片的数量能够随时调整：

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

将从分片的数量增长到2份：

从图中能够看出，如今blogs的索引总共有9个分片：3个主分片和6个从分片。也就是说，如今咱们就能够将总节点数扩展到9个，就又会变成一个节点一个分片的状态了。最终咱们获得了三倍搜索性能的三节点集群。

 

四、故障恢复

若是上面的三节点集群中有一个节点发生故障，例如：

 

被杀掉的节点是主节点。而为了集群的正常工做必须须要一个主节点，因此首先进行的进程就是从各节点中选择了一个新的主节点：Node 2。

主分片1和2在咱们杀掉Node 1后就丢失了，咱们的索引在丢失主节点的时候是不能正常工做的。若是咱们在这个时候检查集群健康状态，将会显示red：存在不可用的主节点！

幸运的是，丢失的两个主分片的完整拷贝在存在于其余的节点上，因此新的主节点所完成的第一件事情就是将这些在Node 2和Node 3上的从分片提高为主分片，而后集群的健康状态就变回至yellow。这个提高的进程是瞬间完成了，就好像按了一下开关。

那么为何集群健康状态依然是是yellow而不是green呢？是由于如今咱们有3个主分片，可是咱们以前设定了1个主分片有2个从分片，可是如今却只有1份从分片，因此状态没法变为green，不过咱们能够不用太担忧这里：当咱们再次杀掉Node 2的时候，咱们的程序依旧能够在没有丢失任何数据的状况下运行，由于Node 3中依旧拥有每一个分片的备份。

若是咱们重启Node 1，集群就可以从新分配丢失的从分片，这样结果就会与三节点两从集群一致。若是Node 1依旧还有旧节点的内容，系统会尝试从新利用他们，并只会复制在故障期间的变动数据。

 

五、分布式存储

当须要新增一个文档到索引中时，须要为这个文档找到一个主分片进行存储，它按照下面的公式选择主分片：
shard = HASH(文档ID) % 主分片数量

其中，文档ID也能够被替换成其它能惟一表示一个文档的字符串。另外，主分片数量在索引建立时就已经肯定了，运行过程当中不容许修改，所以，同一个文档老是会被路由到同一个主分片上。

ES集群若是包含多个节点，每一个节点均可以服务全部请求，节点能够根据上面的方法计算出当前请求的文档在哪一个分片，而后转发请求到该节点上。

 

 

 

参考文档：

http://www.learnes.net/distributed_cluster/