Elasticsearch refresh

Elasticsearch 的 refresh

Index, Update, Delete, and Bulk APIs 支持通过设置 refresh 来该请求是否对查询可见；有如下值可以使用：

空字符串或者 true
当操作发生后，立即更新相关的主分片以及复制分片（并不是整个索引），更新的文档会立即出现在查询结果中。如果做此修改要仔细的思考和验证，不管从索引还是查询的角度，都不会导致性能变差。
wait for
在响应之前，等待请求所做的更改被刷新可见。这个并不会强制立即刷新，而是等待一次刷新发生。Elasticsearch 自动的在每个（index.refresh_interval）周期内刷新分片，该默认时间为 1s，可以动态修改。调用 Refresh API 或者设置支持refresh 为 true 的API 也会造成刷新，从而导致已经运行 refresh=wait_for 的请求返回。
false（默认）
不采取任何刷新相关操作。此请求所做的更改将在请求返回后的某个时间变得可见。

选择要使用的配置

除非你有充足的理由需要等待改变变为可见，否则就使用 refresh=false，因为这个是默认的，所以 ULR 上也不需要保留这个参数。这个是最简单与便捷的选择。

如果你要求必须更改与请求同步可见，那么就需要在向 Elasticsearch 添加更多负载和等待更长时间的响应之间进行选择。以下几点有助于你作出决定：

设置为 wait_for 相比于设置为 true，索引上的更改越多，保留的工作也越多，如果索引每个周期内 index.refresh_interval 更改一次，则不保存任何工作。
设置为 true 会创造低效的索引结构（小的 segment），然后必须将其合并为更大的索引结构（大的 segment）。意味着设置为 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` 也可能强制刷新

如果一个 refresh=wait_for 请求进来，这个时候已经有 index.max_refresh_listeners 个请求（默认1000）等待那个分片刷新，那个这个请求就会表现为 true: 它将会强制刷新。这保证了当 refresh=wait_for 请求返回时更改对于搜索可见，同时防止未检查的资源被阻塞的请求使用。如果一个请求因为监听 slog 不够而强制刷新，那么响应体中会包含 "forced_refresh": true;

Bulk 请求仅仅会占用每个接触分片一个的 slot，无论对该分片修改多少次。