【ES】写入后查询秒级延迟

最近在测试项目的过程中发现，业务写ES后通过查询接口查不到数据，当设置1S延迟后再查询ES才能查到数据，根本原因是ES写入后有秒级的延迟
参考文章：https://cloud.tencent.com/developer/article/1122703

在Elasticsearch和磁盘之间还有一层称为FileSystem Cache的系统缓存，正是由于这层cache的存在才使得es能够拥有更快搜索响应能力。

我们都知道一个index是由若干个segment组成，随着每个segment的不断增长，我们索引一条数据后可能要经过分钟级别的延迟才能被搜索，为什么有种这么大的延迟，这里面的瓶颈点主要在磁盘。

持久化一个segment需要fsync操作用来确保segment能够物理的被写入磁盘以真正的避免数据丢失，但是fsync操作比较耗时，所以它不能在每索引一条数据后就执行一次，如果那样索引和搜索的延迟都会非常之大。

所以这里需要一个更轻量级的处理方式，从而保证搜索的延迟更小。这就需要用到上面提到的FileSystem Cache，所以在es中新增的document会被收集到indexing buffer区后被重写成一个segment然后直接写入filesystem cache中，这个操作是非常轻量级的，相对耗时较少，之后经过一定的间隔或外部触发后才会被flush到磁盘上，这个操作非常耗时。但只要sengment文件被写入cache后，这个sengment就可以打开和查询，从而确保在短时间内就可以搜到，而不用执行一个full commit也就是fsync操作，这是一个非常轻量级的处理方式而且是可以高频次的被执行，而不会破坏es的性能。

在elasticsearch里面，这个轻量级的写入和打开一个cache中的segment的操作叫做refresh，默认情况下，es集群中的每个shard会每隔1秒自动refresh一次，这就是我们为什么说es是近实时的搜索引擎而不是实时的，也就是说给索引插入一条数据后，我们需要等待1秒才能被搜到这条数据，这是es对写入和查询一个平衡的设置方式，这样设置既提升了es的索引写入效率同时也使得es能够近实时检索数据。

refresh操作相比commit操作是非常轻量级的但是它仍然会耗费一定的性能，所以不建议在每插入一条数据后就执行一次refresh命令，es默认的1秒的延迟对于大多数场景基本都可以接受。