图解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模块。
扫描二维码关注公众号，回复：
12882555 查看本文章
