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"}