Elasticsearch数据刷新策略RefreshPolicy简述

说明

默认情况下ElasticSearch索引的refresh_interval为1秒，这意味着数据写1秒才就可以被搜索到。

每次索引refresh会产生一个新的 lucene 段，这会导致频繁的 segment merge 行为，对系统 CPU 和 IO 占用都比较高。

如果产品对于实时性要求不高，则可以降低刷新周期，如：index.refresh_interval: 120s。

但是这种特性对于功能测试来说比较麻烦：

• 因为实时性不能保证，所以每次插入测试数据之后，都需要sleep一段时间，才能进行测试。
• 因为实时性不能保证，及时通过sleep策略通过的case，也可能偶尔失败。

为了解决上述问题，需要提供ElasticSearch增删改数据之后数据立即刷新的策略。

源码

ElasticSearch 5.1.1

org.elasticsearch.action.support.WriteRequestBuilder#setRefreshPolicy接口如下：

default B setRefreshPolicy(RefreshPolicy refreshPolicy) {
    request().setRefreshPolicy(refreshPolicy);
    return (B) this;
}

枚举org.elasticsearch.action.support.WriteRequest.RefreshPolicy定义了三种策略：

NONE,
IMMEDIATE,
WAIT_UNTIL; 

可知有以下三种刷新策略：

• RefreshPolicy#IMMEDIATE:
  请求向ElasticSearch提交了数据，立即进行数据刷新，然后再结束请求。
  优点：实时性高、操作延时短。
  缺点：资源消耗高。
• RefreshPolicy#WAIT_UNTIL:
  请求向ElasticSearch提交了数据，等待数据完成刷新，然后再结束请求。
  优点：实时性高、操作延时长。
  缺点：资源消耗低。
• RefreshPolicy#NONE:
  默认策略。
  请求向ElasticSearch提交了数据，不关系数据是否已经完成刷新，直接结束请求。
  优点：操作延时短、资源消耗低。
  缺点：实时性低。

实现此接口的主要类如下：

• DeleteRequestBuilder
• IndexRequestBuilder
• UpdateRequestBuilder
• BulkRequestBuilder