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 节点都与其他节点不同。只有一些配置参数可以防止每个节点像独立实体一样运行。