首先我们初步理解一下概念
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
在 Solr 4.0 这个版本这部分实现有不少问题：
- Solr 4.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 来完成。