Solr 云是否需要负载均衡器，例如HAPROXY 主节点故障
Does Solr cloud needs a load balancer e.g. HAPROXY in master failure
我搜索了很多，但不幸的是对 solr 云有一些简单的混淆。比方说，我有三个系统，其中配置了 solrCloud（1 个主服务器和 2 个从服务器）和相同三台机器上的外部 Zookeeper 以构成法定人数。系统名称是
- 硕士
- 奴隶1
- 奴隶2
- Public-正面
-Public-前面是我配置HAPROXY的系统所在。它接收来自 WWW 的请求并根据 ACL 发送到后端服务器。
根据我的理解，如果我请求 Solr 集合（即 master），它会将它路由到 slave，从而实现负载平衡。这里不需要指定slaves。不是吗？
现在在 Public-Front，我应该将每个 Solr 配置为单独的从属系统来负载平衡还是仅配置为主系统。
现在，如果我只在 HAPROXY 中将主系统配置为 solr-server，那么如果 solr-server（主）出现故障，那么我认为我无法从 HAPROXY 获得 Solr 的服务（尽管从属系统已启动但未在 HAPROXY 中配置).
我哪里错了，最好的方法是什么？
Solr Cloud 中没有传统的 master 或 slave - 有一组副本，其中一个被定义为领导者。领导者的选择是自动的——即第一个说它想成为领导者的副本，获得那个地位。这是每个集合状态。在您的示例中，有三个副本，其中一个被设计为领导者。如果那个副本消失了，剩下的两个副本之一成为新的领导者，一切照常进行。领导者的角色是索引的 up-to-date 版本并处理任何更新 - first to its own index, then route those updates to any replicas.
还有 several types of replicas，并不是所有的人都适合晋升为领导者 - 但在默认配置中他们可以。
事情是这样的——因为没有真正的主控，所以所有三个索引都包含相同的数据，并且它们都是同一个分片的副本，请求将不必通过主控路由。如果您使用的是 dumb haproxy，您可以安全地将请求分散到所有三个节点，并且它们应该能够在不联系任何其他节点的情况下回答查询（只要它们都包含集合的所有分片）。
但是，如果您使用的是 SolrJ 或其他支持 Zookeeper 的客户端（并使用与 Zookeeper 兼容的客户端），客户端将改为与 Zookeeper 保持联系，并读取集群的状态信息。这允许客户端知道哪些服务器当前是您的集合的副本，并联系它可以决定拥有您的查询所需信息的任何节点。在您的情况下，结果将是相同的，只是您的客户端将知道不要连接到任何消失的节点，并且会自动知道添加到集群中的节点。
"one Solr node routing requests to a different node" 仅在您联系的节点没有您查询的集合的任何副本时才相关 - 即它必须联系不同的节点来获取该内容。在这种情况下，将发生集群间请求，集群上的负载将略高于所需。当集合被复制到所有三个节点时 - 或者当您使用 SolrJ 时，集群间请求不应该发生。
我搜索了很多，但不幸的是对 solr 云有一些简单的混淆。比方说，我有三个系统，其中配置了 solrCloud（1 个主服务器和 2 个从服务器）和相同三台机器上的外部 Zookeeper 以构成法定人数。系统名称是
- 硕士
- 奴隶1
- 奴隶2
- Public-正面
-Public-前面是我配置HAPROXY的系统所在。它接收来自 WWW 的请求并根据 ACL 发送到后端服务器。
根据我的理解，如果我请求 Solr 集合（即 master），它会将它路由到 slave，从而实现负载平衡。这里不需要指定slaves。不是吗？
现在在 Public-Front，我应该将每个 Solr 配置为单独的从属系统来负载平衡还是仅配置为主系统。
现在，如果我只在 HAPROXY 中将主系统配置为 solr-server，那么如果 solr-server（主）出现故障，那么我认为我无法从 HAPROXY 获得 Solr 的服务（尽管从属系统已启动但未在 HAPROXY 中配置).
我哪里错了，最好的方法是什么？
Solr Cloud 中没有传统的 master 或 slave - 有一组副本，其中一个被定义为领导者。领导者的选择是自动的——即第一个说它想成为领导者的副本，获得那个地位。这是每个集合状态。在您的示例中，有三个副本，其中一个被设计为领导者。如果那个副本消失了，剩下的两个副本之一成为新的领导者，一切照常进行。领导者的角色是索引的 up-to-date 版本并处理任何更新 - first to its own index, then route those updates to any replicas.
还有 several types of replicas，并不是所有的人都适合晋升为领导者 - 但在默认配置中他们可以。
事情是这样的——因为没有真正的主控，所以所有三个索引都包含相同的数据，并且它们都是同一个分片的副本，请求将不必通过主控路由。如果您使用的是 dumb haproxy，您可以安全地将请求分散到所有三个节点，并且它们应该能够在不联系任何其他节点的情况下回答查询（只要它们都包含集合的所有分片）。
但是，如果您使用的是 SolrJ 或其他支持 Zookeeper 的客户端（并使用与 Zookeeper 兼容的客户端），客户端将改为与 Zookeeper 保持联系，并读取集群的状态信息。这允许客户端知道哪些服务器当前是您的集合的副本，并联系它可以决定拥有您的查询所需信息的任何节点。在您的情况下，结果将是相同的，只是您的客户端将知道不要连接到任何消失的节点，并且会自动知道添加到集群中的节点。
"one Solr node routing requests to a different node" 仅在您联系的节点没有您查询的集合的任何副本时才相关 - 即它必须联系不同的节点来获取该内容。在这种情况下，将发生集群间请求，集群上的负载将略高于所需。当集合被复制到所有三个节点时 - 或者当您使用 SolrJ 时，集群间请求不应该发生。