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

介紹

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

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

造成的問題

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

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

刷新策略RefreshPolicy

1.NONE：（默認(rèn)策略）

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

2.WAIT_UNTIL：

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

3.IMMEDIATE：

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

支持的接口：

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

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

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

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

---

結(jié)束