本文主要是介绍ES核心概念（45-48）（56-62）（101-103），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
ES集群
ES集群（Cluster）包含多个节点（服务器），整体提供服务
核心概念
索引Index：类似于mysql中的表
映射Mapping:数据的结构信息
文档：相当于表中的一条记录
分片：
将数据分成多片（数据可以放在不同的节点上）
允许你水平分割 / 扩展你的内容容量。
允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
副本：
在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于
离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的， Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片(副本)。
复制分片之所以重要，有两个主要原因：
在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。
分配Allocation
将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由 master 节点完成的
系统架构
P0,1,2为分片 对应的R0,1,2为副本 （分片和副本不在同一节点）
一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同
cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、
删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作
故障转移
当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。集群拥有两个节点 : 所有主分片和副本分片都已被分配
水平扩容
多个集群多个分片副本 更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去 2 个节点
的情况下不丢失任何数据。
应对故障
主节点故障则重新选举一个新的主节点
路由计算 & 分片控制
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个
文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
outing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好，主分片的数量并且永远不会改变:因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
所有的文档API ( get . index . delete 、 bulk , update以及 mget ）都接受一个叫做routing 的路由参数，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档—一例如所有属于同一个用户的文档——都被存储到同一个分片中。
分片控制
我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。
数据写流程
新建、索引和删除请求都是写操作， 必须在主分片上面完成之后才能被复制到相关的副本分片。
在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。由consistency 控制
consistency 参数的值可以设为：
one ：只要主分片状态 ok 就允许执行写操作。
all：必须要主分片和所有副本分片的状态没问题才允许执行写操作。
quorum：默认值为quorum , 即大多数的分片副本状态没问题就允许执行写操作。
数据读流程
在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。
什么是协调节点
负责协调和管理其他节点的工作。在大数据处理中,协调节点通常是一个主节点,它与其他工作节点通信并分配任务
更新流程 & 批量操作流程
更新流程：
更新一个文档的步骤如下：
客户端向Node 1发送更新请求。
它将请求转发到主分片所在的Node 3 。
Node 3从主分片检索文档，修改_source字段中的JSON，并且尝试重新索引主分片的文档。如果文档已经被另一个进程修改,它会重试步骤3 ,超过retry_on_conflict次后放弃。
如果 Node 3成功地更新文档，它将新版本的文档并行转发到Node 1和 Node 2上的副本分片，重新建立索引。一旦所有副本分片都返回成功，Node 3向协调节点也返回成功，协调节点向客户端返回成功。
当主分片把更改转发到副本分片时， 它不会转发更新请求。 相反，它转发完整文档的新版本。
批量操作流程：
协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返回给客户端
动态更新索引
通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到,从最早的开始查询完后再对结果进行合并。
段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新 每个提交点会包含一个.del 文件，文件中会列出这些被删除文档的段信息。
当一个**文档被“删除”**时，它实际上只是在 .del 文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前从结果集中移除。
文档刷新 & 文档刷写 & 文档合并
文档刷写 插入数据先写入内存 后刷写到磁盘 然后请求才可以访问数据 translog保证数据安全（先内存 后磁盘）可以在缓冲区进行查询 然后通过写入策略写入磁盘
流程：
1.一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog
2.刷新（refresh）使分片每秒被刷新（refresh）一次：
这些在内存缓冲区的文档被写入到一个新的段中，且没有进行fsync操作。
这个段被打开，使其可被搜索。
内存缓冲区被清空。
3.这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志
4.每隔一段时间—例如translog变得越来越大，索引被刷新（flush）；一个新的translog被创建，并且一个全量提交被执行。
所有在内存缓冲区的文档都被写入一个新的段。
缓冲区被清空。
一个提交点被写入硬盘。
文件系统缓存通过fsync被刷新（flush） 。
老的translog被删除。
文档合并
段合并
由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和 cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。
段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
启动段合并不需要你做任何事。进行索引和搜索时会自动进行。
一、当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。
二、合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索
一旦合并结束，老的段被删除
新的段被刷新(flush)到了磁盘。
写入一个包含新段且排除旧的和较小的段的新提交点。
新的段被打开用来搜索。老的段被删除。
文档控制
保证没有两个线程同时操作文档（加锁）
这篇关于ES核心概念（45-48）（56-62）（101-103）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
