面试题答案
一键面试1. Search Type对搜索结果一致性与可用性的影响
- query_then_fetch：
- 一致性：先在各个分片上执行查询（query 阶段），收集各分片的相关文档ID及排序信息，再在协调节点根据这些信息从各分片获取文档内容（fetch 阶段）。由于query阶段只涉及轻量级的文档ID和排序信息收集，所以在高并发下能较快响应，不过在fetch阶段可能因为文档获取的延迟或失败影响一致性。例如，在一个高并发环境下，某个分片上的文档在query阶段之后、fetch阶段之前被更新，那么可能获取到的不是最新版本的文档。
- 可用性：总体可用性较高，因为query阶段轻量级，能快速给出部分结果。但fetch阶段如果某个分片出现故障，可能导致部分文档无法获取，影响整体可用性。
- dfs_query_then_fetch：
- 一致性：在query阶段之前会先执行一个分布式的词频统计（DFS），以获取更准确的文档相关性分数。这使得搜索结果在文档相关性方面更具一致性，因为它考虑了全局的词频信息。例如，在一个包含大量文档的分布式系统中，某些词在不同分片上的频率差异较大，dfs_query_then_fetch能更准确地反映这些差异，给出更一致的相关性排序。
- 可用性：由于增加了DFS阶段，开销更大，在高并发时响应速度会变慢，可用性会受到一定影响。如果某个分片在DFS阶段出现故障，可能导致整个搜索请求失败。
- count：
- 一致性：只关注文档数量统计，不涉及文档内容获取。一致性主要体现在文档数量统计的准确性上。如果在统计过程中有文档的增删改，可能导致数量统计的不一致。例如，在统计过程中某个分片上有新文档写入，可能导致最终统计的文档数量不准确。
- 可用性：相对较高，因为操作简单，只进行数量统计，不涉及复杂的文档获取操作。但如果某个分片出现故障，可能导致数量统计不准确。
- scan：
- 一致性：用于扫描大量数据，不考虑排序，按分片顺序依次返回文档。一致性较差，因为不保证全局排序，每次扫描可能因为分片返回顺序不同而结果有差异。例如，在多次扫描时，由于不同分片返回文档的先后顺序不同，可能导致每次获取到的文档顺序不一致。
- 可用性：可用性较高，因为不进行复杂的排序操作，能快速返回数据。但如果某个分片出现故障，可能导致部分数据无法获取。
2. 高并发下的优化策略
- 调整Search Type：
- 选择query_then_fetch：在大多数高并发场景下，优先选择query_then_fetch，因为它在保证一定一致性的同时，能提供较高的可用性和响应速度。例如，在电商搜索场景中，用户更关注快速获取搜索结果，对文档一致性要求并非绝对严格，query_then_fetch能满足快速返回商品列表的需求。
- 特殊场景考虑dfs_query_then_fetch：如果业务对文档相关性要求极高，如学术文献搜索，即使在高并发下也可适当使用dfs_query_then_fetch。但要结合后续的参数调整来优化性能。
- 相关参数调整：
- 设置合理的副本数：增加副本数可以提高可用性，在某个主分片故障时，副本分片能继续提供服务。但过多副本会增加存储和网络开销，需根据实际情况权衡。例如，在一个对可用性要求极高的新闻搜索系统中，可以适当增加副本数到2 - 3个。
- 调整shard数量：合适的shard数量能平衡负载，提高搜索性能。如果shard数量过多，会增加管理开销；过少则可能导致负载不均衡。例如，在一个包含1000万文档的分布式系统中，根据文档大小和服务器资源，可将shard数量设置为10 - 20个。
- 设置合适的timeout：对于高并发搜索请求，设置合理的timeout值能避免请求长时间等待。例如，设置为5 - 10秒，若在这个时间内无法获取全部结果，先返回已获取的部分结果，保证用户体验。
3. 实际案例
- 电商搜索案例：某大型电商平台，每天有百万级的搜索请求。最初使用dfs_query_then_fetch，虽然搜索结果相关性高，但在高并发下响应速度慢，可用性降低，经常出现超时情况。后来调整为query_then_fetch，并增加副本数到2个，调整shard数量为15个，设置timeout为8秒。优化后，搜索响应速度明显提升，可用性达到99%以上，虽然在文档相关性上略有下降，但用户体验整体得到改善，搜索转化率也有所提高。
- 日志分析案例：在一个大规模的日志分析系统中，需要快速统计日志数量并进行简单的关键字搜索。采用count和query_then_fetch结合的方式，count用于快速统计日志数量，query_then_fetch用于获取相关日志内容。同时，根据日志量动态调整shard数量，在高并发时保证了快速响应和结果的一致性，可用性也维持在较高水平。