比方说我这里有一张数据库表，那我们知道对于数据库它一般情况下都会基于i d去创建索引，然后形成一个b+树，当用户根据id（索引字段）进行检索的速度非常快，但是当用户进行局部内容检索，模糊查询的时候，索引将会失效，这时候数据库只能采用逐条扫描的方式来判断每一行数据中是否包含用户搜素的内容，包含的话就存入查询结果集，当数据库中的存储了海量数据的时候，逐条检索的效率非常低，性能非常差，这就是正向索引：

搜索'手机"：

select *from tb_goods where title like'%手机%'

倒排索引：

①、倒排索引，ES在存储文档时，它首先会先对文档的内容按照词义分成一个一个不同词条，对词条创建索引，并记录词条所在文档的id；

②、当我们去做搜素、查询的时候会涉及到两次查询：第一次查询是先根据用户输入的内容按照词义分成一个个词条，然后去词条列表中进行搜素，找到对应的文档id，由于所有的词条都建立了索引，所以基于词条来查询文档id的速度是非常快的；第二次查询是拿着文档id找到具体文档，再存入查询结果集，返回给前端。

③、虽然经历了两次搜查询，但每一次都是根据索引进行查询，所以总的查询效率是比传统的正向索引：逐条扫描要高很多，时间复杂度是O(1)，极大的提高了检索效率。

正向索引是最传统的，根据id索引的方式。但根据词条查询时，必须先逐条扫描获取每个文档，然后判断文档中是否包含所需要的词条，是根据文档找词条的过程。
而倒排索引则相反，是先找到用户要搜索的词条，根据词条得到保护词条的文档的id，然后根据id获取文档。是根据词条找文档的过程。

3、Mysql和Elasticsearch对比

Mysql和Elasticsearch擅长的事情是不一样的。MySQL支持事务，它更擅长的是事物类型的操作：因为事物里边有ACID的原则，所以它是可以确保数据的ACID 安全性、一致性

ES没有事物的概念，所以它无法保证数据的ACID，它更擅长的是数据的搜索、分析和运算。

所以它们两个是各司其职的。如果你的业务对数据的安全性、一致性要求很高，你就应该使用mysql去做数据存储。如果你的业务涉及到了海量数据的搜素、面对比较复杂的搜素业务场景，就是用ES。

4、ik_smart和 ik_max_word区别、优缺点

ik_smart是粗力度切分:它会从字数最多开始往字数越来越少去看，首先看五个字是不是一个词，如果不是，我再看四个，如果还不是，再看三个，如果发现程序员这三个字刚好是一个词，我就不再继续往下看两个字是不是词。

ik_max_word分出来有三个词：程序、程序员、员，那用户搜索的时候，我无论输入程序、程序员还是员，这三个词中的任意一个都能搜这个文档，但是如果你采用的是ik_smart，你分出来只有程序员这一个词，那搜到的概率就会比较低。

ik_smart优缺点：分的词少了，占用的内存空间就小一些，将来内存里可以缓存更多的数据。但是某一条文档被搜到的概率就会比较低

ik_max_word优缺点：占用内存空间会更多，某一条文档被搜索到的概率更大

5、ElasticSearch介绍/理解

ElasticSearch是一个强大的分布式搜索引擎。它有个核心技术叫做倒排索引，可以帮助我们从海量数据中快速的找到所需要的内容，实现海量数据的搜素、分析和运算，响应时间通常很短。（聚合）
ElasticSearch支持跨语言，它对外暴露的是Restful接口，不同的编程语言都可以通过HTTP请求与ElasticSearch进行交互
ElasticSearch这个索引擎是一个分布式的搜素引擎，分布式的设计（架构）使得Elasticsearch能够支持水平的扩展，可以通过添加更多的节点，从而处理海量的数据和请求负载，并且分布式架构也使得Elasticsearch具有高可靠性，即使在部分节点出现故障或网络问题的情况下也能保持稳定运行。
ElasticSearch的底层实现是基于Lucene技术。Lucene是一个java语言的搜索引擎，Lucene是Apache公司的一个顶级项目，而ElasticSearch，正是基于这个Lucene去做的二次开发
ElasticSearch常用在海量数据搜索、日志数据分析、实时监控等领域。
ElasticSearch有故障转移功能：集群的master主节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。
- 如果是集群的主节点出现宕机，我们的候选节点可以重新选举一个主节点。
- 集群的master主节点会检测集群中的节点状态，当我们的数据节点出现宕机的时候，master节点就可以监控到这种状态。然后master就会将宕机节点上的分片数据转移到正常节点上，从而确保数据安全。（确保每一个分片至少都要有一个甚至多个副本）

6、ELK

Elasticsearch结合kibana、Logstash、Beats，也就是elastic stack（ELK）。被广泛应用在海量搜索、日志数据分析、实时监控等领域：

elasticsearch是elastic stack的核心，负责数据的搜素、分析和运算
Logstash、Beats, 这两个组件主要是来负责数据抓取的。比如说你的日志数据，就可以由他来去抓取。
kibana是一个数据可视化的组件。将来搜索出来的数据要展示，可以用它来去展示，形成报表

