1 增删改document的流程

1.1 协调节点 - Coordinating Node

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

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

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

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

③ Primary Shard处理客户端的请求, 然后将操作后的Document同步到其对应的Replica Shard中.

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

注意: 增删改操作只能由Primary Shard处理, Replica Shard只能处理查询请求.

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

② 协调节点对客户端提交的文档进行路由, 明确存储相关文档的Primary Shard, 然后使用Round-Robin随机轮训算法, 将查询请求转发到该Primary Shard及其所有Replica Shard中的任意一个 —— 读请求的负载均衡.

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

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

特殊情况说明:

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

当Document完成索引的创建之后, Primary Shard和Replica Shard中就都有相关数据了.

说明: Replica Shard可以用来响应读请求.

版权声明

作者: ma_shoufeng(马瘦风)

出处: CSDN 马瘦风的博客

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

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