前言

单机ES做数据存储，必然面临两个问题：海量数据的存储，单点故障。

如何解决这两个问题？

• 海量数据的存储问题： 将索引库从逻辑上拆分为N个分片（shard），存储到多个节点。
• 单点故障问题： 将分片数据在不同节点备份（replica）

缺点是什么？ 造成资源的消耗的N倍的。

一、搭建ES集群

使用docker容器模拟ES的节点

1、一键启动文件 docker-compose.yml

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/dataports:- 9202:9200networks:- elasticvolums:data01:driver: localdata02:driver: localdata03:driver: localnetworks:elastic:driver: bridge

2、更改linux系统权限 /etc/sysctl.conf，并启动docker

# command
vi /etc/sysctl.conf#添加内容
vm.max_map_count=262144#执行命令，完成配置
sysctl -p#一键部署docker
docker-compose up -d

效果图

3、利用cerebro监控es集群状态

kibana当然可以监控es集群，但新版本需要依赖es的 x-pack 功能，配置较为复杂。
所以我们使用cerebro监控es集群，官网：https://github.com/lmenezes/cerebro

使用的是 cerebro-0.9.4

开启 cerebro： 双击/bin/cerebro.bat 即可。

访问localhost:9000

我们可以输入任意一个ES地址，例如虚拟机IP:9200

4、创建索引库

方式一：kibana的DevTools创建索引库

PUT /zengoo
{"settings": {"number_of_shards": 3,	#	分片数量"number_of_replicas": 1	#	副本数量},"mappings":	{"properties":	{//..mapping映射的定义}}
}

方式二：利用cerebro创建索引

二、集群脑裂问题

（一）ES集群的节点角色

节点类型	配置参数	默认值	节点职责
master-eligible	node.master	true	备选主节点 主节点可以管理和记录集群状态 决定分片在哪个节点 处理创建和删除索引库的请求
data	node.data	true	数据节点：存储数据、搜索、聚合、CRUD
ingest	node.ingest	true	数据存储之前的预处理
coordinating	上面三个都为false则为coordinating节点	无	路由请求到其它节点 合并其它节点处理的结果，返回用户

（二）ES集群的分布式查询

ES中的每个节点角色都有自己的不同职责，因此建议集群部署时，每个节点都有独立的角色。

分布式查询流程

用户 》 负载均衡器 》 coordinating 节点 》 data 节点 》 master-eligible

（三）集群的脑裂

1、概念： 指的是主节点由于网络问题与其他节点失去联系，其它节点处于选举时期，重新选取一个备用主节点，当网络恢复时，集群当中可能会产生两个及以上的主节点，这就是脑裂。

2、解决方式： 通过配置选票条件，当选票（超过主节点数+1）当选为主节点，因此主节点的数量最好是奇数。discovery.zen.minimum_master_nodes，在es7.0后，称为默认配置，一般不会发生脑裂问题。

---

三、集群故障转移

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

我们不需要自己实现故障转移，master节点已经实现了故障转移

---

四、集群分布式存储

当新增文档时，应该保存到不同的分片，保证数据均衡，那么 coordinating node如何确定数据存储到哪个分片上？

（1）负载均衡的原理

ES通过hash算法来计算文档的存储位置，shard = hash(_routing) % number_of_shards

• _routing：默认是文档的id
• 算法与分片数量有关，因此索引库一旦被创建，分片数量就不能修改

（2）新增文档的流程

• 用户新增文档id=1，向coordinating 节点发起请求
• 经过hash运算，hash=2
• coordinating 节点路由到分配了2号分片的节点
• 在分配了2号分片的节点存储文档，并查询对应的备份节点
• 存储的节点向有2号备份分片备份的节点同步数据
• 主分片与备用分片所在节点公共返回结果给coordinating 节点
• coordinating 节点将结果返回给用户

五、集群分布式查询

ES查询的两个阶段：

• scatter phase： 分散阶段，coordinating node会把请求分发到每个分片上。
• gather phase： 聚集阶段，coordinating node汇总data node搜索结果，并处理为最终结果集返回用户。