ES读写数据的工作原理

一、es写数据过程

1、客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）

2、coordinating node 对document进行路由（_routing机制），将请求转发给对应的node（有primary shard）

3、实际的node上的primary shard 处理请求，，选择一个主分片写入数据，然后将数据同步到replica node。

4、coordinating node如果发现 primary node和所有replica node都搞定之后，就返回响应结果给客户端。

有那么一个印象就是，客户端的请求如果是http，应该是轮询请求，如果是tcp的话，就是随机发送请求到nodes上。

二、es读数据过程

可以通过doc id 来查询，会根据doc id进行hash，判断出来当时把doc id分配到了哪个shard上面去，从那个shard去查询。

1、客户端发送请求到任意一个node，成为coordinate node。

2、coordinate node 对doc id进行哈希路由，将请求转发到对应node，此时会使用round-robin随机轮询算法，在primary shard 以及其所有replica中随机选择一个，让读请求负载均衡。

3、接收请求的node返回document给coordinate node。

4、coordinate node返回document给客户端。

ES读数据，是先走os cache，os cache没有，就会去查磁盘。如果os cache满了，放不下更多数据，意味着大量的查询会去磁盘

三、es搜索数据过程

es最强大的是做全文检索

1、客户端发送请求到一个coordinate node。协调节点会创建一个大小为 from + size 的空优先队列。

2、协调节点将搜索请求转发到所有的shard对应的primary shard 或 replica shard ，都可以。每个分片在本地执行查询并添加结果到大小为 from + size 的本地有序优先队列中。

3、query phase：每个shard将自己的搜索结果（所有文档的 ID和排序值）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作。

4、fetch phase：接着由协调节点根据doc id去各个节点上拉取实际的document数据，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表，最终返回给客户端。

写请求是写入primary shard，然后同步给所有的replica shard

读请求可以从primary shard 或者 replica shard 读取，采用的是随机轮询算法。

例如：查询sise：30000

先从数据节点提取前30000条数据，然后每个节点都返回给协调节点30000条数据，比如三个数据节点，就返回90000条数据，最后协调节点取90000条中的30000条数据返回。

四、写数据底层原理

1、先写入内存buffer，在buffer里的时候数据是搜索不到的；同时将数据写入translog日志文件。

如果buffer快满了，或者到一定时间，就会将内存buffer数据refresh 到一个新的segment file中，但是此时数据不是直接进入segment file磁盘文件，而是先进入

os cache。这个过程就是 refresh。

每隔1秒钟，es将buffer中的数据写入一个新的segment file，每秒钟会写入一个新的segment file，这个segment file中就存储最近1秒内 buffer中写入的数据。

2、但是如果buffer里面此时没有数据，那当然不会执行refresh操作，如果buffer里面有数据，默认1秒钟执行一次refresh操作，刷入一个新的segment file中。

操作系统里面，磁盘文件其实都有一个东西，叫做os  cache，即操作系统缓存，就是说数据写入磁盘文件之前，会先进入os  cache，先进入操作系统级别的

一个内存缓存中去。只要buffer中的数据被refresh 操作刷入os cache中，这个数据就可以被搜索到了。

3、为什么叫es是准实时的？NRT，全称 near real-time。默认是每隔1秒refresh一次的，所以es是准实时的，因为写入的数据1s之后才能被看到。

可以通过es的restful api或者 java api，手动执行一次 refresh操作，就是手动将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。只要

数据被输入os cache中，buffer 就会被清空了，因为不需要保留buffer了，数据在translog里面已经持久化到磁盘去一份了。

4、重复上面的步骤，新的数据不断进入buffer和translog，不断将buffer数据写入一个又一个新的segment file中去，每次refresh完buffer清空，translog保留。

随着这个过程的推进，translog会变得越来越大。当translog达到一定长度的时候，就会触发commit操作。

5、commit操作发生的第一步，就是将buffer中现有的数据refresh到os  cache中去，清空buffer。然后将一个commit  point写入磁盘文件，里面标识者这个commit

point 对应的所有segment file，同时强行将os cache中目前所有的数据都fsync到磁盘文件中去。最后清空现有 translog日志文件，重启一个translog，此时commit操作完成。