例如百度、京东在展示结果的时候，都有自己的网站，所以这种可视化不一定非得用这个kibana去做。你完全可以自己去实现；数据抓取也一样，我们完全可以自己写java代码，自己从数据库中获取数据。然后往ElasticSearch里去写

所以kibana、Logstash、Beats，它们都是可替换的一个组件，官方提供给你，你想用就用，你不用也没关系，但是不可替代的就是ElasticSearch。

7、故障转移

集群的master主节点会检测集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移，保证了ES的高可用性。

如果是集群的主节点出现宕机，我们的候选节点可以重新选举一个主节点。
集群的master主节点会检测集群中的节点状态，当我们的数据节点出现宕机的时候，master节点就可以监控到这种状态。然后master就会将宕机节点上的分片数据转移到正常节点上，从而确保数据安全。（确保每一个分片至少都要有一个甚至多个副本）如果故障节点重新上线，Elasticsearch 会重新分配为其分配分片。

8、shard 分片、replica 副本[ˈreplɪkə]

shard 分片：单台机器无法存储大量数据，es将索引库从逻辑上拆分为N个分片(shard)，存储到多个节点/多台服务器上。有了shard分片意味着ES的存储能力是多个节点/多个服务器的存储能力总和，理论上服务器越多，就可以存储更多数据。另外，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。
replica 副本：当节点（服务器）发生故障或宕机时，原始分片可能会丢失，为了确保数据不丢失，我们创建分片的副本。这些副本可以在分片故障时提供备用服务，每个分片的副本都存储在不同的服务器上，以确保在某台服务器宕机时，数据仍然可用，从而避免数据故障的发生。

索引在创建时会指定分片和副本的数量。如果在创建索引时未指定，那么Elasticsearch会默认为该索引创建5个分片，并为每个分片创建1个副本，以提供数据的高可用性和容错性。

shard 分片数量设置后不能修改，replica 副本数量可随时修改数量；

使用PUT请求来创建一个新的索引，同时指定索引的名称、分片数和副本数等配置参：


PUT /my_index
{
  "settings": {
    "number_of_shards": 3,//分片数量
    "number_of_replicas": 1 //副本数量，默认为1
  },
   "mappings":{
    "properties": {
      "info":{
        "type":"text",
        "analyzer": "ik_smart"
      },
      "email":{
        "type":"keyword",
        "index": false
      },
      "name":{
        "type":"object",
        "properties": {
          "firstName":{
            "type":"keyword"
          },
          "lastName":{
            "type":"keyword"
          }
        }
      }
    }
  }
}

9、ES集群当中不同节点它的角色和职责的划分.

eligible：有资格的英[ˈelɪdʒəbl]

①、master eligible 候选主节点：

候选主节点可以被选举为主节点（master节点），集群中只有候选主节点才有选举权和被选举权，其他节点不参与选举的工作。
主节点负责集群的整体管理，包括新节点的加入和移除、索引的创建和删除，检测集群中其他节点的状态，并决定将索引的哪些分片分配到哪些数据节点上，以保证集群的负载均衡和高可用性。
主节点和其他节点之间通过Ping的方式互检查，主节点负责Ping所有其他节点，判断是否有节点已经挂掉。其他节点也通过Ping的方式判断主节点是否处于可用状态。

②、data数据节点：

数据节点负责对数据进行增、删、改、查和聚合等操作，所以数据节点（data节点）对机器配置要求比较高，对CPU、内存和I/O的消耗很大。通常随着集群的扩大，需要增加更多的数据节点来提高性能和可用性。

③、协调节点：

用户的请求到达了协调节点，协调节点会把这个请求路由到真正做处理的数据节点上去，那数据节点处理完请求后会把结果返回给协调节点，协调节点再收集结果并返回给用户。
协调节点是不需要指定和配置的，集群中的任何节点都可以充当协调节点的角色，所以用户的请求可以发往集群中的任何一个节点，并由该节点负责分发请求、收集结果等操作
可以控制一个节点，只干协调，不干别的，把这三个参数都调成false，那么它就变成了一个纯粹的协调节点了：

④、ingest 节点：

ingest 做数据预处理，例如对数据进行过滤、转换等操作

GPT：

Elasticsearch的ETL利器——Ingest节点_elasticsearch ingest-CSDN博客

        默认情况下ES集群中的节点同时具备这四种角色，身兼数职。但是我们在实际开发当中，不能让一个节点身兼数职，因为职责不同，它其实对于硬件的需求是不一样的。并且，一个节点既是候选主节点又是数据节点的话，可能会造成脑裂问题。

        一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对CPU、内存和I/O消耗都很大，如果某个节点既是数据节点又是主节点，该节点在数据处理的过程中可能会大量的占用cpu和内存，从而可能使得主节点没办法去监管整个集群了，可能会导致主节点无法连接或无法正常工作，集群可能会处于无法响应的状态，这可能会导致系统故障或性能下降。

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

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

10、当一个节点发生故障而导致数据分片丢失时 gpt

以下几个步骤可以帮助恢复数据并保持集群的稳定运行：

