在Solr4.4之后，Solr提供了SolrCloud分布式集群的模式，它带来的主要好处是：

（1）大数据量下更高的性能 
（2）更好扩展性 
（3）更高的可靠性 
（4）更简单易用

什么时候应该使用SolrCloud（Shard）呢？

（1）更大的数据量 
（2）更大的索引体积 
（3）想并行索引和查询 
（4）想自定义数据分区

SolrCloud路由的分类

A：显式路由（Composite） => 创建时明确指定shard数目，后期不能添加或者删除shard，单个shard可以split

创建collection方式：首次创建推荐提前在linux上把conf相关配置上传到zk上，然后在solr的admin进行创建， 除此之外，也支持curl和java api动态创建

独有技能：支持shard的split，不支持shard的动态添加和删除

特点： 
（1）默认是基于通过hash(docid)来定位归属shard 
（2）也支持在主键上加入路由字段进行路由，最多支持2级，查询时加入_route_ 参数，设置路由策略，用例如下： 
一级路由例子： 
china!1   usa!2 
二级路由例子： 
china!beijing!1   usa!nework!2 
如果路由后，数据分布不均衡可对数据倾斜的路由，进行均衡，例子如下： 
china/3!1   按1/8的shard个数，均衡数据，如果shard总数是24个，那么将会有3个shard存储china路由的数据 
china!henan/2!1  按1/4的shard个数，均衡数据，如果shard总数是24个，那么将会有6个shard存储china!henan的数据目前固定只有1/8和1/4的比例分配，也就是只支持2，3这样的分配比例

B：隐式路由（Implict）=> 创建时明确指定shard数目，后期可以动态添加或者删除shard，但单个shard不能split

创建collection方式：首次创建推荐提前在linux上把conf相关配置上传到zk上，然后在solr的admin进行创建， 除此之外，也支持curl和java api动态创建。

独有技能：不支持shard的split，支持shard的动态添加和删除

特点： 
真正的100%的手工路由，可根据业务规则进行shard设置，除此之外，支持shard的动态添加和删除，路由控制随心所欲，不像MySQL还得依赖中间件才能搞定，查询时加入_route_ 参数，设置路由策略

总结： 
文章简单介绍了使用SolrCloud的好处，以及什么时候应该使用和其路由的种类与特点，路由话题在分布式系统中是一个高级技能，它与分而治之，按需所取的思想不谋而合sharding的功能并不是Solr，ElasticSearch独有，任何一个数据库存储系统都可以存在这个概念，在实际的开发应用场景中，需要根据业务一些特定的特点来合理划分维度和路由，使用得当，效率会大大提升，无论是写入还是查询，在考虑设计维度或者路由时，大部分可考虑时间，类别，等级，地区等一些字段，当然具体业务还需要具体分析，不能一概而论。

官网文档： 
（1）文档路由 
https://cwiki.apache.org/confluence/display/solr/Shards+and+Indexing+Data+in+SolrCloud#ShardsandIndexingDatainSolrCloud-DocumentRouting 
（2）Collection API 
https://cwiki.apache.org/confluence/display/solr/Collections+API