图解ES文档的读写原理
1. 简介
ES的Document API分单文档API和多文档API,它们的作用是对文档进行CRUD操作。
注意:所有的CRUD API都单index API,它们只接收一个index name或alias。
1.1 单文档API
- Index
- Get
- Delete
- Update
1.2 多文档API
- Multi Get
- Bulk
- Delete By Query
- Update By Query
- Reindex
2. 读写文档
2.1 主分片和副本分片
ES中每个index都被切分为几个分片,每个分片都可有多个副本。
举例:
- 1个集群有3个节点(node1~node3)
- 1个index被分为2个分片,分片1(P1),分片2(P2),P是Primary的缩写
- 1个主分片有2个副本分片,P1的副本为R1,P2的副本是R2,R是Replica的缩写
目前分片情况如下图:
图中绿色方块P1+两个R1是属于同一个复制组(Replication Group)。
同理黄色方块P2+两个R2是属于同一个复制组(Replication Group)。
3. 写模式
文档的写模式包括新增/修改/删除文档。它一般有如下执行步骤。
- ES的index操作第一步都是通过routing决定发往哪个复制组(Replication Group)。
- 一旦确定了复制组,index操作会被转发给这个复制组内的主分片(如上图的P1或P2)。
- 主分片负责验证index操作,验证通过则执行该index操作。
- 主分片执行成功后,把index操作转发给它的所有副本分片。
- 一旦所有的副本分片执行成功并通知到主分片,主分片才通知主节点(协调节点)执行成功。
- 主节点将结果返回给客户端。
下面通过图片依次介绍上面的操作(PPT画的图,不好看,见谅)
3.1 routing到主分片
- 客户端(笑脸)把请求发给ES集群里的协调节点node1
- 根据routing算出文档属于黄色的复制组
- 协调节点node1把index操作转发给黄色复制组中主分片P2
3.2 主分片分发给副本分片
- 主分片P2介绍到请求并验证,验证通过后执行操作
- 主分片P2把请求转发给它的副本(2个黄色的R2)
3.3 执行成功后返回通知
- 副本分片R2执行请求,把结果返回给主分片P2,图中红色线4
- 主分片接受到所有的副本分片返回的成功结果,才通知协调节点node1成功了,图中黄色线5
- 协调节点node1告诉客户端(笑脸)该写操作执行成功
4. 读模式
ES可以有非常轻量级的查询:按照ID查找。也可以有复杂的聚合搜索请求。主备模型的一个优点就是它让所有的分片(主和备)的数据是等同的。
ES的增删改是在主节点上协调操作的,但是读操作是可以由非主节点操作。
当一个节点接受到读请求时,该节点负责将该请求转发到保存该文档的相关分片的节点。我们称该节点为协调节点(注意只是本次请求的协调节点)。
- 协调节点解析到相关分片,默认根据id值hash,获取是哪个分片(复制组1还是复制组2)
- 从分片的复制组中选择一个活动分片(通常是轮询),可以是主分片也可是副本分片
- 向所选分片发送读取请求,分片查询结果返回给协调节点
- 协调节点将结果整合,返回给客户端
4.1 接受请求,再获取分片复制组
- node1获取了客户端的请求,箭头1
- node1计算出文档在绿色的复制组(P1+R1)
- node1根据轮询算法,把请求发给node2上的R1
4.2 返回结果
- node2把R1里的文档饭会给node1,箭头3
- node1把文档返回给客户端,箭头4
5. 总结
ES的知识点太多,这里只是简单的介绍下它的读写模式,他的读写异常处理暂时不涉及到,需要了解的可以看官方文档,写的很详细。
下面打算结合ES的Query DSL和JavaAPI,深入学习ES的Document和Search模块。