es集群详解

1、集群的介绍：

1.1、单机的elasticsearch做数据存储

必然面临两个问题：海量数据存储问题、单点故障问题。海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点。从逻辑上，将索引库上面的数据，拆分成N份，每一份叫做分片，也就是将索引库上面的数据拆分N个分片，从而存储到多个节点上面。那么从存储能力就是多个节点能力之和。 从而理论上讲，节点越多，存储容量越大。

单点故障问题：将分片数据在不同节点备份（replica ）

主分片和副分片，不能放在统一节点上面。如果某一节点挂掉，那么其他节点的数据加在一起也是完整数据。

1.2、ES集群相关概念:

ES 天生支持集群模式

集群（cluster）：一组拥有共同的 cluster name 的 节点。
节点（node)
分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中
解决问题：数据量太大，单点存储量有限的问题。

主分片（Primary shard）：相对于副本分片的定义。
副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。
数据备份可以保证高可用，但是每个分片备份一份，所需要的节点数量就会翻一倍，成本实在是太高了！

为了在高可用和成本间寻求平衡，我们可以这样做：

首先对数据分片，存储到不同节点
然后对每个分片进行备份，放到对方节点，完成互相备份
这样可以大大减少所需要的服务节点数量，如图，我们以3分片，每个分片备份一份为例：

现在，每个分片都有1个备份，存储在3个节点：

node0：保存了分片0和1
node1：保存了分片0和2
node2：保存了分片1和2

2、搭建3台集群

部署es集群可以直接使用docker-compose来完成，不过要求你的Linux虚拟机至少有4G的内存空间

1.上传运行集群的文件：
首先编写一个docker-compose文件，内容如下：在一个文件里面描述多个容器的部署方式，从而形成一键部署的方式

es01:image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1  // 每个都采用的是相同镜像container_name: es01  //创建的容器的名称 01/02/03environment:			 //环境变量- node.name=es01		// 节点名称。在集群中每个节点都有自己的名字，不能重复。【选择和跟容器名字保持一致】- cluster.name=es-docker-cluster	//集群名称。天生支持集群。启动多台机器，只需要集群名称一样，ES就会把多台机器组成集群。//从而每台节点，都会指定相同的集群名称。- discovery.seed_hosts=es02,es03	// 集群当中，其他节点的ip地址。我们是通过docker容器，容器内是互连，那么可以通过容器名字进行互连.- cluster.initial_master_nodes=es01,es02,es03	//初始化的主节点。指定候选的主节点。主节点是通过选举进行得到主节点。- bootstrap.memory_lock=true- "ES_JAVA_OPTS=-Xms512m -Xmx512m"	// 配置堆内存的大小ulimits:memlock:soft: -1hard: -1volumes:			//数据卷- data01:/usr/share/elasticsearch/dataports:	//端口映射  容器外：容器内。  容器外就是宿主机的端口号，那么其他节点需要变动宿主机的端口号- 9200:9200networks:- elastic

version: '2.2'
services:es01:image: docker.elastic.co/elasticsearch/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- bootstrap.memory_lock=true- "ES_JAVA_OPTS=-Xms512m -Xmx512m"ulimits:memlock:soft: -1hard: -1volumes:- data01:/usr/share/elasticsearch/dataports:- 9200:9200networks:- elastices02:image: docker.elastic.co/elasticsearch/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- bootstrap.memory_lock=true- "ES_JAVA_OPTS=-Xms512m -Xmx512m"ulimits:memlock:soft: -1hard: -1volumes:- data02:/usr/share/elasticsearch/datanetworks:- elastices03:image: docker.elastic.co/elasticsearch/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- bootstrap.memory_lock=true- "ES_JAVA_OPTS=-Xms512m -Xmx512m"ulimits:memlock:soft: -1hard: -1volumes:- data03:/usr/share/elasticsearch/datanetworks:- elasticvolumes:data01:driver: localdata02:driver: localdata03:driver: localnetworks:elastic:driver: bridge

2.修改权限在进行运行
es运行需要修改一些Linux系统权限，修改/etc/sysctl.conf文件
添加下面的内容vm.max_map_count = 262144 然后执行命令，让配置生效：sysctl -p

[root@localhost ~]# vi /etc/sysctl.conf vm.max_map_count = 262144 [root@localhost ~]# sysctl -p vm.max_map_count = 262144

3.运行文件，从而运行集群
docker-compose up -d

4.集群状态监控
1.下载cerebro ，并运行
使用cerebro来监控es集群状态，地址：https://github.com/lmenezes/cerebro 下载解压后，直接运行Bin目录的cerebro.bat即可。

从而在浏览器访问：localhost:9000 即可

2.输入节点的地址和端口号：
 

3. 页面解释：
实心是：master节点
空心是：候选节点

在创建索引库的时候，索引库可以分片，放到不同的节点上面。

在创建索引库的时候，指定settings：

number_of_shards:3, //分片数量。 说明索引库分为3片，默认是1

number_of_replicas:1 //副本数量。 说明每一篇加一个副本

