solrcloud2

分片的原因

由于底层Lucene的限制，每个solr索引中包含的文档数不能超过2³¹个，大约是21亿个。但是solr分片一般不是基于这个的原因，因为一般没有到这个峰值的之后，solr的各中性能问题就暴露出来了。分片一般是为了提高性能，提高吞吐量。

复制策略

solr的复制策略和大部分的NOSQL数据库的复制策略不同，不是通过事务日志进行同步的，而是每次写操作都有leader节点分发到每个replication上去。也就是说，solr更加注重一致性。但是这样牺牲了一定的可用性。

solr的分片策略

solr使用文档路由组件来确定文档应该被分配到那个分片上。solr支持两种文档路由组件：compositeID（默认）和隐式路由（个性化定制分配策略）。

我们只说默认的compositeID策略：

• 计算文档唯一ID字段的数值散列值。
• 将文档分配至hash值区间包含上述计算的散列值的分片。

solr计算散列值使用的是MurmurHash算法，与其它流行的哈希函数相比，对于规律性较强的key，MurmurHash的随机分布特征表现更良好。

ZooKeeper的作用

ZooKeeper在solr中主要负责：

• 集中化配置文件的存储和分发。
• 检测和提醒集群的状态改变。
• 确定分片大小。

每个solr实例将会在ZooKeeper下注册一个ZNode，每个ZNode使用ZooKeeper提供的接口与ZooKeeper通信，如果超过一定的时间（默认是15秒）没有接收到通信，那么ZooKeeper就认为这个节点故障了。节点故障之后ZooKeeper会通知其他solr实例（其实是其他solr实例注册成为了相关ZNode的watcher），这样solr就可以知道哪些节点故障了，如果是replication节点故障了，那么leader节点将不会再转发更新请求到它的身上，如果是leader节点故障了，ZooKeeper会选举一个新的leader节点，然后通知所有相关的solr实例。

solr中leader的作用

在查询操作中，leader和replication具有一样的作用。

对于更新操作来说，leader具有一些责任是replication没有的：

• 为整个分片接收更新请求
• 在更新后的文档上加上_version字段。
• 将文档写入更新日志。
• 以并行的方式将更新请求发送到当前分片的每个replication中，直到收到响应。

solr分布式索引（SolrCloud）的局限性：

• 计算相关度的时候，需要用到文档频次，但是分片之后，文档频次只能计算到所在节点的频次，不是真个集群的频次，所以一定程度上影响了相关度的计算，可能造成偏差。
• 除非使用隐式路由实现个性化配置，如果使用默认的compositionID路由的话，不能使用join和分组（我没有用到，类似于实现sql中的Group by）功能。

分片分割

为集群扩展replication非常简单，只要使用增加完solrcore之后使用命令就可以了。但是如果要增加分片，如原来有2个分片，要增加1个，就很麻烦了，因为分片的内容是根据hash区间确定的，如果我们重新分配Hash区间，那么区间中的数据就需要重新分配。而solr又不能像redis那样，缓存可以经得起丢失，所以solr使用的是分片分割的策略来扩展分片。

分片分割是将一个分片分割为两个的策略。这样不会丢失数据，又可以扩展这个分片。它的缺陷也很明显，如果不能直接扩展分片个数*2，那么就不能均衡的分配分片的hash区间。

这是solr当前的分片扩展策略，还不够成熟，新的版本可能会有更加完善的方案出来。