当前位置： 移动技术网 > IT编程>数据库>其他数据库 > ES 17 - (底层原理) Elasticsearch增删改查索引数据的过程

ES 17 - (底层原理) Elasticsearch增删改查索引数据的过程

2019年04月14日  | 移动技术网IT编程  | 我要评论

目录

1 增删改document的流程

1.1 协调节点 - coordinating node

coordinating node(协调节点): 客户端随机选择一个node用来发送操作请求, 这个节点就称为协调节点.

由于每个node都能计算出document的存储位置, 所以由哪个node担任协调节点都是可以的——这对客户端来说是透明的.

1.2 增删改document的流程

① 客户端通过协调节点发送 增删改请求.

② 协调节点对客户端提交的文档进行路由, 然后将相关请求转发到 存储该文档的primary shard上.

③ primary shard处理客户端的请求, 然后将操作后的document同步到其对应的replica shard中.

④ 协调节点监控到primary shard和其对应的replica shard都处理完了该document, (协调节点)就将操作结果响应给客户端.

强调: 增删改操作只能由primary shard处理, replica shard只能处理查询请求.

2 查询document的流程

(1) 流程:

① 客户端通过协调节点发送 查询请求.

② 协调节点对客户端提交的文档进行路由, 明确存储相关文档的primary shard(主分片), 然后使用round-robin算法(随机轮训算法), 将查询请求转发到 该primary shard及这个主分片对应的任意一个replica shard(副本分片) —— 读请求的负载均衡.

③ 接收到查询请求的shard执行该请求, 然后将查询结果响应给协调节点.

④ 协调节点将查询结果响应给客户端.

(2) 特殊情况说明:

如果某个document正在primary shard中建立索引, 其他replica shard还没有来得及同步此索引, 而协调节点却将查询请求转发到了某个这样的replica shard上, 就会出现 没有查到这个document 的情况.

当document完成索引的创建之后, primary shard和replica shard中就都有相关数据了.

强调: replica shard只能处理读(查询)请求.

参考资料

elasticsearch 6.6 官方文档 - coordinating node

版权声明

作者:

出处: 博客园

您的支持是对博主的极大鼓励, 感谢您的阅读.

本文版权归博主所有, 欢迎转载, 但请保留此段声明, 并在文章页面明显位置给出原文链接, 否则博主保留追究相关人员法律责任的权利.

您可能感兴趣的文章:

如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网