关于java:分布式搜索引擎ElasticSearch之高可用集群搭建配置

29次阅读

共计 4844 个字符,预计需要花费 13 分钟才能阅读完成。

1. ElasticSearch 集群介绍

  • 主节点(或候选主节点)

    主节点负责创立索引、删除索引、调配分片、追踪集群中的节点状态等工作,主节点负荷绝对较轻,客户端申请能够间接发往任何节点,由对应节点负责散发和返回处理结果。

    一个节点启动之后,采纳 Zen Discovery 机制去寻找集群中的其余节点,并与之建设连贯,集群会从候选主节点中选举出一个主节点,并且一个集群只能选举一个主节点,在某些状况下,因为网络通信丢包等问题,一个集群可能会呈现多个主节点,称为“脑裂景象”,脑裂会存在失落数据的可能,因为主节点领有最高权限,它决定了什么时候能够创立索引,分片如何挪动等,如果存在多个主节点,就会产生抵触,容易产生数据失落。要尽量避免这个问题,能够通过 discovery.zen.minimum_master_nodes 来设置起码可工作的候选主节点个数。倡议设置为(候选主节点 /2)+ 1 比方三个候选主节点,该配置项为(3/2)+1 , 来保障集群中有半数以上的候选主节点,没有足够的 master 候选节点,就不会进行 master 节点选举,缩小脑裂的可能。

    主节点的参数设置:

    node.master = true
    node.data = false
  • 数据节点

    数据节点负责数据的存储和 CRUD 等具体操作,数据节点对机器配置要求比拟高、,首先须要有足够的磁盘空间来存储数据,其次数据操作对系统 CPU、Memory 和 IO 的性能耗费都很大。通常随着集群的扩充,须要减少更多的数据节点来进步可用性。

    数据节点的参数设置:

    node.master = false
    node.data = true
  • 客户端节点

    客户端节点不做候选主节点,也不做数据节点的节点,只负责申请的散发、汇总等等,减少客户端节点类型更多是为了负载平衡的解决。

    node.master = false
    node.data = false
  • 提取节点(预处理节点)

    能执行预处理管道,有本人独立的工作要执行,在索引数据之前能够先对数据做预处理操作,不负责数据存储也不负责集群相干的事务。

    参数设置:

    node.ingest = true
  • 协调节点

    协调节点,是一种角色,而不是实在的 Elasticsearch 的节点,不能通过配置项来指定哪个节点为协调节点。集群中的任何节点,都能够充当协调节点的角色。当一个节点 A 收到用户的查问申请后,会把查问子句散发到其它的节点,而后合并各个节点返回的查问后果,最初返回一个残缺的数据集给用户。在这个过程中,节点 A 表演的就是协调节点的角色。

    ES 的一次申请十分相似于 Map-Reduce 操作。在 ES 中对应的也是两个阶段,称之为 scatter-gather。客户端收回一个申请到集群的任意一个节点,这个节点就是所谓的协调节点,它会把申请转发给含有相干数据的节点 (scatter 阶段),这些数据节点会在本地执行申请而后把后果返回给协调节点。协调节点将这些后果汇总(reduce) 成一个繁多的全局后果集(gather 阶段)。

  • 部落节点

    在多个集群之间充当联结客户端,它是一个非凡的客户端,能够连贯多个集群,在所有连贯的集群上执行搜寻和其余操作。部落节点从所有连贯的集群中检索集群状态并将其合并成全局集群状态。把握这一信息,就能够对所有集群中的节点执行读写操作,就如同它们是本地的。请留神,部落节点须要可能连贯到每个配置的集群中的每个单个节点。

2. ElasticSearch 集群原理

2.1 集群分布式原理

ES 集群能够依据节点数,动静调整分片与正本数,做到整个集群无效平衡负载。

单节点状态下:

两个节点状态下,正本数为 1:

三个节点状态下,正本数为 1:

三个节点状态下,正本数为 2:

2.2 分片解决机制

设置分片大小的时候,需事后做好容量布局,如果节点数过多,分片数过小,那么新的节点将无奈分片,不能做到程度扩大,并且单个分片数据量太大,导致数据重新分配耗时过大。

假如一个集群中有两个数据节点。movie 索引的分片散布状况如下所示:

PUT /orders
{
    "settings":{
        "number_of_shards":2,  // 主节点
        "number_of_replicas":2  // 正本节点
    }
}

整个集群中存在 P0 和 P1 两个主分片,P0 对应的两个 R0 正本分片,P1 对应的是两个 R1 正本分片。

2.3 新建索引解决流程

  1. 写入的申请会进入主节点,如果是 NODE2 正本接管到写申请,会将它转发至主节点。
  2. 主节点接管到申请后,依据 documentId 做取模运算(内部没有传递 documentId,则会采纳外部自增 ID),

    如果取模后果为 P0,则会将写申请转发至 NODE3 解决。

  3. NODE3 节点写申请解决实现之后,采纳异步形式,将数据同步至 NODE1 和 NODE2 节点。

