跟我学elasticsearch项目中应用

一、需要掌握的技能

1,安装

 https://www.cnblogs.com/codehello/articles/8136260.html

2，如何整合到项目中

https://www.cnblogs.com/codehello/articles/16382680.html

3，如何实现增删改查

1）查询全部数据

get http://localhost:9200/_search

{ 
    "query":{
         "match_all":{}
          }
}

 

4，如何用分词查询实现搜索优化

 1)Kibana：针对es的ES的开源分析可视化工具，与存储在ES的数据进行交互

kibana安装和应用 ：

https://www.cnblogs.com/codehello/articles/16396288.html

 2)由于es内置分词器太少，无法满足日常业务需要，推荐一款常用分词器 ik分词器

 https://www.cnblogs.com/codehello/articles/16400712.html

 5,集群优化

 1)集群配置

　　准备3台服务器，分别装上es,修改对应配置文件elasticsearch.yml

　　

cluster.name: wtyy-es
#三个节点分别为node-1、node-2、node-3
node.name: node-1
path.data: D:\ES\elasticsearch-7.6.1\data
path.logs:  D:\ES\elasticsearch-7.6.1\logs
bootstrap.memory_lock: true
http.port: 9200
network.host: 0.0.0.0
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: discovery.zen.ping.unicast.hosts: ["xxx.xx.xxx.175", "xxx.xx.xxx.151","xxx.xx.xxx.126"]

参数解析：

（1）cluster.name
       集群名字，三台集群的集群名字都必须一致

（2）node.name
        节点名字，三台ES节点名字都必须不一样

（3）discovery.zen.minimum_master_nodes:2
        表示集群最少的master数，如果集群的最少master数据少于指定的数，将无法启动，官方推荐node master数设置为集群数/2+1，我这里三台ES服务器，配置最少需要两台master，整个集群才可正常运行。

（4）node.master该节点是否有资格选举为master，如果上面设了两个mater_node 2，也就是最少两个master节点，则集群中必须有两台es服务器的配置为node.master: true的配置，配置了2个节点的话，如果主服务器宕机，整个集群会不可用，所以三台服务器，需要配置3个node.masdter为true,这样三个master，宕了一个主节点的话，他又会选举新的master，还有两个节点可以用，只要配了node master为true的ES服务器数正在运行的数量不少于master_node的配置数，则整个集群继续可用，我这里则配置三台es node.master都为true，也就是三个master，master服务器主要管理集群状态，负责元数据处理，比如索引增加删除分片分配等，数据存储和查询都不会走主节点，压力较小，jvm内存可分配较低一点

（5）node.data
      存储索引数据，三台都设为true即可

（6）bootstrap.memory_lock: true
      锁住物理内存，不使用swap内存，有swap内存的可以开启此项

（7）discovery.zen.ping_timeout: 3000s
       自动发现拼其他节点超时时间

（8）discovery.zen.ping.unicast.hosts: ["xxx.xx.x.175:9300","xxx.xx.x.6:9300","xxx.xx.x.22:9300"]
        设置集群的初始节点列表，集群互通端口为9300
2)重启es即可

3)发现机制

   ES 内部是如何通过一个相同的设置 cluster.name 就能将不同的节点连接到同一个集群的？答案是 Zen Discovery。

   Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。

    当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 Master 节点，并加入集群。

这意味着单播列表不需要包含集群中的所有节点， 它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。

  节点启动后先 Ping ，如果 discovery.zen.ping.unicast.hosts 有设置，则 Ping 设置中的 Host ，否则尝试 ping localhost 的几个端口。

Elasticsearch 支持同一个主机启动多个节点，Ping 的 Response 会包含该节点的基本信息以及该节点认为的 Master 节点。

选举开始，先从各节点认为的 Master 中选，规则很简单，按照 ID 的字典序排序，取第一个。如果各节点都没有认为的 Master ，则从所有节点中选择，规则同上。

这里有个限制条件就是 discovery.zen.minimum_master_nodes ，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举。

最后选举结果是肯定能选举出一个 Master ，如果只有一个 Local 节点那就选出的是自己。

如果当前节点是 Master ，则开始等待节点数达到 discovery.zen.minimum_master_nodes，然后提供服务。

