在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
（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