ElasticSearch - 挖掘剖析ES分布式的原理

小鱼儿 2022-10-29 02:00 170阅读 0赞

### 文章目录 ###

*  ElasticSearch - 挖掘剖析ES的原理
 *   *  1.ES分布式工作原理
     *   *  1.1 节点交互原理
         *  1.2 写入文档
         *  1.3 读取文档
     *  2.ES文档路由原理
     *   *  2.1 路由算法
         *  2.2 探究文档所在分片
     *  3.ES乐观锁机制
     *   *  3.1 锁的分类
         *  3.2 乐观锁(版本号)
     *  4.倒排索引介绍和剖析

# ElasticSearch - 挖掘剖析ES的原理 #

## 1.ES分布式工作原理 ##

>  ES是分布式的，但是对于我们开发者而言并未过多的参与其中。我们只需修改好配置启动对应数量的节点，给它们分配相同的`cluster.name`让它们归属于同⼀个集群即可。创建索引的时候只需指定索引主分⽚数和副分⽚数 ，其他的基本完全交给了ES内部去实现了。  
>    
>  这与数据库以及同源的solr实现分布式还是有一定区别的。数据库要做集群分布式，例如分库分表就需要我们自己指定路由规则和数据同步策略，包括读写分离，主从同步等；而solr的分布式也需依赖`zookeeper`，但是Elasticsearch则完全屏蔽了这些。  
>    
>  即使Elasticsearch为了使用者方便，天⽣就是分布式并且在设计时屏蔽了分布式的复杂性。但是我们依然需要去弄清它内部的原理，这样才能够在使用ES时如鱼得水。

### 1.1 节点交互原理 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70]

>  大家可以通过官方文档或者各种博客都能了解到，ES和其他中间件例如mysql、redis一样，都有master-slave模式。ES集群也会选举⼀个节点作为master节点，master节点它的职责是维护全局集群状态，在节点加⼊或离开集群的时候重新分配分⽚。  
>    
>  所有⽂档级别的写操作都不会与master节点通信，master节点不需要涉及到⽂档级别的变更和搜索等操作。并且ES分布式和mysql的master-slave模式有所区别，mysql是写在主库然后再同步数据到从库；⽽ES⽂档写操作是分⽚上⽽不是节点上，先写在主分⽚后再同步给副分⽚。由于主分⽚可以分布在不同的节点上，所以当集群只有⼀个master节点的情况下，即使流量的增加它也不会成为瓶颈，就算它挂了后任何节点都有机会成为主节点。  
>    
>  读写可以请求任意节点，节点再通过转发请求到⽬的节点。例如⼀个⽂档的新增，⽂档通过路由算法分配到某个主分⽚，然后找到对应的节点，将数据写⼊到主分⽚上，然后再同步到副分⽚上。

### 1.2 写入文档 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 1]

>  上面我们简单介绍了一个文档新增的过程，这里我们来看一下ES集群具体是如何操作的。
> 
> 1.  客户端向`NODE-1`发送新增文档的请求。
> 2.  节点通过文档路由算法计算出该文档属于主分片`P0`。由于主分片`P0`在`NODE-3`上，所以请求转发到`NODE-3`节点。
> 3.  `NODE-3`将文档写入主分片`P0`上，然后将请求转发到`NODE-1`和`NODE-2`对应的副本分片`R0`上。当所有副本分片告知成功后，`NODE-3`会向`NODE-1`告知成功，然后`NODE-1`向客户端响应成功。

### 1.3 读取文档 ###

>  读取文档就简单很多了，同样以上图部署为例，读取文档主要分为两步。
> 
> 1.  客户端向NODE-1发送读取文档请求。
> 2.  在处理读取请求时，`NODE-1`在每次请求的时候都会通过轮询所有的副本分⽚来达到负载均衡。

## 2.ES文档路由原理 ##

>  当新增⼀个⽂档时，⽂档会被存储到⼀个主分⽚中。ES如何确定⼀个⽂档应该存放到哪个分⽚中呢？这就涉及了ES文档路由的原理。

### 2.1 路由算法 ###

>  ⾸先文档被存放在哪个分片中肯定不会是随机的，否则搜索要获取⽂档时ES就不知道从何处寻找了。实际上，这个过程是根据这个公式决定的：`shard = hash(routing) % number_of_primary_shards`。  
>    
>  这里的`routing`是⼀个可变值，默认是⽂档的`_id` ，也可以设置成⼀个⾃定义的值。 `routing`通过`hash`函数⽣成⼀个哈希值，然后将哈希值再除以`number_of_primary_shards（即主分⽚的数量）`后得到 余数 。这个分布在 0 到 number\_of\_primary\_shards-1 之间的余数，就是我们所寻求的⽂档所在分⽚的位置。  
>    
>  上一篇博客我们在讲集群分片时讲到过，一个索引一旦创建，那么其主分片数量就无法修改。而路由算法就解释了为什么我们要在创建索引的时候就确定好主分⽚的数量并且永远不会改变这个数量：因为如果数量发生变化，那所有之前路由的值都会⽆效，定位不到之前的⽂档了。

