Elasticsearch數據刷新策略RefreshPolicy簡述

說明

默認情況下ElasticSearch索引的refresh_interval為1秒，這意味着數據寫1秒才就可以被搜索到。

每次索引refresh會產生一個新的 lucene 段，這會導致頻繁的 segment merge 行為，對系統 CPU 和 IO 占用都比較高。

如果產品對於實時性要求不高，則可以降低刷新周期，如：index.refresh_interval: 120s。

但是這種特性對於功能測試來說比較麻煩：

• 因為實時性不能保證，所以每次插入測試數據之后，都需要sleep一段時間，才能進行測試。
• 因為實時性不能保證，及時通過sleep策略通過的case，也可能偶爾失敗。

為了解決上述問題，需要提供ElasticSearch增刪改數據之后數據立即刷新的策略。

源碼

ElasticSearch 6.6.2

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

轉載：(2條消息) Elasticsearch數據刷新策略RefreshPolicy簡述_m0_45406092的博客-CSDN博客