首先我们初步理解一下概念

 

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来完成。