面试题：ElasticSearch searchtype在分布式环境下的选择与一致性保障

Question

在ElasticSearch的分布式集群环境中，searchtype的选择会如何影响数据的一致性？如何在保障数据一致性的前提下，合理选择searchtype以满足不同业务需求？请详细阐述涉及到的原理及实现方式。

Answer 1

1. search_type对数据一致性的影响

• dfs_query_then_fetch
  • 原理：首先在每个分片上执行查询（query），收集所有分片的词频等统计信息（DFS，Distributed Finite State Machine），再根据这些信息计算相关性分数，然后从各个分片上拉取（fetch）匹配的文档。
  • 对一致性影响：由于先收集统计信息再拉取文档，能获取到相对较新的数据状态，一致性较高。但在高并发写入场景下，统计信息收集和文档拉取之间可能存在数据更新，不过总体能保证较高一致性。
• query_then_fetch
  • 原理：直接在每个分片上执行查询，每个分片独立计算相关性分数并返回初步结果，然后协调节点从这些初步结果对应的分片中拉取完整文档。
  • 对一致性影响：没有专门的DFS步骤收集统计信息，在高并发写入场景下，各分片计算相关性分数时可能依据的数据版本不一致，导致最终结果的一致性相对较低。比如某个分片刚写入新数据，而其他分片还未感知到，可能造成部分数据在查询结果中出现或缺失不一致的情况。
• count
  • 原理：仅统计符合查询条件的文档数量，不涉及文档内容的拉取。
  • 对一致性影响：它只关心符合条件的文档计数，由于不涉及文档内容获取，一致性主要体现在计数的准确性上。在高并发写入场景下，如果写入和计数操作同时进行，可能出现计数偏差，但这种偏差通常较小且不影响整体业务对文档数量的大致了解。

2. 保障数据一致性前提下合理选择search_type

• 读多写少且对一致性要求极高的场景
  • 选择：优先使用dfs_query_then_fetch。
  • 实现方式：在构建查询请求时，将search_type参数设置为dfs_query_then_fetch。例如在使用Elasticsearch的REST API时，在请求URL中添加?search_type=dfs_query_then_fetch；在使用客户端（如Java High - Level REST Client）时，通过相应的请求构建器设置该参数。
• 读多写少但对一致性要求稍低，追求更高查询性能的场景
  • 选择：可以使用query_then_fetch。
  • 实现方式：与设置dfs_query_then_fetch类似，在请求构建时将search_type设置为query_then_fetch。这种场景下，虽然可能存在一定的数据一致性风险，但由于写入频率低，风险可控，同时能利用query_then_fetch相对简单的查询流程提升查询性能。
• 仅关注文档数量，对一致性要求不高的场景
  • 选择：使用count。
  • 实现方式：同样在请求构建时，将search_type设置为count。例如在REST API请求中，发送POST /index/_search?search_type=count，并在请求体中设置查询条件。这种方式在高并发写入场景下能快速返回大致的文档数量，满足业务对文档数量快速了解的需求，即使存在少量计数偏差也不影响业务。