ES写数据延迟问题

 ES写数据延迟问题

问题背景

在index后有一个refresh_interval默认1秒，在这个时间间隔内search是不可见的。 

解决elasticsearch更新数据后不能立即刷新的问题_啦啦不要熬夜啊的博客-CSDN博客_es更新后立马刷新

写数据----->ES内存 buffer（缓存区）-------定期refresh成segment------>os系统文件缓冲区（在这里的数据对搜索可见）---->磁盘

refresh：Elasticsearch 刚索引的文档并不是立即对搜索可见，它们会先在内存 buffer（缓存区）中，buffer 数据满后或主动刷新操作才会进行refresh写入到文件缓存区中，便可以搜索。每秒refresh清空一次写缓冲的时候会产生一个新的Lucene 分段，新段先1.refresh写入文件系统缓存，但稍后再执行2.flush刷磁盘操作，写操作很快会执行完，一旦写成功，就可以像其他文件一样被打开和读取了。由于系统先缓冲一段数据才写到os缓存，且新段不会立即刷入磁盘，这两个过程中如果出现某些意外情况（如主机断电），则会存在丢失数据的风险。通用的做法是记录事务日志，每次对ES进行操作时均记录事务日志，当ES启动的时候，重放translog中所有在最后一次提交后发生的变更操作。

但是分段数量太多会带来较大的麻烦，每个段都会消耗文件句柄、内存。每个搜索请求都需要轮流检查每个段，查询完再对结果进行合并；所以段越多，搜索也就越慢。因此需要通过一定的策略将这些较小的段合并为大的段，常用的方案是选择大小相似的分段进行合并。在合并过程中，标记为删除的数据不会写入新分段，当合并过程结束，旧的分段数据被删除，标记删除的数据才从磁盘删除。

频繁refrsh的危害：每次索引的refresh会产生一个新的Lucene段，这会导致频繁的segment merge行为，如果不需要这么高的搜索实时性，应该降低索引refresh周期

解决方案

1.写数据时候，加上刷新策略

2.代码制定refresh的时间

3.通过ui层解决。比如更新成功后，弹出提示框

es 更新延迟问题_Zephyrrrrrrrrr的博客-CSDN博客

近实时搜索 | Elasticsearch: 权威指南 | Elastic

1.批量删除操作，加上刷新策略（等待分片与备份刷新完成后再返回），强制将缓存中的数据，刷到os缓冲区，保证下次读取，不会读到已经被删除的数据

关于elasticsearch批量删除后立马查询还能查出被删除的数据的问题