我进行了很多搜索，但不幸的是，关于solr cloud有些简单的困惑。可以说，我有三个系统，其中已配置solrCloud（1个主服务器和2个从属服务器），以及在同一三台计算机上构成外部仲裁程序的Zookeeper。系统名称是
Public-Front是在其中配置HAPROXY的系统。它根据ACL接收来自WWW的请求并将其发送到后端服务器。
根据我的理解，如果我请求Solr集合（即主服务器），它将路由到从服务器并因此实现负载平衡。此处无需指定从站。不是吗？
现在在Public-Front中，我应该将每个Solr配置为一个单独的从属服务器，以实现负载平衡还是仅作为主系统。
现在，如果我仅将主系统配置为HAPROXY中的solr-server，那么如果solr-server（主）发生故障，那么我认为我无法从HAPROXY获得Solr的服务（尽管从属服务器一直处于运行状态，但未在HAPROXY中进行配置）。
我在哪里错了，最好的方法是什么？
答案 0 :(得分：1)
Solr Cloud中没有传统的master或slave-有一组副本，其中一个副本被定义为领导者。领导者选择是自动的-即表示要成为领导者的第一个副本将获得该状态。这是每个收集状态。在您的示例中，有三个副本，其中一个副本被设计为领导者。如果该副本消失，则其余两个副本之一将成为新的领导者，并且一切照常进行。领导者的角色是成为索引的最新版本并处理所有更新-first to its own index, then route those updates to any replicas。
还有several types of replicas，并不是所有人都适合晋升为领导者-但在默认配置下，他们可以成为领袖。
这就是问题-因为实际上没有主服务器，所以所有三个索引都包含相同的数据，而且它们都是同一分片的副本，因此不必通过主服务器路由请求。如果您使用的是哑巴代理，则可以将请求安全地分布在所有三个节点上，并且它们应该能够在不联系任何其他节点的情况下回答查询（只要它们都包含集合的所有分片）。
但是，如果您使用的是SolrJ或其他支持Zookeeper的客户端（并使用与Zookeeper兼容的客户端），则该客户端将与Zookeeper保持联系，并读取集群的状态信息。这样，客户端就可以知道哪些服务器当前是您集合的副本，并联系可以确定具有查询所需信息的那些节点中的任何一个。在您的情况下，结果将是相同的，除了您的客户端将不连接任何消失的节点，并自动知道添加到群集的节点之外。
“一个Solr节点将请求路由到另一个节点”仅在您要联系的节点没有要查询的集合的任何副本的情况下才有意义-即，它必须联系另一个节点来获取该内容。在这种情况下，将发生集群间请求，并且集群上的负载将略高于必需的负载。当将集合复制到所有三个节点时-或使用SolrJ时，该集群间请求就不会发生。