2.4 读取索引解决流程

  1. 读取的申请进入 MASTER 节点,会依据取模后果,将申请转发至不同的节点。
  2. 如果取模后果为 R0,外部还会有负载平衡解决机制,如果上一次的读取申请是在 NODE1 的 R0,那么以后申请会转发至 NODE2 的 R0,保障每个节点都可能平衡的解决申请数据。
  3. 读取的申请如果是间接落至正本节点,正本节点会做判断,若有数据则返回,没有的话会转发至其余节点解决。

3. ElasticSearch 集群部署布局

筹备一台虚拟机:

10.10.20.28:Node-1(节点一), 端口:9200,9300

10.10.20.28:Node-2(节点二),端口:9201,9301

10.10.20.28:Node-3(节点三),端口:9202,9302

4. ElasticSearch 集群配置

  1. 解压安装包:

    cd /usr/local/cluster
    tar -xvf elasticsearch-7.10.2-linux-x86_64.tar.gz

    将安装包解压至 /usr/local/cluster 目录。

  2. 批改集群配置文件:

    vi /usr/local/cluster/elasticsearch-7.10.2-node1/config/elasticsearch.yml 

    10.10.20.28, 第一台节点配置内容:

    # 集群名称
    cluster.name: my-application
    #节点名称
    node.name: node-1
    # 绑定 IP 地址
    network.host: 10.10.20.28
    # 指定服务拜访端口
    http.port: 9200
    # 指定 API 端户端调用端口
    transport.tcp.port: 9300
    #集群通讯地址
    discovery.seed_hosts: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]
    #集群初始化可能参选的节点信息
    cluster.initial_master_nodes: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]
    #开启跨域拜访反对,默认为 false
    http.cors.enabled: true
    ## 跨域拜访容许的域名, 容许所有域名
    http.cors.allow-origin: "*"
    

    批改目录权限:

    chown -R elsearch:elsearch /usr/local/cluster/elasticsearch-7.10.2-node1
  3. 复制 ElasticSearch 装置目录:

    复制其余两个节点:

    cd /usr/local/cluster
    cp -r elasticsearch-7.10.2-node1 elasticsearch-7.10.2-node2
    cp -r elasticsearch-7.10.2-node1 elasticsearch-7.10.2-node3
  4. 批改其余节点的配置:

    10.10.20.28 第二台节点配置内容:

    # 集群名称
    cluster.name: my-application
    #节点名称
    node.name: node-2
    # 绑定 IP 地址
    network.host: 10.10.20.28
    # 指定服务拜访端口
    http.port: 9201
    # 指定 API 端户端调用端口
    transport.tcp.port: 9301
    #集群通讯地址
    discovery.seed_hosts: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]
    #集群初始化可能参选的节点信息
    cluster.initial_master_nodes: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]
    #开启跨域拜访反对,默认为 false
    http.cors.enabled: true
    ## 跨域拜访容许的域名, 容许所有域名
    http.cors.allow-origin: "*"
    

    10.10.20.28 第三台节点配置内容:

    # 集群名称
    cluster.name: my-application
    #节点名称
    node.name: node-3
    # 绑定 IP 地址
    network.host: 10.10.20.28
    # 指定服务拜访端口
    http.port: 9202
    # 指定 API 端户端调用端口
    transport.tcp.port: 9302
    #集群通讯地址
    discovery.seed_hosts: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]
    #集群初始化可能参选的节点信息
    cluster.initial_master_nodes: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]
    #开启跨域拜访反对,默认为 false
    http.cors.enabled: true
    ## 跨域拜访容许的域名, 容许所有域名
    http.cors.allow-origin: "*"
    
  5. 启动集群节点

    先切换 elsearch 用户,在三台节点顺次启动服务:

    su elsearch
    /usr/local/cluster/elasticsearch-7.10.2-node1/bin/elasticsearch -d
    /usr/local/cluster/elasticsearch-7.10.2-node2/bin/elasticsearch -d
    /usr/local/cluster/elasticsearch-7.10.2-node3/bin/elasticsearch -d

    留神:如果启动呈现谬误,将各节点的 data 目录清空,再重启服务。

  6. 集群状态查看

    集群装置与启动胜利之后,执行申请:http://10.10.20.28:9200/_cat/nodes?pretty

    能够看到三个节点信息,三个节点会自行选举出主节点(ES 的是基于 Bully 选举算法做的改良实现):

5. ElasticSearch 集群分片测试

批改 kibana 的配置文件,指向创立的集群节点:

elasticsearch.hosts: ["http://10.10.20.28:9200","http://10.10.20.28:9201","http://10.10.20.28:9202"]

重启 kibana 服务,进入控制台:

http://10.10.20.28:5601/app/home#/

再次创立索引(正本数量范畴内):

PUT /orders
{
  "settings":{
      "index":{
        "number_of_shards": 2, 
        "number_of_replicas": 2
        }
   }
}

能够看到,这次后果是失常:

集群并非能够随便减少正本数量,创立索引(超出正本数量范畴):

PUT /orders
{
  "settings":{
      "index":{
        "number_of_shards": 2, 
        "number_of_replicas": 5
        }
      }
}

能够看到呈现了 yellow 正告谬误:

本文由 mirson 创作分享,感激大家的反对,心愿对大家有所播种!
入群申请,请加 WX 号:woodblock99

正文完
 0