目录
1.简介
Elasticsearch用于构建高可用和可扩展的系统。
扩展的方式:
① 购买更好的服务器(纵向扩展(vertical scale or scaling up)),有局限性
② 购买更多的服务器(横向扩展(horizontal scale orscaling out)),推荐,通过增加节点来均摊负载和增加可靠性
关键词:
集群(cluster)、节点(node)、分片(shards)
1.1.空集群
只有一个空节点运行的集群;
空节点:没有数据和索引
解释:
【关系】
一个节点(node)就是一个Elasticsearch实例;
一个集群(cluster)由一个或多个节点组成,它们具有相同的 cluster.name,它们协同工作,分享数据和负载;
当加入新的节点或者删除一个节点时,集群就会感知到并平衡数据;
【选举】
集群中一个节点会被选举为主节点(master),它将临时管理集群级别的一些变更;
主节点不参与文档级别的变更或搜索,这意味着在流量增长的时候,该主节点不会成为集群的瓶颈;
解释:(主节点可以设置是否能存放数据,如果存放数据,则会有可能发生瓶颈(主要是硬盘))
任何节点都可以成为主节点;
【用户】
能够与集群中的任何节点通信,包括主节点;
每一个节点都知道文档存在于哪个节点上,它们可以转发请求到相应的节点上;
访问的节点负责收集各节点返回的数据,最后一起返回给客户端;
1.2.集群健康(cluster health)
集群健康状态(status): green 、 yellow 、 red
颜色 | 意义 |
green | 所有主要分片(primary shard)和复制分片(replica shard)都可用 |
yellow | 所有主要分片(primary shard)可用,但不是所有复制分片(replica shard)都可用 |
red | 不是所有的主要分片(primary shard)都可用 |
GET /_cluster/health
1.3.添加索引(index)
索引(index)
一个存储关联数据的地方
只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”
分片(shard)
一个最小级别“工作单元(worker unit)”
只是保存了索引中所有数据的一部分
一个Lucene实例,并且它本身就是一个完整的搜索引擎
我们的应用程序不会直接与它们通信,取而代之的是,直接与索引通信
在集群中分发数据的关键
把分片想象成数据的容器。文档存储在分片中,然后分片分配到你集群中的节点上
当你的集群扩容或缩小,Elasticsearch将会自动在你的节点间迁移分片,以使集群保持平衡
分片可以是主分片(primary shard)或者是复制分片(replica shard)
你索引中的每个文档属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据
理论上主分片能存储的数据大小是没有限制的,限制取决于你实际的使用情况。分片的
最大容量完全取决于你的使用状况:硬件存储的大小、文档的大小和复杂度、如何索引
和查询你的文档,以及你期望的响应时间。
复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求
当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整
默认情况下,一个索引被分配5个主分片
1.4.增加故障转移
启动第二个节点
第二个节点与第一个节点有相同的 cluster.name(./config/elasticsearch.yml 文件),就能自动发现并加入第一个节点所在的集群。
1.5.横向扩展
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
假设主节点上有3个主分片,那么复制分片就是2*3=6个
假设有3个节点启动,那么复制分片可以均摊
假设number_of_replicas 为1,则复制分片为1*3=3个
[注意]
在同样数量的节点上增加更多的复制分片并不能提高性能,因为这样做的话平均每个分片的所占有的硬件资源就减少了
(注:大部分请求都聚集到了分片少的节点,导致一个节点吞吐量太大,反而降低性能),你需要增加硬件来提高吞吐量。
不过这些额外的复制节点产生更多的冗余:通过以上对节点的设置,能够承受两个节点故障而不丢失数据。
1.6.应对故障
假设有3个节点运行,每个节点上有3个分片
把主节点杀掉,剩下2个节点选举出主节点,状态为yellow
解释:指定了每个主分片对应两个复制分片,当前却只有一个复制分片被分配
然后把杀掉的节点起来,它将会尝试再利用它们,从主分片上复制在故障期间有数据变更的那一部分