Index successfully created```分片是：3片*2。实心是主分片。每个主副都是在不同主机上面。从而确保当某一台主机宕机后，而备份还在。

三、不同节点角色和职责的划分
master eligible ：候选主节点
可以参与当主节点。主节点非常重要，集群都是由主节点来进行监管。
data ：数据节点
创建索引、搜索、聚合crud
ingest：数据存储之前的预处理
插入文档到数据库中，比如增删改查某个字段。当java代码直接往数据库存储，不需要预处理，那么Ingest是无用处的。 所以用的少
coordinating：协调节点
不做业务处理，做协调。比如用户请求，搜索数据，到达协调节点，路由到真正处理数据节点当中，那么数据节点处理后，会进行返回到协调节点。协调节点在进行合并，返回给用户。 从而：路由+负载均衡+合并结果。
 

默认情况es节点，同时具备这四种角色。实际开发当中，不允许同时具备四个角色。

不同角色对硬件要求不一样：

· 主节点管理，只需要对CPU有要求

· 数据节点：crud对磁盘要求。聚合对CPU要求

· 协调节点：请求、转发 对CPU有要求。磁盘无要求

从而不同的角色有不同的硬件支持。

除了协调节点其他都可以为false，那么也就是说：所有节点都必须做协调操作。
那么专门做协调节点的，可以把其他角色全部为false，就可以是专门做协调角色的节点了。

集群的结构：
3个coordinating协调节点（前面加了负载均衡器，对协调节点做负载均衡，请求来了不同的节点进行接收，从而提高并发能力，协调节点路由到数据节点）
n个数据节点。可以海量存储、避免单点故障
3个候选master节点（当master节点挂了，可以马上有候选节点进行选举。从而健壮性有了保障）

脑裂问题：
默认情况，每个节点都是master eligible节点，因此一旦master节点宕机，其他候选节点会选举一个成为主节点。
当主节点与其他节点网络故障时【网络故障并不是宕机】，可能发生脑裂问题。
网络故障，只是导致连接不上其他节点。但是主节点是可以跟数据节点能正常连接。而其他节点也可以和数据节点进行正常连接，当其他节点连接不上主节点时，会认为主节点挂掉了。那么其他分节点会自选一个节点当主节点。那么问题来了：就会造成有两个主节点了，从而会造成数据不一致的问题

解决脑裂方法：
为了避免脑裂，需要要求选票超过（eligible候选节点数量+1）/2才能 当选为主节点，因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum_master_nodes，在es7.0后，以及成为默认配置，因此一般不会出现脑裂情况。

当有3个节点，假设主节点1出现网络故障，那么节点1想选自己当主节点，节点2 和节点3 选择节点3当主节点。 节点1只有自己一票，会失败。 节点3有节点2和3，有两票会成功，从而节点3会成为主节点。 从而节点3变成了主节点。
要求是：要想成功则 候选节点数量+1除以2，3加1除以2 =2。那么就是说的得需要两个节点投票才能成功。

4、分布式新增和删除流程

协调节点如何工作的呢？
协调节点是如何把数据分到不同的片上呢？不同的片上是好的，可以确保负载均衡。
elasticsearch会通过hash算法来计算文档应该存储到哪个分片：
_rounting：默认是文档的id
number_of_shards： 分片的数量 。例如是3
那么hash出来一个数据，对分片数量进行取余，那么结果只有：012三种情况。将数据均衡的分散到了不同的分片当中。

算法与分片数量有关，因此索引库一旦创建，分片数量不能修改

该算法，数据存放的位置跟分片的数量有关系。当取数据时，也是通过算法去改分片进行查找数据。 如果将分片数量更改后，那么在根据相同的算法，去取数据，就可能查找失败了。

新增文档流程：

有3个节点：node1/node2/node3
每个节点有两份数据：主分片主数据.
深颜色为主分篇、浅颜色的是：副分片。

当文档id=1，请求到达了node1，那么就充当协调节点角色。那么协调节点会根据hash算法运算。
hash运算的到结果是2，说明应该将数据放到2号分片。
那么协调节点就会路由到，node3节点。
node3将数据写到分片2。
由于是写到主分片，那么就会把主分片同步到副分片node2。
从而将数据写到主副分片后，那么两个节点将结果返回协调节点node1上面。
协调节点将信息返回给用户：“新增成功”

分布式查询过程：
查询任何一个节点都可以查到信息. 是因为：

第一阶段：分散阶段：coordinating node协调节点 会把请求分发到每一个分片上面。

每个节点都进行查询。其实可以保障能查到结果是完整的

第二阶段：聚集极端，coordinating node汇总data node的搜索结果，并处理为最终结果集返给用户

每个节点查询结果，返回协调节点。协调节点进行汇总结果，返回用户.。
协调节点也可也是数据节点。

六、主节点故障转移
集群的master节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。

master节点监控分片、节点状态，将故障节点上的分片转移到正常节点，确保数据安全。

现在，node1是主节点，其它两个节点是从节点。

突然，node1发生了故障：

宕机后的第一件事，需要重新选主，例如选中了node2：

node2成为主节点后，会检测集群监控状态，发现：shard-1、shard-0没有副本节点。因此需要将node1上的数据迁移到node2、node3：

模拟主节点故障转移： CP
停掉主节点：

docker-compose stop es01

第一：选择主节点

第二：将宕机的节点的数据，备份到其他节点。

当宕机的节点回复后：
第一：之前的主节点，会变成副节点。
第二：数据从新均衡。

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。【等待，得到一致】
Availability（可用性）用户访问集群中的任意健康节点，必须得到相应，而不是超时或拒绝。【追求可用就行，不管数据一致不一致】
Partition分区：网络的故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。
当网络出现故障时，节点之间断开连接【P分区容错】，ES集群处于警告状态，一段时间后异常节点就会被剔除【失去可用性A】，原来的数据分片会分到健康的节点中去【数据一致性C】。

-----------------------------------
es集群 数据浏览 es数据库集群
https://blog.51cto.com/u_16099165/10117967