ES是一个分布式可扩展的东西,这个分布式我们可以从redis的cluster获得理解。和所有的分布式应用一样,ES也拥有一些概念诸如节点,集群,分片。本文就一一来看一下这些概念,对于后面的搭建集群有一个认知。
ES是具有高可用性的,也就是当你某些节点突然宕机了,是可以继续对外提供服务的。
ES基于其高可用性,是具有数据可用性的。当部分节点的数据丢失,整体不会丢失数据。
ES是具有可扩展性的,当你的请求量或者数据量增长到一定程度,我们可以水平扩展节点,将数据分布到所有的节点上面。
下面我们一一来理解介绍一下这些概念。
一、节点
1、简介
节点是一个ES的实例,也就是说当你在服务器启动一个es实例的时候,他就是一个节点。
- 其本质是一个JAVA进程,你可以用JPS查到。
- 一个机器上可以运行多个ES进程,但是生产环境建议一台机器运行一个,因为保证可用性,别一个机器宕机了,你所有的服务全部没了。
- 每一个几点都是由名称的,你可以在配置文件中配置指定,也可以在启动命令行中指定,通过-E node.name = 名称。
- 每一个节点启动之后,会分配一个UID,保存在data目录下面。
2、主节点
每个节点启动之后,都是自己的Master eligible节点。
- 你也可以在配置文件中设置node.master:false来禁止成为主节点。
Master eligible节点可以参加选主流程,进而成为Master主节点。也就是说一个节点起来之后是拥有成为主节点的资格。
当第一个节点启动的时候,他会将自己选举成为Master节点。
每个节点上都保存了集群的状态,只有Master节点才能修改集群的状态信息。 - 所谓的集群状态信息,也叫cluster state,维护了一个集群中所必要的信息。
包括所有的节点信息。
所有的索引和其相关的Mapping 和Setting信息。
分片的路由信息,数据被分片之后分到哪里了。
- 之所以要主节点才能修改集群的状态信息,是为了避免任意节点都能修改信息会导致数据的不一致性。怕乱了。
3、Data Node && Coordinating Node
3.1、Data Node
顾名思义,数据节点就是可以保存数据的节点。负责保存分片的数据,当集群扩展的时候其实就是扩展他。
3.2、Coordinating Node
协调节点,负责接收客户端的请求,然后将请求分发到合适的节点分片,最后把各个分片查到的数据结果汇集到一起。
每个节点默认都是Coordinating Node,都具有他的职责。
3.3、Hot & Warm Node
冷热节点,es提供了冷热数据分开存储的机制。实现hot & warm架构,Hot数据就是冷数据,一些不常用的数据,我们可以部署在一些低配置的机器上,实现冷热分区的机制。降低部署的成本。
3.4、Machine Learning Node
负责跑机器学习的job的节点,自动发现ES数据的异常,发出一些警报。
3.5、Tribe Node
这个东西慢慢被淘汰了,在5.3之后开始使用Cross Cluster Search节点,Tribe Node连接到不同的ES集群,并且支持将这些集群当成一个单独的集群处理。
4、配置节点类型
1、开发环境中一个节点可以承担多个角色。
2、生产环境中,应该设置单一的角色节点。一来可以性能好,节点负责的东西不多就性能好。二来职责单一,可以很快确定问题。管理也方便,可以为不同职责的节点配置不同的硬件。这里不要纠结这种,后面我们配置集群的时候来理解这些问题。
二、分片
分片分为主分片和副本。
1、主分片
主分片用于解决数据水平扩展的问题,通过主分片,可以将数据分布到集群内的所有节点上。
一个分片就是一个运行的Lucene实例。
主分片数量在索引创建的时候指定,后续不许修改,除非Reindex。
我们从以上信息可以提取一些点。
1、分片是在索引创建的时候指定的,所以分片的维度是在索引上,不同的索引有不同的分片数。
2、一个索引会分散数据到各个分片上,每个分片都是一个Lucene实例。
3、Reindex会导致主分片数量变化。
2、副本
副本是解决数据高可用问题的关键点。副本是属于主分片的,每个主分片下面多个副本。
1、副本是主分片的拷贝。
2、副本分片数是可以动态调整的。
3、增加副本数,可以在一定程度上提高服务的可用性,还能提高读取的吞吐。可见读取数据可以走副本。为啥说一定程度呢,因为不可能无限制增加的,你副本要同步主分片数据也需要成本,只能是一定限度。
3、分片,副本,和节点的关系
场景,一个集群testCluster里面有三个节点,此时我们去创建一个testIndex索引。其分片情况如下。
PUT /testIndex
{
"settings":{ # 在settings里面设置分片,副本等信息
"number_of_shards":3 # 这个索引指定三个主分片
"number_of_replicas":1 # 每个主分片下设置一个副本
}
}
我们看到此时三个节点下的集群,三个主分片就分布到不同的节点上。每个主分片的副本分片分布到和主分片不同的节点上。避免一个宕机了把主从都丢失了。
问题:
此时增加一个节点,或者增大主分片数对系统有何影响。
4、分片的设定
对于生产中分片的设定,需要提前做好容量规划。
4.1、分片数量过小
导致后续无法通过增加节点来实现水平扩展。因为你分片就那么多,你增加节点他没分片去分布啊。
单个分片的数量会很多,导致数据重新分配耗时。查询也慢。
4.2、分片数量设置过大
7.0开始默认主分片从原来的5变成了1.解决了over-sharding的问题。
分片数过于多也影响相关性打分。这个后面学打分的时候看一下。
单个节点过多分片也会导致资源浪费,影响节点性能,此外因为分布集中要是一个节点挂了,可能还有可用性问题。
可以使用GET _cluster/health来查看集群的健康程度。
{
"cluster_name" : "test",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 6,
"active_shards" : 12,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
显示出以上的信息,其中status有三个值。
- green:集群中的主分片和副本都正常分配。
- yellow:主分片全部正常分配,有副分片未能正常分配。
- red:有主分片未能正常分配。
例如,当服务器的磁盘容量超过百分之85,此时你去创建索引,就会分配失败,需要人工介入干预。
三、cerebro可视化查看集群
1、查看信息
连接到9000端口查看集群信息。
索引现在的主分片和副本分片默认都是1。
我上面说错,每个节点都是带星号的,表示都是Master eligible节点。但是加粗的星号表示是master节点,他们都有被选能力,但是加粗的表示他成为了master节点,一般先启动的就是master。
2、手动移除节点
为了验证我们上面说的那个status的绿色,红色,黄色,我们现在看到的都是正常的,绿色。
现在我们手动停止其中的一个容器。我们先查看一下当前docker有哪些容器。docker ps
我们停掉es_702那个,我们上面看到702是各个索引的副本分片所在的地方,所以停掉之后应该就变成黄色。红色的自己去试试。socker stop
此时再去kibana看下信息:发现一切都如预期。
四、总结
我们需要知道这些概念,因为实际生产都是集群模式,我们需要做到心中有数,有的放矢。后续再真正使用集群的时候才能知道自己在干吗。至于具体的设计,搭建,配置,调优需要在后续不断的完善知识完成理论和实践体系。
附操作:
#查看索引相关信息
GET kibana_sample_data_ecommerce
#查看索引的文档总数
GET kibana_sample_data_ecommerce/_count
#查看前10条文档,了解文档格式
POST kibana_sample_data_ecommerce/_search
{
}
#_cat indices API
#查看indices
GET /_cat/indices/kibana*?v&s=index
#查看状态为绿的索引
GET /_cat/indices?v&health=green
#按照文档个数排序
GET /_cat/indices?v&s=docs.count:desc
#查看具体的字段
GET /_cat/indices/kibana*?pri&v&h=health,index,pri,rep,docs.count,mt
#How much memory is used per index?
GET /_cat/indices?v&h=i,tm&s=tm:desc