### 2.2 探究文档所在分片 ###

>  这里我们先添加一个文档，这里没有什么特殊的地方，唯一一个需要知道的就是我们指定了ID=1。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 2]  
>  这里我们可以通过`nba/_search_shards?routing=1`来查看`routing=1`所在分片的情况。

{ 
        "nodes": { 
            "kYOpZCUvR0-SIEJZVhG7og": { 
                "name": "es-node-2",
                "ephemeral_id": "GRnzd60gTCqhINvp2TIm6w",
                "transport_address": "172.17.0.12:9301",
                "attributes": { 
                    "ml.machine_memory": "1927176192",
                    "ml.max_open_jobs": "20",
                    "xpack.installed": "true",
                    "transform.node": "true"
                }
            },
            "-4jfSBaLS36K6-nXIXBWkw": { 
                "name": "es-node-1",
                "ephemeral_id": "Jo1-PxxVQnmgwqeR5TDC0A",
                "transport_address": "172.17.0.12:9300",
                "attributes": { 
                    "ml.machine_memory": "1927176192",
                    "xpack.installed": "true",
                    "transform.node": "true",
                    "ml.max_open_jobs": "20"
                }
            }
        },
        "indices": { 
            "nba": { }
        },
        "shards": [
            [
                { 
                    "state": "STARTED",
                    "primary": true,
                    "node": "kYOpZCUvR0-SIEJZVhG7og",
                    "relocating_node": null,
                    "shard": 2,
                    "index": "nba",
                    "allocation_id": { 
                        "id": "BLNOGWTWRoKwMmFl0TejNw"
                    }
                },
                { 
                    "state": "STARTED",
                    "primary": false,
                    "node": "-4jfSBaLS36K6-nXIXBWkw",
                    "relocating_node": null,
                    "shard": 2,
                    "index": "nba",
                    "allocation_id": { 
                        "id": "kaswyguPTz2cvsFIA5LN-g"
                    }
                }
            ]
        ]
    }

>  从ES响应来看我们可以得知，`routing=1`的文档存储在`es-node-1`和`es-node-2`。并且`es-node-2`为主分片。

## 3.ES乐观锁机制 ##

### 3.1 锁的分类 ###

>  相比大家对锁其实都比较熟悉了，那么我们来回顾一下我们接触比较锁，主要分为两类。
> 
> 1.  `悲观锁`：顾名思义就是很悲观，每次去拿数据的时候都认为别⼈会修改，所以每次在拿数据的时候都会上锁，这样别⼈想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库⾥边就⽤到了很多这种锁机制，⽐如⾏锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
> 2.  `乐观锁`：顾名思义就是很乐观，每次去拿数据的时候都认为别⼈不会修改，所以不会上锁。但是在更新时会判断⼀下在此期间别⼈有没有去更新这个数据，⽐如可以使⽤版本号等机制。乐观锁适⽤于多读的应⽤类型，这样可以提⾼吞吐量。由于我们ES⼀般业务场景都是写少读多，所以通过乐观锁可以在控制并发的情况下⼜能有效的提⾼系统吞吐量。

### 3.2 乐观锁(版本号) ###

>  这里我们主要介绍一下ES里面采用的锁机制，ES所采用的的锁机制主要是通过版本号来实现的乐观锁。  
>    
>  小伙伴们要是还有印象的话应该记得之前我们在操作文档时，时不时都能看到一个`_version`，这就是ES所维护的版本号了。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 3]  
>  ES中对⽂档的`GET` 和 `DELETE` 请求时，都会返回⼀个 `_version`，当⽂档被修改时版本号递增。  
>    
>  并且所有⽂档的更新或删除 API，都可以接受 version 参数。这允许我们在代码中使⽤乐观的并发控制，这⾥要注意的是版本号要⼤于旧的版本号，并且加上version\_type=external。  
>    
>  例如这里我们去修改文档时，当前文档version=1，然后我们参数又指定了version=1。此时我们的修改是无法成功的，只有当我们传递的version参数大于ES本身维护的version参数时才接受处理，如果大家对乐观锁了解的话就十分容易理解。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 4]

## 4.倒排索引介绍和剖析 ##

>  我们去NBA官网搜索james时可以得到下面五条数据。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 5]  
>  假设我们目前只有这五条球员的数据，那么我们是如何通过`james`查找到名字中带有`james`的球员的呢?