分片复制（Replicas）：Elasticsearch 通过分片的副本来增加数据的可靠性。每个主分片可以配置一个或多个副本分片。当主分片所在的节点发生故障时，其中一个副本分片会被提升为新的主分片。因此，确保为所有重要的索引配置了足够的副本分片是预防数据丢失的重要策略。
节点恢复：如果发生节点故障，尽快恢复或替换故障节点。Elasticsearch 会尝试重新分配该节点上的副本分片到集群中的其他节点上。如果故障节点重新上线，Elasticsearch 会重新同步其上的分片数据。
分片分配策略：可以通过Elasticsearch 的分片分配设置，调整分片的分配方式，如设置 cluster.routing.allocation.enable 控制分片分配的启用或禁用，或是使用 cluster.routing.rebalance.enable 来控制分片重平衡的行为。这些设置可以帮助在节点恢复或新节点加入时优化数据的重新分配。
快照和备份：定期对Elasticsearch 数据进行快照备份是非常重要的。使用Elasticsearch 的快照和恢复功能，可以将数据备份到如文件系统、HDFS或云存储等安全的位置。在发生不可恢复的硬件故障或数据丢失时，可以从快照中恢复数据。
监控和警报：使用Elasticsearch 的监控工具，如Elasticsearch自带的X-Pack监控功能，或其他外部工具，来监控集群的健康和性能。配置适当的警报，当发现节点故障或资源瓶颈时可以及时响应。
集群健康检查：定期检查集群的健康状态，使用如 GET _cluster/health 或 GET _cat/indices?v&health=yellow,red 等API来识别和解决潜在的问题。

通过上述步骤，可以有效地应对Elasticsearch节点故障引起的分片丢失问题，并确保数据的安全和服务的持续性。

11、脑裂问题及解决

脑裂现象：

脑裂通常是由于主节点失去响应，导致其他部分节点认为主节点已经失效，从而选举出了新的主节点，导致一个ES集群中出现了两个Master主节点。

脑裂主要是是由于网络原因，导致主节点失去响应，其他部分节点认为主节点已经失效，从而选举出了新的主节点，导致一个ES集群中出现了两个Master主节点。

脑裂带来的问题：

数据不一致：由于ES集群分裂成了多个相互独立的子系统，当用户请求对文档进行增删改的时候，一部分请求被主节点A所管理的节点处理，一部分请求被主节点B所管理的节点处理，那么一旦网络恢复，当用户来访问的时候，就会出现两边数据不一致的情况

脑裂的可能原因：

网络问题：集群间的网络延迟导致一些节点访问不到 master，认为 master 挂掉了从而选举出新的主节点（并对 master 上的分片和副本标红，分配新的主分片）
主节点负载过大：主节点的角色既是数据节点又是主节点，该节点在数据处理的过程中可能会大量的占用cpu和内存，主节点负载过大，从而可能使得该主节点没办法去监管整个集群了，可能会导致主节点无法连接或无法正常工作，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。

脑裂问题解决方案：

        1. 其他节点通过Ping的方式判断主节点是否处于可用状态，如果在指定的超时时间内未收到响应，则认为主节点不可用/已经挂掉了，默认为3s，所以我们可以适当的调大响应时间，减少由于集群间的网络延迟造成的误判。通过参数 discovery.zen.ping_timeout：6 设置节点状态的响应时间。

        2. 选举触发条件：我们需要在候选集群中的节点的配置文件中设置参数 discovery.zen.munimum_master_nodes的值，
这个参数表示在选举主节点时需要参与选举的候选主节点的节点数，默认值是1，官方建议
取值 (master_eligibel_nodes/2)+1，其中 master_eligibel_nodes为候选主节点的个数，ES7.X后已经成为了默认设置了，所以不用担心脑裂问题。

        当有节点认为主节点挂了，会触发选举过程，候选主节点之间会进行投票，当某个候选主节点获得的投票数大于（候选主节点数+1）/2时（票数超过一半的候选主节点总数时），并且该节点自己也选举自己为主节点，那这个节点才能成为新的主节点master，这样就能避免一个ES集群中出现了两个Master主节点。我们通常设置候选主节点数为奇数

        3. 角色分离：对候选主节点和数据节点进行角色分离，让主节点专注于管理整个集群，不做数据处理，这样可以减轻主节点的负担，防止主节点的假死状态发生，减少对主节点“已死”的误判。

         主节点配置为: node.master: true         node.data: false
从节点配置为: node.master: false node.data: true

默认情况下ES的节点同时具备这四种角色，身兼数职：

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

12、Elasticsearch 的 master 选举流程？

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

当选举发生时，每个候选主节点会把自己所知道的所有正常状态的候选主节点按照nodeId节点ID进行排序，然后投票给排位在第一个的（第 0 位）节点，当某个候选主节点获得的投票数大于（候选主节点数+1）/2时（票数超过一半的候选主节点总数时），并且该节点自己也选举自己为主节点，那这个节点才能成为新的主节点master，这样也能防止脑裂，避免一个ES集群中出现了两个Master主节点。我们通常设置候选主节点数为奇数，投票数一样，id小的值就成为主节点

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/weixin_40725706/article/detail/518944?site