【博学谷学习记录】超强总结，用心分享|狂野架构师elasticsearch常用知识点三

目录

• ElasticSearch高级操作
• ElasticSearch查询
• ElasticSearch 集群
  • 集群介绍
  • ES集群相关概念
  • 集群搭建
  • kibina管理集群
  • 分片配置
    • 分片与自平衡
    • 索引分片推荐配置方案：
  • 路由原理
• 脑裂
  • 脑裂现象
  • 脑裂产生的原因
  • 避免脑裂

ElasticSearch高级操作

ElasticSearch查询

ElasticSearch 集群

集群介绍

	比喻	解决的问题
集群	多个人做一样的事	让系统高可用，分担请求压力
分布式	多个人做不一样的事	分担存储和计算的压力，提速；解耦

ElasticSearch 的设计隐藏了分布式本身的复杂性天然支持分布式

ES集群相关概念

集群（cluster）：一组拥有共同的 cluster name 的 节点。

节点（node) ：集群中的一个 Elasticearch 实例。

索引（index) ：es存储数据的地方。相当于关系数据库中的database概念。

分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同。

分片可以拆分到不同的节点中

主分片（Primary shard）：相对于副本分片的定义。

副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

集群搭建

参考https://www.cnblogs.com/xieshier/p/16538627.html

kibina管理集群

vim kibana-7.4.0-linux-x86_64-cluster/config/kibana.yml

kibana.yml

#支持中文 
i18n.locale: "zh-CN" 
#5602避免与之前的冲突 
server.port: 5602 
server.host: "0.0.0.0" 
server.name: "kibana-itcast-cluster" 
elasticsearch.hosts: 
["http://localhost:9201","http://localhost:9202","http://localhost:9203"] 
elasticsearch.requestTimeout: 99999

分片配置

在创建索引时，如果不指定分片配置，则默认主分片1，副本分片1。

在创建索引时，可以通过settings设置分片

#分片配置 
#"number_of_shards": 3, 主分片数量 
#"number_of_replicas": 1 主分片备份数量，每一个主分片有一个备份 
# 3个主分片+3个副分片=6个分片 
PUT cluster_test1 
{ 
	"settings": { 
		"number_of_shards": 3, 
		"number_of_replicas": 1 
	},
	"mappings": { 
		"properties": { 
			"name":{ 
				"type": "text" 
			} 
		} 
	} 
}

分片与自平衡

当节点挂掉后，挂掉的节点分片会自平衡到其他节点中

注意：分片数量一旦确定好，不能修改。

索引分片推荐配置方案：

1.每个分片推荐大小10-30GB

2.分片数量推荐 = 节点数量 * 1~3倍

思考：比如有1000GB数据，应该有多少个分片？多少个节点

1.每个分片20GB 则可以分为40个分片

2.分片数量推荐 = 节点数量 * 1~3倍 --> 40/2=20 即20个节点

路由原理

文档存入对应的分片，ES计算分片编号的过程，称为路由。

怎么知道应该存放到哪个分片中呢？

查询时，根据文档id,Elasticsearch又该去哪个分片中查询数据呢?

路由算法 ：shard_index = hash(id) % number_of_primary_shards

（分片 = hashId % 分片数量）

脑裂

ElasticSearch 集群正常状态：

1.一个正常es集群中只有一个主节点（Master），主节点负责管理整个集群。如创建或删除索引，跟踪

哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

2.集群的所有节点都会选择同一个节点作为主节点。

脑裂现象

脑裂问题的出现就是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点从而使集群分裂，使得集群处于异常状态。

脑裂产生的原因

1.网络延迟

一般es集群会在内网部署，也可能在外网部署，比如阿里云。

内网一般不会出现此问题，外网的网络出现问题的可能性大些。

2.节点负载

主节点的角色既为master又为data。数据访问量较大时，可能会导致Master节点停止响应（假死状态）。

3.JVM内存回收:当Master节点设置的JVM内存较小时，引发JVM的大规模内存回收，造成ES进程失去响应。

避免脑裂

1.网络原因：discovery.zen.ping.timeout 超时时间配置大一点。默认是3S

2.节点负载：角色分离策略

候选主节点配置为

node.master: true

node.data: false

数据节点配置为

node.master: false

node.data: true

3.JVM内存回收：修改 config/jvm.options 文件的 -Xms 和 -Xmx 为服务器的内存一半。