6、这个commit操作叫做flush。默认30分钟自动执行一次flush，但如果translog过大，也会触发flush。flush操作就对应着commit的全过程，我们可以通过es api，手动执行

flush操作，手动将os  cache中数据fsync强刷到磁盘上去。

7、translog日志文件的作用是什么？

执行commit 操作之前，数据要么是停留在buffer中，要么是停留在os cache中，无论是buffer 还是os cache都是内存，一旦这台机器死了，内存中的数据就全丢了。

所以需要将数据对应的操作写入一个专门的日志文件translog中，一旦此时机器宕机了，再次重启的时候，es会自动读取translog日志文件中的数据，恢复到内存buffer

和os cache中去。

8、translog其实也是先写入os  cache的，默认每隔5秒刷一次到磁盘中去，所以默认情况下，可能有5s的数据会仅仅停留在buffer或者translog文件的os cache中，如果

此时机器挂了，会丢失5秒钟的数据。但是这样性能比较好，最多丢5秒的数据。

也可以将translog设置成每次写操作必须是直接fsync到磁盘，但是性能会差很多。

9、es第一是准实时的，数据写入1秒后就可以搜索到：可能会丢失数据的。有5秒的数据，停留在buffer、translog  os  cache 、segment file  os  cache中，而不在磁盘上，

此时如果宕机，会导致5秒的数据丢失。

10、总结：：数据先写入内存buffer，然后每隔1s，将数据refresh到 os cache，到了 os cache数据就能被搜索到（所以我们才说es从写入到能被搜索到，中间有1s的延迟）。

每隔5s，将数据写入到translog文件（这样如果机器宕机，内存数据全没，最多会有5s的数据丢失），translog达到一定程度，或者默认每隔30min，会触发commit操作，将缓冲区的

数据都flush到segment file磁盘文件中。

数据写入 segment file之后，同时就建立好了倒排索引。

五、删除/更新数据底层原理

如果是删除操作，commit的时候会生成一个 .del文件，里面将某个doc标识为 deleted状态，那么搜索的时候根据 .del文件就知道这个doc是否被删除了。

如果是更新操作，就是将原来的doc标识为deleted状态，然后重新写入一条数据。

buffer 每refresh一次，就会产生一个segment file，所以默认情况下是1秒钟一个segment file，这样下来segment file会越来越多，此时会定期执行merge。

每次merge的时候，会将多个segment file合并成一个，同时这里会将标识为 deleted的doc给物理删除掉，然后将新的segment file写入磁盘，这里会写一个

commit point，标识所有新的 segment file，然后打开segment file供搜索使用，同时删除旧的segment file。

六、底层lucence

简单来说，lucence就是一个jar包，里面包含了封装好的各种建立倒排索引的算法代码。我们用java 开发的时候，引入 lucene  jar，然后基于lucene的api去开发

就可以了。

通过lucene，我们可以将已有的数据建立索引，lucene会在本地磁盘上面，给我们组织索引的数据结果。

七、分片机制下隐藏的问题

分片机制虽然能有效提高查询速度，但是在执行聚合查询时，会引起聚合结果不准确的问题，需要根据实际业务场景决定如何选择。

解决方法：

1. 1. 方案1：设置主分片为1
   2. 方案2：调大 shard_size 值，减小误差
   3. 方案3：将size设置为最大值来解决精度问题

八、关于请求的一个理解

作为用户，我们可以访问包括master节点在内的集群中的任一节点。每个节点都知道各个文档的位置，并能够将我们的请求直接转发到拥有我们想要的数据的节点。无论我们访问的是哪个节点，当请求访问到这个节点的时候，它就成为协调节点，它都会控制从拥有数据的节点收集响应的过程，并返回给客户端最终的结果。

个人认为如果master节点不是被设置为单一的角色，被选举出来的master，同时承担datanode的角色。“访问包括master节点在内的集群中的任一节点”就符合这句话的场景。如果master仅仅承担master角色则无需参与文档层面的变更和搜索。如果集群中设置独立的协调节点的话，是否客户端所有文档层面的变更和搜索都有协调节点处理请求？是否可以选择协调节点和数据节点区分不同的请求？答案应该是否的，这部分请求区分应该由客户端来区分。

文章转载来自：https://www.cnblogs.com/yuxiang1/p/10601253.html