Elasticsearch如何是如何实现分布式增删改查，一文搞懂

灰太狼 2022-12-29 15:30 106阅读 0赞

**分布式文档存储**

*  路由文档到分片
 *  主分片和复制分片如何交互
 *  新建、索引和删除文档
 *  检索文档
 *  局部更新文档
 *  多文档模式
 *  福利

## 路由文档到分片 ##

当你索引一个文档，它被存储在单独一个主分片上。Elasticsearch是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片1还是分片2上的呢？进程不能是随机的，因为我们将来要检索文档。事实上，它根据一个简单的算法决定：

shard = hash(routing) % number_of_primary_shards

routing 值是一个任意字符串，它默认是 \_id 但也可以自定义。这个 routing 字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是 0 到 number\_of\_primary\_shards - 1 ，这个数字就是特定文档所在的分片。  
这也解释了为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。

所有的文档API（ get 、 index 、 delete 、 bulk 、 update 、 mget ）都接收一个 routing 参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档——例如属于同一个人的文档——被保存在同一分片上。

## 主分片和复制分片如何交互 ##

为了阐述意图，我们假设有三个节点的集群。它包含一个叫做 bblogs 的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会放在同一个节点上，所以我们的集群是这样的：  
![在这里插入图片描述][20201223160425136.png]  
我们能够发送请求给集群中任意一个节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。下面的例子中，我们将发送所有请求给 Node 1 ，这个节点我们将会称之为请求节点(requesting node)。

> 提示： 当我们发送请求，最好的做法是循环通过所有节点请求，这样可以平衡负载。

## 新建、索引和删除文档 ##

新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70]  
下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：

1.  客户端给 Node 1 发送新建、索引或删除请求。
2.  节点使用文档的 \_id 确定文档属于分片 0 。它转发请求到 Node 3 ，分片 0 位于这个节点上。
3.  Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和 Node 2 的复制节点上。当所有的复制节点报告成功， Node 3 报告成功到请求的节点，请求的节点再报告给客户端。

客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。  
有很多可选的请求参数允许你更改这一过程。你可能想牺牲一些安全来提高性能。这一选项很少使用因为Elasticsearch已经足够快，不过为了内容的完整我们将做一些阐述。

**replication**  
复制默认的值是 sync 。这将导致主分片得到复制分片的成功响应后才返回。  
如果你设置 replication 为 async ，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。

上面的这个选项不建议使用。默认的 sync 复制允许Elasticsearch强制反馈传输。 async 复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。

**consistency**  
默认主分片在尝试写入时需要规定数量(quorum)或过半的分片（可以是主节点或复制节点）可用。这是防止数据被写入到错的网络分区。规定的数量计算公式如下：

int( (primary + number_of_replicas) / 2 ) + 1

consistency 允许的值为 one （只有一个主分片）， all （所有主分片和复制分片）或者默认的 quorum 或过半分片。

注意 number\_of\_replicas 是在索引中的的设置，用来定义复制分片的数量，而不是现在活动的复制节点的数量。如果你定义了索引有3个复制节点，那规定数量是：

int( (primary + 3 replicas) / 2 ) + 1 = 3

但如果你只有2个节点，那你的活动分片不够规定数量，也就不能索引或删除任何文档。

**timeout**  
当分片副本不足时会怎样？Elasticsearch会等待更多的分片出现。默认等待一分钟。如果需要，你可以设置 timeout 参数让它终止的更早： 100 表示100毫秒， 30s 表示30秒。

> 注意： 新索引默认有 1 个复制分片，这意味着为了满足 quorum  
> 的要求需要两个活动的分片。当然，这个默认设置将阻止我们在单一节点集群中进行操作。为了避开这个问题，规定数量只有在  
> number\_of\_replicas 大于一时才生效。

## 检索文档 ##

文档能够从主分片或任意一个复制分片被检索。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 1]  
下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤：

1.  客户端给 Node 1 发送get请求。
2.  节点使用文档的 \_id 确定文档属于分片 0 。分片 0 对应的复制分片在三个节点上都有。此时，它转发请求到 Node 2 。
3.  Node 2 返回endangered给 Node 1 然后返回给客户端。

对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。

可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。

## 局部更新文档 ##

update API 结合了之前提到的读和写的模式。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 2]  
下面我们罗列执行局部更新必要的顺序步骤：

