南通网站建设哪家好没有专项备案的网站
目录
前言
搭建ES集群
集群状态监控
分片备份
节点角色
脑裂问题
分布式存储
分布式查询
故障转移
前言
单机的ES做数据存储必然会面临两个问题:海量数据存储问题、单机故障问题
海量数据存储问题:将索引库从逻辑上拆分为N个分片(shard),存储到多个节点。
单机故障问题:将分片数据在不同节点备份(replica)

搭建ES集群
在Docker中部署三个ES节点。请确保虚拟机存在至少4G运行内存。
下面是docker-compose文件的内容
version: '2.2'
services:es01:image: elasticsearch:7.12.1container_name: es01environment:- node.name=es01- cluster.name=es-docker-cluster- discovery.seed_hosts=es02,es03- cluster.initial_master_nodes=es01,es02,es03- "ES_JAVA_OPTS=-Xms512m -Xmx512m"volumes:- data01:/usr/share/elasticsearch/dataports:- 9200:9200networks:- elastices02:image: elasticsearch:7.12.1container_name: es02environment:- node.name=es02- cluster.name=es-docker-cluster- discovery.seed_hosts=es01,es03- cluster.initial_master_nodes=es01,es02,es03- "ES_JAVA_OPTS=-Xms512m -Xmx512m"volumes:- data02:/usr/share/elasticsearch/dataports:- 9201:9200networks:- elastices03:image: elasticsearch:7.12.1container_name: es03environment:- node.name=es03- cluster.name=es-docker-cluster- discovery.seed_hosts=es01,es02- cluster.initial_master_nodes=es01,es02,es03- "ES_JAVA_OPTS=-Xms512m -Xmx512m"volumes:- data03:/usr/share/elasticsearch/datanetworks:- elasticports:- 9202:9200
volumes:data01:driver: localdata02:driver: localdata03:driver: localnetworks:elastic:driver: bridge 
修改虚拟机配置
vi /etc/sysctl.conf
vm.max_map_count = 262144
#max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量 
保存后刷新配置文件
sysctl -p 
使用docker-compose启动三个容器
docker-compose up -d 
 

集群状态监控
处理在浏览器访问9200、9201、9202端口外,还能使用一种ES集群可视化工具Cerebro。我们选择win版本的可视化工具。
下载地址为:Tags · lmenezes/cerebro (github.com)
启动时如果报错加载缓存错误,更换JDK版本即可。在cerebro.bat文件中添加如下代码

双击启动运行图如下

访问9000端口。


输入集群其中一个节点即可连接整个集群。节点名称前面的星号实心代表是主节点,空心代表是候选节点。
分片备份
可以使用Kibana或Cerebro来实现。
如果使用Kibana实现分片,那么在创建索引库时指定
PUT /索引库名
{"settings":{"number_of_shards":3, //分片数量"number_of_replicas":1//副本数量
},"mappings":{}
} 
使用Cerebro时,则如下图所示


创建完成后

节点角色
|   节点类型  |   配置参数  |   默认值  |   节点职责  | 
|   master eligible  |   node.master  |   true  |   备选主节点:主节点可以管理和记录集群状态,决定分片在哪个节点,处理创建和删除索引库的请求  | 
|   data  |   node.data  |   true  |   数据节点:存储数据,搜索、聚合、CRUD  | 
|   ingest  |   node.ingest  |   true  |   数据存储之前的预处理  | 
|   coordinating  |   上面3个参数都为false则为coordinating节点  |   无  |   协调节点:路由请求到其他节点,合并其他节点处理的结果,返回给用户  | 
如果没有配置,每个节点四个职责都会处理,但是在生产环境,通常不会这样。每个节点都是单一职责。其次通常不需要ingest节点,数据预处理通常在Java代码中完成,不会让ES去做。

脑裂问题
默认情况下,每个节点都是master eligible节点,因此一旦master节点宕机,其他候选节点会选举一个成为主节点,但是当主节点与其他节点网络故障时,可能会发生脑裂问题。

当候选主节点无法连接到主节点时,会从候选主节点中选举一个重新作为主节点。。去实现索引库的增删。当网络恢复时,集群中就出现了2个主节点,且两个节点的数据不一致。

为了避免出现脑裂问题,需要要求选票超过(候选节点数量+1)/2才能成为主节点。
当开始重新选举主节点时,node1会投自己一票,由于node2与node3连接不上node1。因此,node2与node3中会选举出一个主节点。如果node2与node3都投node3节点为主节点,那么(3+1)/2 = 2。node3成为主节点,node1成为候选主节点。
候选主节点数量最好为奇数。对应配置项是discovery.zen.minimum_master_nodes,在es7版本之后,已经成为一个默认配置,因此一般不会发生脑裂问题。
分布式存储
测试向之间创建的索引库插入数据三条数据。

接下来查询数据。

可以看到在9200节点增加的数据在9201也可以查询。添加配置查询每个数据都存储在哪些节点上

每条数据会被存储到哪个分片是由coordinating决定的。具体算法如下

说明
- _routing默认是文档id
 - 算法与分片数量有关,因此索引库一旦创建,分片数量不能修改
 

分布式查询
ES的查询分为两个阶段:
- scatter phase:分散阶段,协调节点会把请求分发到每一个分片中
 - gather phase:聚集阶段,协调节点汇总数据节点的搜索结果,并处理为最终结果集返回给用户
 

故障转移
集群中master节点会监控集群中的节点状态,如果发现有节点宕机,会立即将宕机节点的分片数据迁移到其他节点,确保数据安全。

测试:



接下来重启es01节点。

我并没有搜到好的解释为什么重启的节点会分到两个副本分片,理论上来讲应该会分到一个主分片和副本分片。
