首先我们初步理解一下概念
SolrCloud模式下有 Cluster,Node,Collection,Shard,LeaderCore,ReplicationCore几个概念,这里我引用一下同事对官方概念的翻译:
* Cluster群集:群集是一组作为一个单元管理的Solr节点。整个群集必须使用同一套schema和solrconfig
* Node节点:一个运行Solr的JVM实例
* Shard碎片:一个分区通过指定的复制因子(replication factor)被存储在多个节点上。所有这些节点共同形成一个碎片。一个节点可能由多个碎片组成。
* Leader负责人:每个碎片(shard)都有一个节点标识作为它的领导。所有的写操作经过领导节点写入指定的分区。
* Replication Factor复制因子的最少数量的文件的副本群集维护
补充说一下:
Collection
这里没有说Collection是什么意思,我就用自己的理解给大家说明, Collection英文直译是集合的意思,在SolrCloud模式下Collection是访问Cluster的入口。这个入口有什么用呢?比如说集群里面有好多台机器,那么访问这个集群通过哪个地址呢,必须有一个接口地址,Collection就是这个接口地址。因此可见Collection是一个逻辑存在的东西,因此是可以跨Node的,在任意节点上都可以访问Collection。
Shard
Shard其实也是一个逻辑存在的东西,因此Shard也是可以跨Node的;
1个Shard下面能且只能包含一个Leader
1个Shard下面可以包含0个或者多个Replication
如果Shard下面的Leader挂掉了,会从Replication里面选举一个Leader。在Solr4.0这个版本这部分实现有不少问题:
Solr4.0的AdminGUI里面可以增加和删除Core,如果Shard里最后一个Core被删除了,Shard不会自动删除掉,会导致集群出错,我们fix了这部分代码;
Shard里面所有的Core宕机了,会导致不能继续插入新的记录,查询不受影响,个人认为应该可以插入到其它存活的Shard里面,因此我们fix了这部分代码;
SolrCloud的工作模式
在SolrCloud模式下,同一个集群里所有Core的配置是统一的,Core有leader和replication两种角色,每个Core一定属于一个Shard,Core在Shard中扮演Leader还是replication由Solr内部自动协调,目前没有找到人工干预的方法,也不需要干预,因为访问SolrCloud的过程:Solrj向Zookeeper咨询Collection的地址,Zookeeper返回存活的节点地址供访问,插入数据的时候由SolrCloud内部协调数据分发(内部使用一致性哈希)。
MultiCore的工作模式
MulitCore模式下各Core之间是相互独立的,同一个Jvm下可以同时运行多个有不同配置的Core。当然在这种模式下,也可以通过参数同时访问多个Core,可以通过配置实现master->replication主从模式的复制,不过这些都需要自己编写的JavaApp来完成。