Solr支持服务器的分布式集群部署，即SolrCloud。在SolrCloud中，一个索引可以被分布到不同的服务器，即不同的node，所有的这些node组成一个collection，并且充分考虑了高可靠性和容错的设计。
SolrCloud使用zookeeper来管理这些服务器，被搜索的文件可以放在任何一个服务器，ZooKeeper会自动管理它们。
一个collection可以把数据（索引文件）拆分成多份，放进几个不同的shard中，一个shard的数据可以有多个备份（replica）。一个shard的多个replica中会有一个leader，由选举程序推选出来。一个replica相当于一个core。
这个功能的主要特性是：
- 整个集群的配置信息可以集中配置
- 对于搜索自动负载均衡、出现故障时可以自动切换
- 集成了ZooKeeper，负责集群的协调和配置
如上图，一个collection（gettingstarted）被拆分到两个不同的shard中，而每个shard都有两个服务器（node）提供负载均衡和遇错切换的服务。这个分布式的结构是由ZooKeeper负责管理的。那些node中，实心圆圈的就是leader。
相关概念：
- HA：High Availability
- Node：一个服务器、或虚拟服务器节点，每个node对应一个port向外提供服务。对应于一个JVM。
- Collection：一个SolrCloud实例，负责对一批数据建立一个索引，并提供基于这个索引的搜索服务
- Shard：一个SolrCloud中的索引可以被拆分存放到多个shard中
- Replica：一个shard中的数据，可以有多个副本，就是Replica，其中有一个被推选出来的leader
- Core：负责处理一个Replica，跟一个node对应
- Cluster：由ZooKeeper管理的多个Node的集合，对solr的请求可以发送给一个cluster
Shard的数量决定了索引是如果被拆分的，所以，当一个cluster初始化完成之后，shard的数量是不能改的。
创建一个新的core并加入到一个Collection和shard中：
curl ‘http://localhost:8983/solr/admin/cores? action=CREATE&name=mycore&collection=my_collection&shard=shard2‘
Shard的迁移：
如果原来只有一个机器、或只有少量机器，可以先规划好shard的数量并启动，然后等有新的机器之后，在新的机器中为某个shard启动一个新的replica，然后把原来的shard移除，这样ZooKeeper就会把新的replica提升为这个shard的leader了。
Leader和Replica：
如果Solr启动的时候，参数numShards=2，那么前两个启动的node就是leader，分别服务于这两个shard，第三个和之后启动的node就是replica，他们会依次按照那两个leader加入cluster的顺序分配给那两个leader（使用round-robin的方式）。也可以在启动node的时候使用shardId参数直接把这个node分配给某个shard。当solr重启的时候，所有的node还是归属到重启之前所归属的shard，同个shard中先启动的node就是leader（first
come first served）。
当一个leader无法工作的时候，这个shard中的某一个replica会被自动推选为leader。
在Solr Admin UI界面中，Cloud菜单里面可以看到哪个是Leader（实心圆圈者）。
新的文档可以被送往任何一个node，SolrCloud会自动把它们分配到合适的shard中：
- 如果文档被送到一个replica中，那么这个replica会把这些文档发送给这个shard的leader
- 当一个leader接收到文档的时候，SolrCloud会决定这些文档应该分配到哪个shard，然后把它们发生给这个shard的leader、建立索引、并把索引发送给这个shard中所有的replica
添加shard：
如果需要加多一个shard，可以使用Collections API，创建两个新的shard，再把现有shard中的索引分配到这两个新Shard中。旧的shard需要手动删掉。
版权声明：本文为原创文章，转载请注明转自Clement-Xu的csdn博客。