Elasticsearch 參考指南（?refresh）

?refresh

索引、更新、刪除和批量API支持設置refresh，以控制什麼時候由此請求作出的更改對搜索可見，這些是容許的值：

空字符串或true

• 在操做發生後當即刷新相關的主碎片和副本碎片（不是整個索引），以便更新後的文檔當即出如今搜索結果中，只有通過仔細考慮和核實，從索引和搜索的角度來看，它不會致使性能低下以後，才能這樣作。

wait_for

• 在應答以前，等待請求所作的更改被刷新可見，這並非強制當即刷新，而是等待刷新發生。Elasticsearch會每index.refresh_interval（默認值爲1秒）自動刷新已經更改的碎片，這個設置是動態的。調用Refresh API或在任何支持它的API上將refresh設置爲true也會致使刷新，從而致使已經運行的帶有refresh=wait_for的請求返回。

false（默認）

• 不執行刷新相關操做，此請求所作的更改將在請求返回後的某個時刻變得可見。

選擇使用哪一個設置

除非你有充分的理由等待更改變爲可見，不然老是使用refresh=false，或者，由於這是默認值，因此將refresh參數排除在URL以外，這是最簡單、最快的選擇。

若是你必須使請求所作的更改可見與請求同步，那麼你必須在對Elasticsearch增長更多負載（true）和等待更長時間的響應（wait_for）之間進行選擇，如下幾點應該爲該決定提供參考：

• 與true相比，對索引進行的更改越多，wait_for節省越多的工做，在每次index.refresh_interval只更改一次索引的狀況下，它不會節省任何工做。
• true建立的索引結構效率較低（小段），稍後必須合併爲更高效的索引結構（大段），這意味着true的代價是在索引時建立小段，在搜索時搜索小段，在合併時製做大段。
• 不要在一行中啓動多個refresh=wait_for請求，相反，將使用refresh=wait_for的請求批量到單個bulk請求中，Elasticsearch將會並行啓動它們，只有當它們所有完成時才返回。
• 若是刷新間隔設置爲-1，則禁用自動刷新，那麼具備refresh=wait_for的請求將無限期地等待，直到某個操做致使刷新。相反，將index.refresh_interval設置爲比默認值更短的值，好比200ms，將使refresh=wait_for返回的速度更快，但仍然會生成效率低下的段。
• refresh=wait_for隻影響它所在的請求，可是，經過強制當即刷新，refresh=true將影響其餘正在進行的請求，一般，若是你有一個正在運行的系統，你不但願打擾它，那麼refresh=wait_for是一個較小的修改。

refresh=wait_for能夠強制刷新

若是已經有index.max_refresh_listener（默認爲1000）請求等待刷新的狀況下在那個碎片上出現refresh=wait_for請求，那麼該請求的行爲就好像它已經將refresh設置爲true同樣：它將強制刷新。這保證了當refresh=wait_for請求返回時，它的更改對於搜索是可見的，同時防止對被阻塞的請求使用未檢查的資源，若是一個請求由於耗盡了監聽器插槽而強制刷新，那麼它的響應將包含"forced_refresh": true。

Bulk請求在每一個碎片上只佔用一個插槽，無論它們修改碎片多少次。

樣例

這將建立一個文檔，並當即刷新索引，使其可見：

PUT /test/_doc/1?refresh
{"test": "test"}
PUT /test/_doc/2?refresh=true
{"test": "test"}

這將建立一個文檔，而不須要作任何事情使其對於搜索可見：

PUT /test/_doc/3
{"test": "test"}
PUT /test/_doc/4?refresh=false
{"test": "test"}

這將建立一個文檔，並等待它對於搜索成爲可見：

PUT /test/_doc/4?refresh=wait_for
{"test": "test"}