基础知识
首先,我们知道,es中刷新策略:
默认情况下ElasticSearch索引的refresh_interval为1秒,这意味着数据写1秒才就可以被搜索到。
每次索引refresh会产生一个新的 lucene 段,这会导致频繁的 segment merge 行为,对系统 CPU 和 IO 占用都比较高。
如果产品对于实时性要求不高,则可以降低刷新周期,如:index.refresh_interval: 120s。
但是这种特性对于功能测试来说比较麻烦:
因为实时性不能保证,所以每次插入测试数据之后,都需要sleep一段时间,才能进行测试。
因为实时性不能保证,及时通过sleep策略通过的case,也可能偶尔失败。
为了解决上述问题,需要提供ElasticSearch增删改数据之后数据立即刷新的策略。
org.elasticsearch.action.support.WriteRequest.RefreshPolicy定义了三种策略:
/**
* Don't refresh after this request. The default.
*/
NONE,
/**
* Force a refresh as part of this request. This refresh policy does not scale for high indexing or search throughput but is useful
* to present a consistent view to for indices with very low traffic. And it is wonderful for tests!
*/
IMMEDIATE,
/**
* Leave this request open until a refresh has made the contents of this request visible to search. This refresh policy is
* compatible with high indexing and search throughput but it causes the request to wait to reply until a refresh occurs.
*/
WAIT_UNTIL;
可知有以下三种刷新策略:
RefreshPolicy#IMMEDIATE:
请求向ElasticSearch提交了数据,立即进行数据刷新,然后再结束请求。
优点:实时性高、操作延时短。
缺点:资源消耗高。
RefreshPolicy#WAIT_UNTIL:
请求向ElasticSearch提交了数据,等待数据完成刷新,然后再结束请求。
优点:实时性高、操作延时长。
缺点:资源消耗低。
RefreshPolicy#NONE:
默认策略。
请求向ElasticSearch提交了数据,不关系数据是否已经完成刷新,直接结束请求。
优点:操作延时短、资源消耗低。
缺点:实时性低。
RefreshPolicy.IMMEDIATE 不生效?
- 确定是否在对应的request 加上了 RefreshPolicy,如下错误示例:
UpdateRequest updateRequest = new UpdateRequest(getIndexName(), esContentDoc.getId().toString());
updateRequest.doc(JSON.toJSONString(esContentDoc), XContentType.JSON).retryOnConflict(3);
IndexRequest request = new IndexRequest(getIndexName()).id(esContentDoc.getId().toString());
request.source(JSON.toJSONString(esContentDoc), XContentType.JSON);
request.setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE);
updateRequest.upsert(request);
restHighLevelClient.update(updateRequest, RequestOptions.DEFAULT);
咋一看,没问题,加上了?
其实加在了 IndexRequest ,只有不存在时的index才会立即刷新,而update 却不会立即刷新