如果当前节点不是 Master ，则尝试加入 Master 。Elasticsearch 将以上服务发现以及选主的流程叫做 Zen Discovery 。

 

只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的。

但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题。

大多数解决方案就是设置一个 Quorum 值，要求可用节点必须大于 Quorum（一般是超过半数节点），才能对外提供服务。

而 Elasticsearch 中，这个 Quorum 的配置就是 discovery.zen.minimum_master_nodes 。

4）节点的角色

每个节点既可以是候选主节点也可以是数据节点，通过在配置文件 ../config/elasticsearch.yml 中设置即可，默认都为 true。

node.master: true  //是否候选主节点  
node.data: true    //是否数据节点

数据节点负责数据的存储和相关的操作，例如对数据进行增、删、改、查和聚合等操作，所以数据节点（Data 节点）对机器配置要求比较高，对 CPU、内存和 I/O 的消耗很大。

通常随着集群的扩大，需要增加更多的数据节点来提高性能和可用性。

候选主节点可以被选举为主节点（Master 节点），集群中只有候选主节点才有选举权和被选举权，其他节点不参与选举的工作。

    主节点负责创建索引、删除索引、跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点、追踪集群中节点的状态等，稳定的主节点对集群的健康是非常重要的。

一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对 CPU、内存核 I/O 消耗都很大。

所以如果某个节点既是数据节点又是主节点，那么可能会对主节点产生影响从而对整个集群的状态产生影响。

因此为了提高集群的健康性，我们应该对 Elasticsearch 集群中的节点做好角色上的划分和隔离。可以使用几个配置较低的机器群作为候选主节点群。

主节点和其他节点之间通过 Ping 的方式互检查，主节点负责 Ping 所有其他节点，判断是否有节点已经挂掉。其他节点也通过 Ping 的方式判断主节点是否处于可用状态。

虽然对节点做了角色区分，但是用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而不需要主节点转发。

这种节点可称之为协调节点，协调节点是不需要指定和配置的，集群中的任何节点都可以充当协调节点的角色。

5）脑裂现象

     同时如果由于网络或其他原因导致集群中选举出多个 Master 节点，使得数据更新时出现不一致，这种现象称之为脑裂，即集群中不同的节点对于 Master 的选择出现了分歧，出现了多个 Master 竞争。

“脑裂”问题可能有以下几个原因造成：

  • 网络问题： 集群间的网络延迟导致一些节点访问不到 Master，认为 Master 挂掉了从而选举出新的 Master，并对 Master 上的分片和副本标红，分配新的主分片。
  • 节点负载： 主节点的角色既为 Master 又为 Data，访问量较大时可能会导致 ES 停止响应（假死状态）造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
  • 内存回收： 主节点的角色既为 Master 又为 Data，当 Data 节点上的 ES 进程占用的内存较大，引发 JVM 的大规模内存回收，造成 ES 进程失去响应。

避免脑裂现象的发生优化方案：

  • 适当调大响应时间，减少误判。 通过参数 discovery.zen.ping_timeout 设置节点状态的响应时间，默认为 3s，可以适当调大。

如果 Master 在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如 6s，discovery.zen.ping_timeout:6），可适当减少误判。

  • 选举触发。 我们需要在候选集群中的节点的配置文件中设置参数 discovery.zen.munimum_master_nodes 的值。

这个参数表示在选举主节点时需要参与选举的候选主节点的节点数，默认值是 1，官方建议取值(master_eligibel_nodes2)+1，其中 master_eligibel_nodes 为候选主节点的个数。

这样做既能防止脑裂现象的发生，也能最大限度地提升集群的高可用性，因为只要不少于 discovery.zen.munimum_master_nodes 个候选节点存活，选举工作就能正常进行。

当小于这个值的时候，无法触发选举行为，集群无法使用，不会造成分片混乱的情况。

  • 角色分离。 即是上面我们提到的候选主节点和数据节点进行角色分离，这样可以减轻主节点的负担，防止主节点的假死状态发生，减少对主节点“已死”的误判。

6,常见项目中异常处理

 

posted on 2022-06-22 15:24  让代码飞  阅读(115)  评论(0)  编辑  收藏  举报

导航

一款免费在线思维导图工具推荐：https://www.processon.com/i/593e9a29e4b0898669edaf7f?full_name=python