用户管理的分布式搜索

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

强烈建议您在需要扩展或扩展时使用 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 上运行

http://localhost: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 组件，它处理 facet.query 和 facet.field 请求，其中 facet 按计数（默认）排序。

  • 高亮组件，它使 Solr 能够在字段值中包含“高亮”匹配项。

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

  • 调试组件，它有助于进行调试。

allowUrls 参数

shards 参数中允许的节点可以通过 solr.xml 中的 allowUrls 属性进行配置。此允许列表已为 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 发出请求，负载均衡器将选择一个可用的关注者。最后，结果将被合并到一个单一的结果集中并返回。如果任何关注者宕机，它们将被移出轮换，剩余的关注者将被使用。如果一个分片领导者宕机，搜索仍然可以从关注者那里提供，直到您纠正问题并将领导者重新投入生产。