SpringCloud：ElasticSearch之集群

「爱情、让人受尽委屈。」 2024-03-22 06:27 115阅读 0赞

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

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

**ES集群相关概念**:

*  集群（`cluster`）：一组拥有共同的`cluster name` 的 节点。
 *  节点（`node`) ：集群中的一个 `Elasticearch` 实例
 *  分片（`shard`）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中
    
    解决问题：数据量太大，单点存储量有限的问题。
    
    ![在这里插入图片描述][bfb724c9d91840ffbbd90f3bb97fefa5.png_pic_center]
    
    > 此处，我们把数据分成3片：`shard0`、`shard1`、`shard2`
 *  主分片（`Primary shard`）：相对于副本分片的定义。
 *  副本分片（`Replica shard`）每个主分片可以有一个或者多个副本，数据和主分片一样。

数据备份可以保证高可用，但是每个分片备份一份，所需要的节点数量就会翻一倍，成本实在是太高了！

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

*  首先对数据分片，存储到不同节点
 *  然后对每个分片进行备份，放到对方节点，完成互相备份

这样可以大大减少所需要的服务节点数量，如图，我们以3分片，每个分片备份一份为例：

![在这里插入图片描述][d76aba497a3a4d4a8bc9dee70d216e32.png_pic_center]

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

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

### 2.集群脑裂问题 ###

#### 2.1.集群职责划分 ####

`elasticsearch`中集群节点有不同的职责划分：

![在这里插入图片描述][d06b07aae62740e4b55abafaf53ba9fb.png_pic_center]

默认情况下，集群中的任何一个节点都同时具备上述四种角色。

但是真实的集群一定要将集群职责分离：

*  `master`节点：对`CPU`要求高，但是内存要求第
 *  `data`节点：对`CPU`和内存要求都高
 *  `coordinating`节点：对网络带宽、`CPU`要求高

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署。而且避免业务之间的互相干扰。

一个典型的`es`集群职责划分如图：

![在这里插入图片描述][baa6e71dfbae4a618171371fa4c4e69c.png_pic_center]

#### 2.2.脑裂问题 ####

脑裂是因为集群中的节点失联导致的。

例如一个集群中，主节点与其它节点失联：

![在这里插入图片描述][bed308121e354d969239ff9de00cd73c.png_pic_center]

此时，`node2`和`node3`认为`node1`宕机，就会重新选主：

![在这里插入图片描述][942a618f8a81479e90a640eb92c0005d.png_pic_center]

当`node3`当选后，集群继续对外提供服务，`node2`和`node3`自成集群，`node1`自成集群，两个集群数据不同步，出现数据差异。

当网络恢复后，因为集群中有两个`master`节点，集群状态的不一致，出现脑裂的情况：

![在这里插入图片描述][e464d672943947768e2885aab619e2d2.png_pic_center]

解决脑裂的方案是，要求选票超过`( eligible节点数量 + 1 ）/ 2`才能当选为主，因此`eligible`节点数量最好是奇数。对应配置项是`discovery.zen.minimum_master_nodes`，在`es7.0`以后，已经成为默认配置，因此一般不会发生脑裂问题

例如：3个节点形成的集群，选票必须超过 `（3 + 1） / 2`，也就是2票。`node3`得到`node2`和`node3`的选票，当选为主。`node1`只有自己1票，没有当选。集群中依然只有1个主节点，没有出现脑裂。

#### 2.3.小结 ####

`master eligible`节点的作用是什么？

*  参与集群选主
 *  主节点可以管理集群状态、管理分片信息、处理创建和删除索引库的请求

`data`节点的作用是什么？

*  数据的`CRUD`

`coordinator`节点的作用是什么？

*  路由请求到其它节点
 *  合并查询到的结果，返回给用户

### 3.集群分布式存储 ###

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

#### 3.1.分片存储测试 ####

插入多条数据：

![在这里插入图片描述][50e241c8d0e847568e752fb50e667af5.png_pic_center]

测试可以看到，三条数据分别在不同分片：

![在这里插入图片描述][0f4d34232b8d4bbca0854e093bd973b6.png_pic_center]

#### 3.2.分片存储原理 ####

`elasticsearch`会通过`hash`算法来计算文档应该存储到哪个分片：

![在这里插入图片描述][03e5ab36da8f4a7c97f10958207f330f.png_pic_center]

说明：

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

新增文档的流程如下：

![在这里插入图片描述][6242afeefbf4490f802752984d26e954.png_pic_center]

解读：

*  1）新增一个`id`=1的文档
 *  2）对id做`hash`运算，假如得到的是2，则应该存储到`shard-2`
 *  3）`shard-2`的主分片在`node3`节点，将数据路由到`node3`
 *  4）保存文档
 *  5）同步给`shard-2`的副本`replica-2`，在`node2`节点
 *  6）返回结果给`coordinating-node`节点

### 4.集群分布式查询 ###

`elasticsearch`的查询分成两个阶段：

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

![在这里插入图片描述][4594a9ef242248748015502101637963.png_pic_center]

### 5.集群故障转移 ###

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

1）例如一个集群结构如图：

![在这里插入图片描述][fe45fcd75df84944b90eb12cfbc09a20.png_pic_center]

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

2）突然，`node1`发生了故障：

![在这里插入图片描述][29ce343c0a3842699a68ac0b8f355b4a.png_pic_center]

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

![在这里插入图片描述][2f2693881ee8456a8783a94a532c5644.png_pic_center]

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

![在这里插入图片描述][62d42460460149249fd9c7d328a92e25.png_pic_center]

[bfb724c9d91840ffbbd90f3bb97fefa5.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/e4c21cdf05da41edbe56fff166e32371.png
[d76aba497a3a4d4a8bc9dee70d216e32.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/0b9b3b46b2894cc9940ca296dbcd69f3.png
[d06b07aae62740e4b55abafaf53ba9fb.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/a21f52d8dc8240438f50b667dd84745d.png
[baa6e71dfbae4a618171371fa4c4e69c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/9a626c377a0648abb96846ec262a4759.png
[bed308121e354d969239ff9de00cd73c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/1bea80fc63c243ef8a65d888f8f3e401.png
[942a618f8a81479e90a640eb92c0005d.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/618d64ddb5e54ec989f43e7f4ca5f70d.png
[e464d672943947768e2885aab619e2d2.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/84e718058bfe4568b8f2b0e5fd72be6c.png
[50e241c8d0e847568e752fb50e667af5.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/21c403014de545dba38d8dd867e638a6.png
[0f4d34232b8d4bbca0854e093bd973b6.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/bec51492f07040a2a84e59c721fb6915.png
[03e5ab36da8f4a7c97f10958207f330f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/65690ad51a064564b1878ed83fe17a19.png
[6242afeefbf4490f802752984d26e954.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/e0504c2b70c147058c476a164edcc1f5.png
[4594a9ef242248748015502101637963.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/6b3d4dbea85e4869a4fc1735f9f25998.png
[fe45fcd75df84944b90eb12cfbc09a20.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d0fd0d022b8d4baf8f8951ac5e567c83.png
[29ce343c0a3842699a68ac0b8f355b4a.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/b4ec8bdbb14341aca731d93a9e5c954f.png
[2f2693881ee8456a8783a94a532c5644.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/8628975d257d48a4a7627170fdad6c72.png
[62d42460460149249fd9c7d328a92e25.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/3ffb327fa1f7468f97776babb61e13a4.png