微服务9--Elasticsearch集群

六月雨丶终成忆

已于 2022-09-03 16:32:32 修改

阅读量286

点赞数

分类专栏：微服务文章标签： elasticsearch docker 大数据

于 2022-09-03 16:10:31 首次发布

原文链接：https://www.xn2001.com/archives/663.html

版权

微服务专栏收录该内容

14 篇文章 0 订阅

订阅专栏

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

解决方案：

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

ES集群相关概念：

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

此处，我们把数据分成3片：shard0、shard1、shard2

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

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

数据备份可以保证高可用，但是每个分片备份一份在节点上，所需要的节点数量就会翻倍，成本太高。为了在高可用和成本间寻求平衡

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

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

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

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

部署集群

搭建Elasticsearch

我们会在单机上利用 Docker 容器运行多个 Elasticsearch 实例来模拟集群。

可以直接使用 docker-compose 来完成，这要求你的Linux虚拟机至少有4G以上的内存空间。

docker-compose.yml

version: '2.2'
services:
  es01:
    image: elasticsearch:7.12.1
    container_name: es01
    environment:
      - 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/data
    ports:
      - 9200:9200
    networks:
      - elastic
  es02:
    image: elasticsearch:7.12.1
    container_name: es02
    environment:
      - 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/data
    ports:
      - 9201:9200
    networks:
      - elastic
  es03:
    image: elasticsearch:7.12.1
    container_name: es03
    environment:
      - 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/data
    networks:
      - elastic
    ports:
      - 9202:9200
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

修改 Linux 系统权限，修改 /etc/sysctl.conf 文件

vi /etc/sysctl.conf

添加下面的内容

vm.max_map_count=262144

让配置生效：

sysctl -p

通过docker-compose启动集群

docker-compose up -d

集群状态监控

kibana 可以监控 Elasticsearch 集群，但是更推荐使用 cerebro

下载解压打开 /bin/cerebro.bat

访问 http://localhost:9000 即可进入管理界面

输入任意节点的地址和端口，点击 connect

绿色的线条代表集群处于绿色（健康状态）

创建索引库

我们还可以通过 cerebro 创建索引库，当然你需要使用 kibana 也可以。

填写索引库信息

回到首页，即可查看索引库分片效果

集群职责划分

Elasticsearch 中集群节点有不同的职责划分

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

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

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

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

集群脑裂问题

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

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

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

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

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

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

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