🔥Elasticsearch(ES)(版本7.x)数据更新后刷新策略RefreshPolicy

💖简介

在Elasticsearch 7.x版本中，当更新数据时（例如索引、更新或删除文档），这些更改并不会立即对搜索可见。为了让这些更改能够被搜索到，需要了解和选择合适的刷新策略（Refresh Policy）。刷新操作会将内存中的变更提交到文件系统缓存中，并使这些变更对搜索可见。

📖默认

ES数据写入后，默认1s后才会被搜索到（refresh_interval为1）；

这样可能是考虑到性能问题，毕竟实时IO 消耗较多资源

👉场景

• 例如一个索引现在有100个文档，当新增一个文档时，立即查询，显示数量为100，并不为101

• 例如当修改一个文档数据后，立即查询的结果为上次文档的数据，并不为最新数据

⭐刷新策略RefreshPolicy

🌟1.NONE：（默认策略）

• 请求提交数据后，不等待数据刷新，直接结束请求
• 优点：操作延时短、资源消耗低
• 缺点: 实时可见性低，数据可能不会立即可见，直到下一个自动刷新周期。
• 适用场景: 对实时性要求不高但对性能敏感的应用。

🌟2.WAIT_UNTIL：

• 索引操作完成后，Elasticsearch 会等待当前正在进行的刷新周期完成(1s)再返回客户端请求
• 优点：数据会在当前刷新周期内变得可搜索，通常比 None 策略具有更好的实时性
• 缺点：可能会有较高的延迟，尤其是在刷新周期较长时间的情况下
• 适用场景: 需要较快的数据可见性，但又不想强制立即刷新的情况

🌟3.IMMEDIATE：

• 请求提交数据后，立即进行数据刷新，再结束请求返回客户端
• 优点：实时性高、操作延时短，数据几乎立即变得可搜索
• 缺点：强制刷新会消耗较多资源，并可能导致更高的延迟
• 适用场景：对数据实时性有极高要求的应用

💡支持的接口：

• 删除：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负载，并可能导致更多的段合并操作，从而影响整体性能。因此，在选择刷新策略时，需要根据实际应用场景来平衡实时性和性能之间的关系。

---

结束