<table> 
 <thead> 
  <tr> 
   <th align="center">文档编号</th> 
   <th align="center">文档内容</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">1</td> 
   <td align="center">James Ennis III</td> 
  </tr> 
  <tr> 
   <td align="center">2</td> 
   <td align="center">James Harden</td> 
  </tr> 
  <tr> 
   <td align="center">3</td> 
   <td align="center">Justin James</td> 
  </tr> 
  <tr> 
   <td align="center">4</td> 
   <td align="center">Lebron James</td> 
  </tr> 
  <tr> 
   <td align="center">5</td> 
   <td align="center">James Johnson</td> 
  </tr> 
 </tbody> 
</table>

>  围绕上面这个问题，假如我们的数据是以上面这份文档的形式存储的，那我们只能通过顺序扫描遍历整个列表才能够得出答案。很显然Mysql都不会这样单纯去维护数据，更何况ES这种专门作为检索的搜索引擎呢。

<table> 
 <thead> 
  <tr> 
   <th align="center">单词序号</th> 
   <th align="center">单词</th> 
   <th align="center">倒排列表</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">1</td> 
   <td align="center">james</td> 
   <td align="center">[1,2,3,4,5]</td> 
  </tr> 
  <tr> 
   <td align="center">2</td> 
   <td align="center">ennis</td> 
   <td align="center">[1]</td> 
  </tr> 
  <tr> 
   <td align="center">3</td> 
   <td align="center">harden</td> 
   <td align="center">[2]</td> 
  </tr> 
  <tr> 
   <td align="center">4</td> 
   <td align="center">justin</td> 
   <td align="center">[3]</td> 
  </tr> 
  <tr> 
   <td align="center">5</td> 
   <td align="center">lebron</td> 
   <td align="center">[4]</td> 
  </tr> 
  <tr> 
   <td align="center">6</td> 
   <td align="center">johnson</td> 
   <td align="center">[5]</td> 
  </tr> 
 </tbody> 
</table>

>  那么假如我们将五个球员名字进行分词小写后，再以每个单词分组维护，维护一份如上的列表。当有关键词检索的时候，将关键词进行小写然后根据上面维护的列表找出关键词所在的文档位置然后全部返回。  
>    
>  而ES做的更加完善，除了将五个球员名字分词小写转换分组，还会统计每个单词所在文档的位置。

<table> 
 <thead> 
  <tr> 
   <th align="center">单词序号</th> 
   <th align="center">单词</th> 
   <th align="center">文档频率</th> 
   <th align="center">倒排列表(DocID;TF;[POS])</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">1</td> 
   <td align="center">james</td> 
   <td align="center">5</td> 
   <td align="center">(1;1;&lt;1&gt;),(2;1;&lt;1&gt;),(3;1;&lt;2&gt;),(4;1;&lt;2&gt;),(5;1;&lt;1&gt;)</td> 
  </tr> 
  <tr> 
   <td align="center">2</td> 
   <td align="center">ennis</td> 
   <td align="center">1</td> 
   <td align="center">(1;1;&lt;2&gt;)</td> 
  </tr> 
  <tr> 
   <td align="center">3</td> 
   <td align="center">harden</td> 
   <td align="center">1</td> 
   <td align="center">(2;1;&lt;2&gt;)</td> 
  </tr> 
  <tr> 
   <td align="center">4</td> 
   <td align="center">justin</td> 
   <td align="center">1</td> 
   <td align="center">(3;1;&lt;2&gt;)</td> 
  </tr> 
  <tr> 
   <td align="center">5</td> 
   <td align="center">lebron</td> 
   <td align="center">1</td> 
   <td align="center">(4;1;&lt;1&gt;)</td> 
  </tr> 
  <tr> 
   <td align="center">6</td> 
   <td align="center">johnson</td> 
   <td align="center">1</td> 
   <td align="center">(5;1;&lt;2&gt;)</td> 
  </tr> 
 </tbody> 
</table>

>  这里我们主要看一下倒排列表中维护信息的含义。
> 
> 1.  DocID：单词出现的文档ID
> 2.  TF：单词在某个文档出现的次数
> 3.  POS：单词在文档中出现的位置  
>      
> 
>  这就是ES独有的倒排索引结果。

--------------------

>  到这里我们对ES就已经有了一个全方位的认识了，并且我们已经掌握了ES的大部分能力的使用，基本大部分的场景我们都能够很快就设计出一套解决方案。不过对于技术我们还是要抱有敬畏之心，还有更多更深次的东西等待着我们去探索。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70]: /images/20221024/6bdb00dbb2a14e698e657cbf8dfca4a5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 1]: /images/20221024/ed6e1ae8665541bf95570a7a96934efe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 2]: /images/20221024/80e6407db27546da878b19ce86c3b19c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 3]: /images/20221024/34e869c0c2dc4ad5984fd4773de6e004.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 4]: /images/20221024/646f4b377d6f41be8e6ff967655f197e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 5]: /images/20221024/65e40163ae1c41f1b8dfc86781aaea25.png