用户管理的分布式搜索

当使用传统的索引分片时，您需要考虑如何查询您的文档。

强烈建议您在需要向上扩展或向外扩展时使用SolrCloud。下面描述的设置是旧的，在 SolrCloud 存在之前使用。SolrCloud 提供了一组真正的分布式功能，支持自动路由、领导者选举、乐观并发以及分布式系统所需的其他健全性检查。

此页面上的所有内容都特定于分布式搜索的旧版设置。尝试 SolrCloud 的用户不应遵循以下任何步骤或信息。

更新会重新排序（即，副本 A 可能会先看到更新 X，然后看到 Y，而副本 B 可能会先看到更新 Y，然后看到 X）。 deleteByQuery 也以相同的方式处理重新排序，以确保副本是一致的。分片的所有副本都是一致的，即使更新在不同的副本上以不同的顺序到达。

在分片之间分配文档

当不使用 SolrCloud 时，您需要将所有文档索引到服务器场的每个分片上。Solr 仅在 SolrCloud 模式下以其真实形式支持分布式索引（路由）。

在旧版分布式模式中，Solr 不会计算通用的词/文档频率。对于大多数大规模实现，Solr 在分片级别计算 TF/IDF 可能无关紧要。但是，如果您的集合在服务器之间的分布严重倾斜，您可能会在搜索中发现具有误导性的相关性结果。一般来说，最好将文档随机分配到您的分片。

使用 shards 参数执行分布式搜索

如果查询请求包含 shards 参数，则 Solr 服务器会将请求分发到作为参数的参数列出的所有分片。shards 参数使用以下语法

host:port/base_url,host:port/base_url*

例如，下面的 shards 参数导致搜索分布在两个 Solr 服务器上：solr1 和 solr2，它们都在端口 8983 上运行

https://127.0.0.1:8983/solr/core1/select?shards=solr1:8983/solr/core1,solr2:8983/solr/core1&indent=true&q=ipod+solr

通常首选在 solrconfig.xml 的 RequestHandler 部分中将此参数配置为默认值，而不是要求用户显式包含 shards 参数。

不要将 shards 参数添加到标准请求处理程序；这样做可能会导致搜索查询进入无限循环。相反，请定义一个新的使用 shards 参数的请求处理程序，并将分布式搜索请求传递给该处理程序。

在旧版模式下，仅分发查询请求。这包括对使用支持分布式搜索的标准组件的 SearchHandler（或从 org.apache.solr.handler.component.SearchHandler 扩展的任何处理程序）的请求。

与 SolrCloud 模式一样，当 shards.info=true 时，分布式响应将包括有关分片的信息（其中每个分片代表一个逻辑上不同的索引或物理位置）。

以下组件支持分布式搜索

  • 查询组件，返回与查询匹配的文档。

  • 分面组件，处理 facet.query 和 facet.field 请求，其中分面按计数排序（默认）。

  • 突出显示组件，使 Solr 能够在字段值中包含“突出显示”的匹配项。

  • 统计组件，返回 DocSet 中数字字段的简单统计信息。

  • 调试组件，有助于调试。

allowUrls 参数

通过 solr.xml 中的 allowUrls 属性，可以配置 shards 参数中允许的节点。此允许列表为 SolrCloud 自动配置，但对于用户管理的集群，需要显式配置。请在 配置 ShardHandlerFactory 一节中阅读更多详细信息。

Solr 中的分布式搜索具有以下限制：

  • 每个索引的文档都必须具有唯一的键。

  • 如果 Solr 发现重复的文档 ID，Solr 将选择第一个文档并丢弃后续文档。

  • 如果在分布式搜索的第一阶段和第二阶段之间发生提交，则用于分布式搜索的索引可能会暂时不同步。 这可能会导致这样一种情况：曾经与查询匹配并且随后被更改的文档可能不再与查询匹配，但仍将被检索。这种情况预计非常罕见，并且只可能发生在一个查询请求中。

  • 分片的数量受 GET 方法的 URI 允许的字符数限制；大多数 Web 服务器通常至少支持 4000 个字符，但许多服务器限制 URI 长度以降低其遭受拒绝服务 (DoS) 攻击的脆弱性。

  • 通过在搜索请求中包含 fl=id, [shard]，可以在分布式搜索中返回每个文档的分片信息。 这将返回分片 URL。

  • 在分布式搜索中，核心描述符中的数据目录将覆盖 solrconfig.xml 中的任何数据目录。

  • 更新命令可以发送到任何配置了正确分布式索引的服务器。 文档添加和删除会根据唯一文档 ID 的哈希值转发到相应的服务器/分片。 commit 命令和 deleteByQuery 命令会发送到 shards 中列出的每个服务器。

以前的一个限制是，TF/IDF 相关性计算仅使用分片本地的统计信息。默认情况下仍然如此。如果您的数据不是随机分布的，或者您想要更精确的统计信息，那么您可以配置 ExactStatsCache。

避免分布式死锁

与 SolrCloud 模式一样，分片间请求可能会导致分布式死锁。可以通过遵循 SolrCloud 分布式请求 一节中的说明来避免这种情况。

负载均衡请求

在管理用户管理的 Solr 集群时，查询请求应在每个分片跟随者之间进行负载均衡。这既可以提高查询处理能力，又可以在服务器宕机时实现故障转移。

在这种情况下，由于没有集中的集群管理，因此此配置中的任何领导者分片都不知道彼此。文档会索引到每个领导者，索引会复制到每个跟随者，然后使用每个分片的一个跟随者，在所有跟随者之间分发搜索。

为了实现高可用性，您应该使用负载均衡器为每个分片的一组跟随者设置一个虚拟 IP。 如果您不熟悉负载均衡，HAProxy (http://haproxy.1wt.eu/) 是一个不错的开源软件负载均衡器。 如果跟随者服务器宕机，一个好的负载均衡器将使用某些技术（通常是心跳系统）检测到故障，并将所有请求转发给与失败的跟随者一起工作的其余活动跟随者。 然后应该设置一个单独的虚拟 IP，以便请求可以访问一个单独的 IP，并负载均衡到用于搜索跟随者的每个虚拟 IP。

使用此配置，您将拥有一个完全负载均衡、搜索端容错的系统。传入的搜索将被传递给其中一个正常运行的跟随者，然后跟随者将跨配置中每个分片的跟随者分发搜索请求。 跟随者将向每个分片的每个虚拟 IP 发出请求，并且负载均衡器将选择其中一个可用的跟随者。 最后，结果将合并为一个结果集并返回。 如果任何跟随者宕机，它们将被取消轮换，并将使用其余的跟随者。 如果分片领导者宕机，则仍然可以从跟随者提供搜索服务，直到您纠正问题并将领导者重新投入生产为止。