1.  客户端给 Node 1 发送更新请求。
2.  它转发请求到主分片所在节点 Node 3 。
3.  Node 3 从主分片检索出文档，修改 \_source 字段的JSON，然后在主分片上重建索引。如果有其他进程修改了文档，它以retry\_on\_conflict 设置的次数重复步骤3，都未成功则放弃。
4.  如果 Node 3 成功更新文档，它同时转发文档的新版本到 Node 1 和 Node 2 上的复制节点以重建索引。当所有复制节点报告成功， Node 3 返回成功给请求节点，然后返回给客户端。

> 基于文档的复制  
> 当主分片转发更改给复制分片时，并不是转发更新请求，而是转发整个文档的新版本。记住这些修改转发到复制节点是异步的，它们并不能保证到达的顺序与发送相同。如果Elasticsearch转发的仅仅是修改请求，修改的顺序可能是错误的，那得到的就是个损坏的文档。

## 多文档模式 ##

mget 和 bulk API与单独的文档类似。差别是请求节点知道每个文档所在的分片。它把多文档请求拆成每个分片的对文档请求，然后转发每个参与的节点。  
一旦接收到每个节点的应答，然后整理这些响应组合为一个单独的响应，最后返回给客户端。  
下面我们将罗列通过一个 mget 请求检索多个文档的顺序步骤：

1.  客户端向 Node 1 发送 mget 请求。
2.  Node 1 为每个分片构建一个多条数据检索请求，然后转发到这些请求所需的主分片或复制分片上。当所有回复被接收， Node 1 构建响应并返回给客户端。routing 参数可以被 docs 中的每个文档设置。

下面我们将罗列使用一个 bulk 执行多个 create 、 index 、 delete 和 update 请求的顺序步骤：  
3. 客户端向 Node 1 发送 bulk 请求。  
4. Node 1 为每个分片构建批量请求，然后转发到这些请求所需的主分片上。  
5. 主分片一个接一个的按序执行操作。当一个操作执行完，主分片转发新文档（或者删除部分）给对应的复制节点，然后执行下一个操作。复制节点为报告所有操作完成，节点报告给请求节点，请求节点整理响应并返回给客户端。

bulk API还可以在最上层使用 replication 和 consistency 参数， routing 参数则在每个请求的元数据中使用。

## 为什么是奇怪的格式？ ##

当我们在《批量》一章中学习了批量请求后，你可能会问：“为什么 bulk API需要带换行符的奇怪格式，而不是像 mget API一样使用JSON数组？”

为了回答这个问题，我们需要简单的介绍一下背景：  
批量中每个引用的文档属于不同的主分片，每个分片可能被分布于集群中的某个节点上。这意味着批量中的每个操作(action)需要被转发到对应的分片和节点上。

如果每个单独的请求被包装到JSON数组中，那意味着我们需要：

*  解析JSON为数组（包括文档数据，可能非常大）
 *  检查每个请求决定应该到哪个分片上
 *  为每个分片创建一个请求的数组
 *  序列化这些数组为内部传输格式
 *  发送请求到每个分片

这可行，但需要大量的RAM来承载本质上相同的数据，还要创建更多的数据结构使得JVM花更多的时间执行垃圾回收。

取而代之的，Elasticsearch则是从网络缓冲区中一行一行的直接读取数据。它使用换行符识别和解析action/metadata行，以决定哪些分片来处理这个请求。

这些行请求直接转发到对应的分片上。这些没有冗余复制，没有多余的数据结构。整个请求过程使用最小的内存在进行。

## 粉丝福利 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 3]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 4]

微信搜一搜「 码上代码」回复【面试资料】，【技术书籍】有我准备的一线大厂面试资料和简历模板和java必看技术书籍

大家好，感谢各位人才  
能看到这里的都是您已是佼佼者  
我会持续为大家做技术分享  
预知下篇如何  
请点赞、收藏和评论，我们下期见！

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

[20201223160425136.png]: /images/20221120/dac3aac031b946d0b078d85ec1375426.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70]: /images/20221120/27e7de897962488694443a37cfb9d64a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 1]: /images/20221120/54b2530ff83a448a9eeeb26916f9445e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 2]: /images/20221120/6805c2c05c3e4d55afbdb684cffa80aa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 3]: /images/20221120/0211a33101c84d2d9fe81a8b976aacc6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 4]: /images/20221120/fe2bae958b074783a3bcfbc3e6e932eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70 5]: /images/20221120/acadc4bcec494b56a81a7eda683e7bb8.png