Solr6与Zookeeper的SolrCloud集群

摘要： 在上一篇中，介绍了Solr6与Zookeeper在Tomcat环境做SolrCloud集群，这一篇接着介绍一些在这一过程中可能遇到的名词或概念。

为什么多个Zookeeper实例

Zookeeper被用来监控你的集群，启动的多个Zookeeper中有一个被称为overseer节点，负责总管你的集群。如果这个节点挂了，其他的Zookeeper会被任命为overseer，继续处理集群事务。

为什么多个Solr实例

集群中至少拥有和shard一样多的Solr实例充当leader，之后增加的Solr实例被充当为replica，如果有leader挂了之后，其replica会被任命为leader。一个collection下的所有leader中的数据应该不是一样的，leader对应的replica中的数据与之是相同的。

伪集群

基于Zookeeper，我们可以做到在单个实例版的Zookeeper实例运行SolrCloud；单机版（IP相同）多Zookeeper实例的伪SolrCloud集群；真实的生产环境通常会包含多台物理服务器或是虚拟机（IP不同），所以还有生产环境下的SolrCloud集群。

Node和Core

对于SolrCloud，node可以理解为运行Solr的JVM进程，一般称之为server。每一个 Solr core都可看作是一个node,任何的node都可以拥有一个Solr实例和其他数据。一个Solr core 主要是一些索引数据和文档字段。一个Solr实例可以包含多个cores,他们彼此独立。

集群

集群是一系列由Zookeeper管理的Solr nodes，如果你拥有一个集群，你可以发送请求到任何一个可达节点，你不会丢失数据。数据的更改可以被立刻感知到。
一般认为，一个Solr实例被注册到Zookeeper之后，这个集群就被创建了。

Leader和Replica

这个Leader有点像以前master-slave模式中的master，负责确保replica节点中的数据与其保持一致。每一个shard中都必须存在一个leader，而replica是可选的。如果shard的leader不可用，replica就会充当leader角色。

SolrCloud集群分析

一个集群可能拥有如下视图：

collection collection为core0，默认就是core的名称。
shard 该core有两个shard,分别是shard1，shard2,是默认的名字，如果再加一个就是shard3
leader 有两个leader，8080端口和8081端口（黑色实心小圆点）
replica 有两个replica，8082端口和8083端口（空心小圆圈）
在搭建SolrCloud的时候，我先启动ZooKeeper，然后启动了8080端口，并指定了参数-DnumShards=2，也就是集群的shard是2，后台报错，因为此时集群中shard是1。我启动了8081端口，它会自动被添加到shard2，作为leader，此时集群可以正常工作。我又启动了8082端口，其配置与8081端口的配置完全相同，但是集群中所有shard都有leader，因此就会被顺序添加到shard1作为replica。再启动8083端口，就会被顺序添加到shard2作为replica。
8080端口必须被首先启动，因为它配置了-DnumShards=2等信息，其他的节点如果启动顺序不一样，会有完全不同的分配情况。例如，在启动8080端口以后，先启动8083端口，那它就成了shard2的leader。