ElasticSearch搜索引擎：数据的写入流程

一、ElasticSearch 写数据的总体流程：

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

（2）协调节点对 document 进行路由，通过 hash 算法计算出数据应该落在哪个分片 shard 上，然后根据节点上维护的 shard 信息，将请求转发到对应的实际处理节点node上

shard = hash(document_id) % (num_of_primary_shards)，

（3）实际的节点上的 primary shard 主分片处理请求，然后将数据同步到副本节点 replica node

（4）coordinating node 等到 primary node 和所有 replica node 都执行成功之后，就返回响应结果给客户端。

二、ES 的主分片写数据的详细流程：

1、refresh 操作：
primary shard 主分片先将数据写入 memory buffer，然后定时（默认每隔1s）将 memory buffer 中的数据写入一个新的 segment 文件中，并进入 Filesystem cache（同时清空 memory buffer），这个过程就叫做 refresh；每个 Segment 文件实际上是一些倒排索引的集合， 只有经历了 refresh 操作之后，这些数据才能变成可检索的。

ES 的近实时性：当数据存在 memory buffer 时是搜索不到的，只有数据被 refresh 到 Filesystem cache 之后才能被搜索到，而 refresh 是每秒一次， 所以称 es 是近实时的，或者可以通过手动调用 es 的 api 触发一次 refresh 操作，让数据马上可以被搜索到；

     上文讲到的 memory buffer，也称为 Indexing Buffer，这个区域默认的内存大小是 10% heap size。
1

2、写 translog 事务日志文件：
由于 memory Buffer 和 Filesystem Cache 都是基于内存，假设服务器宕机，那么数据就会丢失，所以 ES 通过 translog 日志文件来保证数据的可靠性，在数据写入 memory buffer 的同时，将数据写入 translog 日志文件中，在机器宕机重启时，es 会从磁盘中读取 translog 日志文件中最后一个提交点 commit point 之后的数据，恢复到 memory buffer 和 Filesystem cache 中去。

ES 数据丢失的问题：translog 也是先写入 Filesystem cache，然后默认每隔 5 秒刷一次到磁盘中，所以默认情况下，可能有 5 秒的数据会仅仅停留在 memory buffer 或者 translog 文件的 Filesystem cache中，而不在磁盘上，如果此时机器宕机，会丢失 5 秒钟的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘，但是性能会差很多。

3、flush 操作：
不断重复上面的步骤，translog 会变得越来越大，当 translog 文件默认每30分钟或者阈值超过 512M 时，就会触发 flush 操作，将 memory buffer 中所有的数据写入新的 Segment 文件中， 并将内存中所有的 Segment 文件全部落盘，最后清空 translog 事务日志。

（1）将 memory buffer 中的数据 refresh 到 Filesystem Cache 中的一个新的 segment 文件中去，然后清空 memory buffer；
（2）创建一个新的 commit point（提交点），同时强行将 Filesystem Cache 中目前所有的数据都 fsync 到磁盘文件中；
（3）删除旧的 translog 日志文件并创建一个新的 translog 日志文件，此时 flush 操作完成
ES 的 flush 操作主要通过以下几个参数控制：

index.translog.flush_threshold_period：每隔多长时间执行一次flush，默认30m
index.translog.flush_threshold_size：当事务日志大小到达此预设值，则执行flush，默认512mb
index.translog.flush_threshold_ops：当事务日志累积到多少条数据后flush一次。
————————————————
版权声明：本文为CSDN博主「张维鹏」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a745233700/article/details/118076845