Solr 集群类型

Solr 集群是一组服务器（节点），每个服务器都运行 Solr。

操作 Solr 节点集群有两种通用模式。一种模式提供 Solr 节点的集中协调（SolrCloud 模式），而另一种模式允许您在没有这种集中协调的情况下操作集群（用户管理模式）。

这两种模式共享通用概念，但最终在这些概念如何反映在功能和特性中方面有所不同。

首先，让我们介绍一些通用概念，然后概述这两种模式之间的差异。

集群概念

在这两种集群模式中，单个逻辑索引可以作为分片跨节点拆分。每个分片都包含总体索引的子集。

分片数量决定了可以索引到 Solr 的文档数量的理论限制。它还决定了单个搜索请求可能的并行化程度。

为了为每个分片提供一些故障转移，每个分片都可以复制为副本。副本具有与分片和同一索引的任何其他副本相同的配置。

可以在没有创建分片的情况下拥有副本。在这种情况下，每个副本将是整个索引的完整副本，而不是仅是整个索引的一部分的副本。

副本数量决定了在节点发生故障时整个集群的容错级别。它还决定了在高负载下可以处理的并发搜索请求数量的理论限制。

创建副本后，必须标识领导者。领导者的职责是成为每个副本的事实来源。当对索引进行更新时，它们首先由领导者处理，然后由每个副本处理（具体机制因情况而异）。

不是领导者的副本是跟随者。

每个副本，无论是领导者还是跟随者，都称为内核。任何一个节点都可以托管多个内核。

SolrCloud 模式（也称为“SolrCloud”）使用 Apache ZooKeeper 来提供其主要特性集中式集群管理。ZooKeeper 跟踪集群的每个节点以及每个节点上每个核心的状态。

在此模式中，配置文件存储在 ZooKeeper 中，而不是存储在每个节点的文件系统中。当进行配置更改时，必须将它们上传到 ZooKeeper，ZooKeeper 反过来确保每个节点都知道已进行更改。

SolrCloud 引入了另一个概念，即集合。集合是表示索引的所有核心组：每个分片的逻辑分片和物理副本。所有集合共享相同的配置（模式、solrconfig.xml 等）。这是集群管理的另一个集中化，因为可以一次对整个集合执行操作。

当对配置进行更改时，重新加载集合的单个命令会自动重新加载属于该集合的每个单独核心。

分片会自动处理，只需在创建集合时告诉 Solr 您希望集合包含多少个分片即可。然后，索引更新通常会在每个分片之间自动平衡。如果需要，还可以对存储在哪个分片中的文档进行一定程度的控制。

ZooKeeper 还处理负载平衡和故障转移。传入请求（用于索引文档或用户查询）可以发送到集群的任何节点，ZooKeeper 会将请求路由到每个分片的适当副本。

在 SolrCloud 中，领导者是灵活的，具有内置机制，以便在领导者发生故障时自动选举领导者。这意味着另一个核心可以成为领导者，从那时起，它就是所有副本的事实来源。

只要每个相关分片的副本可用，在 SolrCloud 模式下运行时，仍然可以满足用户查询或索引请求。

Solr 的用户管理模式要求 SolrCloud 通常使用 ZooKeeper 执行的集群协调活动手动执行或使用本地脚本执行。

如果文档语料库对于单分片索引来说太大，则创建分片的逻辑完全留给用户。Solr 没有自动或编程方式在索引期间创建分片。

将文档路由到分片是手动处理的，可以使用简单的哈希系统或将每个文档发送到不同分片的简单循环分片列表。文档更新必须发送到正确的分片，否则可能会导致重复文档。

在用户管理模式中，领导者和跟随者的概念变得至关重要。识别哪个节点将托管领导者副本以及哪个主机将成为副本决定了每个节点的配置方式。在此模式中，所有索引更新仅发送到领导者。一旦领导者完成索引，副本将请求索引更新并从领导者复制它们。

除非请求流量可以由领导者或其一个副本单独管理，否则负载平衡是通过外部工具或进程实现的。

如果领导者宕机，则没有内置故障转移机制。如果查询被专门定向到副本，则副本可以继续提供查询服务。将副本更改为领导者需要在所有副本上更改 solrconfig.xml 配置并重新加载每个核心。

用户管理模式没有集合的概念，因此，出于所有意图和目的，每个 Solr 节点都与其他节点不同。只有某些配置参数可以防止每个节点表现为独立实体。