Elasticsearch(ES)(版本7.x)數(shù)據(jù)更新后刷新策略RefreshPolicy

介紹

ES數(shù)據(jù)寫入后，默認1s后才會被搜索到（refresh_interval為1）；

這樣可能是考慮到性能問題，畢竟實時IO 消耗較多資源

造成的問題

例如一個索引現(xiàn)在有100個文檔，當新增一個文檔時，立即查詢，顯示數(shù)量為100，并不為101

例如當修改一個文檔數(shù)據(jù)后，立即查詢的結(jié)果為上次文檔的數(shù)據(jù)，并不為最新數(shù)據(jù)

刷新策略RefreshPolicy

1.NONE：（默認策略）

• 請求提交數(shù)據(jù)后，不等待數(shù)據(jù)刷新，直接結(jié)束請求
• 優(yōu)點：操作延時短、資源消耗低
• 缺點: 實時可見性低，數(shù)據(jù)可能不會立即可見，直到下一個自動刷新周期。
• 適用場景: 對實時性要求不高但對性能敏感的應用。

2.WAIT_UNTIL：

• 索引操作完成后，Elasticsearch 會等待當前正在進行的刷新周期完成(1s)再返回客戶端請求
• 優(yōu)點：數(shù)據(jù)會在當前刷新周期內(nèi)變得可搜索，通常比 None 策略具有更好的實時性
• 缺點：可能會有較高的延遲，尤其是在刷新周期較長時間的情況下
• 適用場景: 需要較快的數(shù)據(jù)可見性，但又不想強制立即刷新的情況

3.IMMEDIATE：

• 請求提交數(shù)據(jù)后，立即進行數(shù)據(jù)刷新，再結(jié)束請求返回客戶端
• 優(yōu)點：實時性高、操作延時短，數(shù)據(jù)幾乎立即變得可搜索
• 缺點：強制刷新會消耗較多資源，并可能導致更高的延遲
• 適用場景：對數(shù)據(jù)實時性有極高要求的應用

支持的接口：

• 刪除：DeleteRequestBuilder
• 新增：IndexRequestBuilder
• 更新：UpdateRequestBuilder
• 批量：BulkRequestBuilder

用法：(elasticsearch-rest-high-level-client)

// 設置為立即刷新
request.setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE);// 設置為等待當前刷新周期
request.setRefreshPolicy(WriteRequest.RefreshPolicy.WAIT_UNTIL);// 使用默認策略（即不等待刷新）
request.setRefreshPolicy(WriteRequest.RefreshPolicy.NONE);

其中 WriteRequest.RefreshPolicy 是一個枚舉類型，包含了以上提到的不同刷新策略選項。
需要注意的是，頻繁的刷新可能會導致更多的磁盤I/O操作，增加CPU負載，并可能導致更多的段合并操作，從而影響整體性能。因此，在選擇刷新策略時，需要根據(jù)實際應用場景來平衡實時性和性能之間的關系。

---

結(jié)束